search

briansmith / ring

Safe, fast, small crypto using Rust
Other
3.74k stars 704 forks source link

Change `aead` API to more clearly support symmetric encryption #456

Closed djc closed 7 years ago

djc commented 7 years ago

As discussed a long time ago, the aead API currently kind of depends on OpeningKey and SealingKey, suggesting a use of asymmetric encryption, even though the algorithms supported are symmetric. IIRC this was because the aead stuff is most often used with different keys for the sending and receiving channels, but I would also like to use it to encrypt data at rest, for which the use of different keys does not make much sense.

briansmith commented 7 years ago

I agree. But, how would an application of at-rest encryption generate the IVs? It seems like we need to use nonce-misuse-resistant (NMR) encryption instead, for these use cases. That's why I didn't add the "decrypt_with_own_key()` API that I had mentioned before.

djc commented 7 years ago

I discussed this a little bit in #rust-crypto, where the suggestion seems to be derive a per-blob key and IV from a long-term key plus a blob-specific nonce through HKDF. Would that solve the problems you see? AES-GCM-SIV and HS1-SIV were also mentioned.

briansmith commented 7 years ago

I discussed this a little bit in #rust-crypto, where the suggestion seems to be derive a per-blob key and IV from a long-term key plus a blob-specific nonce through HKDF. Would that solve the problems you see? AES-GCM-SIV and HS1-SIV were also mentioned.

Right. The thing with HKDF is basically implementing an ad-hoc NMR AEAD. We have #411, #412, and #413 to track adding NMR AEADs. One problem with AES-GCM-SIV is that the spec isn't stable; in fact, it is guaranteed to change. Adding XChaCha20-Poly1305 (#411) would probably be the simplest thing to do. We should be able to easily build an API for it that supports exactly the kind of use case you have.

briansmith commented 7 years ago

I'm going to close this as WONTFIX. Basically, it is intentionally awkward to use the existing AEADS (ChaCha20-Poly1305 and AES-GCM) to encrypt and decrypt with the same key because the use cases for that aren't really that suitable for using ChaCha20-Poly1305 and AES-GCM.

Instead, when we implement one of the NMR AEADs (see previous comment), the NMR AEADs will have a different API that does make it easy to use them for one-party encryption/decryption.