Reevaluate timing of retrieval of storage key

[marsella]

In generate and store and retrieve, the client needs to retrieve their storage key. Currently, the flows retrieve it at the beginning of the protocol, then use it later.

This is technically fine, but in the implementation, we want to try to bundle cryptographic operations together to reduce exposure of unencrypted keys. The cryptography module does not handle networking or database access, so operations can only be bundled if they aren't interspersed with these calls.

Two possible options to achieve this (there may be others):

1. Leave the calls to retrieve_storage_key where they are, but change the function to return the encrypted storage key. Decrypt the key when it is used. E.g. in generate-and-store, add an action before 3.ii to decrypt the storage key.
2. Leave retrieve_storage_key the same, but call it immediately before use. E.g. in generate-and-store, the first step of 3 should be "call retrieve_storage_key"

@marsella is slightly partial to 1, because it reduces the spec changes and simplifies the code blocks: since retrieve_storage_key includes networking, it won't be fully defined in the cryptography module. This means it's not completely simple to bundle the decryption of the storage key in that function with its use in another crypto function. We could probably achieve what we want by doing some slightly fancy type stuff -- passing a follow-up function like encrypt_secret to the retrieve_storage_key function, so that the StorageKey type can remain private to the dams crate / crypto module. But it would add some code complexity.

Possible concerns:

• Does this change the server threat model? Is there a problem if the client retrieves a secret but cannot decrypt it? Does it reveal any information to change the timing of storage key retrieval?

[marsella]

Per #183, also review whether we can persist an encrypted storage key between sessions (e.g. retrieve_storage_key would become, check if the encrypted key is in local storage and retrieve if not).

This might require additional specification of when it should be removed from local storage (e.g. when authentication expires).