-
Notifications
You must be signed in to change notification settings - Fork 70
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
Switch to AES-GCM-SIV for encryption in the store? #291
Comments
@emschwartz you can use Miscreant for AES-SIV (RFC 5297) and I'd consider that implementation fairly robust. I've been working on implementing AES-GCM-SIV (which will be available in a standalone I'd consider any such forthcoming implementation bleeding edge for awhile though. |
How does AES-SIV compare to AES-GCM-SIV? |
They have roughly equivalent security properties. AES-GCM-SIV provides "beyond birthday bound" security by deriving a unique keys for each message. As of the final version, it provides good security bounds under nonce reuse, while when used under the birthday bound AES-SIV leaks nothing but message equivalence under nonce reuse. AES-SIV is over twice as slow for short messages, and significantly slower for long messages as AES-CMAC isn't parallelizable. AES-GCM-SIV, when properly optimized, is ~30% slower than AES-GCM for encryption, and vanishingly faster than AES-GCM for decryption (due to the use of POLYVAL). Either are suitable for deterministic "keywrap" use, where a uniformly random key is encrypted without a nonce, shortening the message payload in cases where you may have otherwise used a random nonce. This sort of use case is why AES-GCM-SIV was originally developed (e.g. source-address tokens in QUIC, or session tokens in TLS). Ideally these keys are randomly generated and encrypted, which sidesteps the issue of leaking message equivalence as you won't ever have equivalent messages since they're randomly generated. If you're encrypting an existing key, as opposed to a randomly generated one, make sure it's for a use case where deterministic encryption is desirable and message equivalence isn't helpful to an attacker, like "tokenization" . |
@tarcieri How much value does nonce reuse resistance add if we are in a context where we control the creation of nonces and always use a random nonce generated by |
AES-SIV was originally created for the keywrap use case, which it sounds like is what you're doing. Its big advantage there is no nonce is required, which saves space. If you don't care about that, you can do whatever you want, although personally I'm not a fan of using AES-GCM in combination with random 96-bit nonces. |
Ah good point, that makes sense |
We should make a decision on this before #557 is finalized |
Note the relevant crate is here: https://github.com/RustCrypto/AEADs/tree/master/aes-gcm-siv There may be a security audit happening soon too. |
Suggested by @tarcieri in #245 (comment).
This would be a breaking change so it would be good to decide sooner rather than later whether we want to make this change.
@tarcieri is miscreant ready to use for this?
@gakonst we should also move the encryption/decryption out of the store and into the node if possible. We could open a separate issue to track that or include it with this change
The text was updated successfully, but these errors were encountered: