Allow to set aad in StorableBuilder::{build,desconstruct}
#40
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.
tnull
force-pushed
the
2025-08-include-key-aad
branch
from
e7bdd0a to
3c62a9f
Compare
.. to make sure the values don't linger in memory.
tnull
force-pushed
the
2025-08-include-key-aad
branch
from
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.
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. |
|
🔔 2nd Reminder Hey @tankyleo! This PR has been waiting for your review. |
Previously, we omitted setting
ChaCha20Poly1305RFC'saadfield, which had thetagnot 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 theStorableto get stored). This change is backwards compatible if users provide a staticaad: &[]argument. Otherwise, users will need to find an upgrade path client-side.