-
Notifications
You must be signed in to change notification settings - Fork 6
Allow to set aad
in StorableBuilder::{build,desconstruct}
#40
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
base: main
Are you sure you want to change the base?
Conversation
Previously, we omitted setting `ChaCha20Poly1305RFC`'s `aad` field, which had the `tag` not commit to any particular key. This would allow a malicious VSS provider to substitute blobs stored under a different key without the client noticing. Here, we allow to set the `aad` (which usually should be the full key under which we expect the `Storable` to get stored). This change is backwards compatible if users provide a static `aad: &[]` argument. Otherwise, users will need to find an upgrade path client-side.
👋 I see @jkczyz was un-assigned. |
Previously, this `unwrap` could have us panic if the service wouldn't provide a message including the `EncryptionMetadata`. Here we fix this by simply erroring out if the expected metadata is not present.
There is now reason `StorableBuilder` needs to permanently own the `data_encryption_key`, which just risks that the key will linger around in memory after `StorableBuilder` has been dropped. Here, we switch the API to simply take `data_encryption_key` by reference for the `build`/`deconstruct` operations.
e7bdd0a
to
3c62a9f
Compare
.. to make sure the values don't linger in memory.
3c62a9f
to
03ca9d9
Compare
the core of the issue of not having the AAD is that we can no longer authenticate the storage context of the encrypted blob. another attack that is still possible is that the VSS provider can claim thing that an encrypted blob came from a different
Not really sure how this becomes bad in practice, but also something worth keeping in mind. |
something that just came to mind while thinking about backwards-compatibility. A server could also:
I'm not sure adding something to AAD alone would help here at all. The App would need to store some state, which runs counter to VSS' use-case as a backup store (how do you verify something you don't have information about?) |
/// | ||
/// Refer to docs on [`Storable`] for more information. | ||
/// | ||
/// [`PutObjectRequest`]: crate::types::PutObjectRequest | ||
pub fn build(&self, input: Vec<u8>, version: i64) -> Storable { | ||
pub fn build( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i wonder if we could be opinionated here for future writes and have the AAD commit to:
- The key-value key (lol) [fixes the issue mentioned in pr]
- store_id [fixes potential multi-tenancy issues]
🔔 1st Reminder Hey @jkczyz! This PR has been waiting for your review. |
🔔 1st Reminder Hey @tankyleo! This PR has been waiting for your review. |
Previously, we omitted setting
ChaCha20Poly1305RFC
'saad
field, which had thetag
not commit to any particular key. This would allow a malicious VSS provider to substitute blobs stored under a different key without the client noticing.Here, we allow to set the
aad
(which usually should be the full key under which we expect theStorable
to get stored). This change is backwards compatible if users provide a staticaad: &[]
argument. Otherwise, users will need to find an upgrade path client-side.