Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Align behavior of associated data on encrypted data sent to the server #123

Open
marsella opened this issue Sep 7, 2022 · 0 comments
Open

Comments

@marsella
Copy link
Contributor

marsella commented Sep 7, 2022

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

  1. 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.
  2. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant