You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A local client sends two types of encrypted data to the server for storage: an encrypted storage key and encrypted secrets.
The implementation sends the "complete" encrypted data to the server. This includes
The ciphertext
The associated data
The random nonce
The original type
When the server receives this data, they store it without checking the associated data.
However, the spec implies that the server should not receive the associated data and simply store the encrypted pieces. On the client side, when they need to decrypt something, they should reconstruct the associated data and use it to decrypt.
There are two options to fix this
Update the implementation to have the server check that the associated data is consistent with the rest of the request (e.g. for a secret, the associated data should contain the expected key id and user id). Update the spec to pass the associated data and validate it.
Update the implementation to not send the associated data with the encrypted data to the server. Update the client side to reconstruct the associated data at decryption time.
The latter will have some additional considerations when we start to allow user-specified context with a secret -- if it's not stored at the server, it must be stored locally, and then there's an availability issue if the user loses their device and can't remember that context.
The text was updated successfully, but these errors were encountered:
A local client sends two types of encrypted data to the server for storage: an encrypted storage key and encrypted secrets.
The implementation sends the "complete" encrypted data to the server. This includes
When the server receives this data, they store it without checking the associated data.
However, the spec implies that the server should not receive the associated data and simply store the encrypted pieces. On the client side, when they need to decrypt something, they should reconstruct the associated data and use it to decrypt.
There are two options to fix this
The latter will have some additional considerations when we start to allow user-specified context with a secret -- if it's not stored at the server, it must be stored locally, and then there's an availability issue if the user loses their device and can't remember that context.
The text was updated successfully, but these errors were encountered: