Add retrieve details #50
Conversation
|
Second bullet is a good point. In phase 0, we included a "get all key IDs" function that didn't make it into this version yet. Would "a list of the user's associated data" include anything other than key IDs? |
See #53 |
indomitableSwan
force-pushed
the
retrieve
branch
from
31faa2c
to
49dedd2
Compare
|
There should probably be implementation guidance around the handlings of |
| 1. Runs the [generate protocol](cryptographic_flows.md#generate-a-secret) to get a symmetric key `storage_key` for [`Enc`](#external-dependencies) of length 32 bytes. | ||
| - The `storage key` MUST NOT be saved, stored, or used in any context outside this protocol. It must not be passed to the calling application. | ||
| 1. Computes a ciphertext `encrypted_storage_key = Enc(opaque_encryption_key, storage_key, user_id||"storage key")`. | ||
| 1. Computes a ciphertext `encrypted_storage_key = Enc(master_key, storage_key, user_id||"storage key"|context)`. |
There was a problem hiding this comment.
Open question: Is there additional context here beyond "storage key"? We temporarily had "context" set in a previous step, but that has been removed now. The only thing I can think of is details of the encryption scheme or maybe a note that it was encrypted with the master key, but neither of those seem particularly useful to me since you have to know them to decrypt the thing anyway.
There was a problem hiding this comment.
I had simplified this for now, based on your previous comments and after thinking about how we plan to use this key.
In general, though, it's much safer to view a key as both the key material and the context (which primitive, which parameters) and to be careful to enforce that the context is correct. This helps prevent downstream misuse like where you use the key in a different primitive or with different parameters, for example as part of an attack. Does this make sense? @marsella
This PR closes #12.
Things it doesn't address, but came up as questions during drafting:
user_idfor both OPAQUE and our application, but these identifiers should be different. For OPAQUE, the user identifier should be human-memorable account information, whereas the latter is a 128-bit UUID. The likely solution here is that the key server should generate and store this ID during registration (Write cryptographic flow for registering a user #11), and pass it back to the client during authentication (Write cryptographic flow for authenticating a user #10).