Recommended AEAD algorithms

[tarcieri]

Following up from RustCrypto/meta#10, this is an issue for discussion potentially adding "recommended" badges to certain algorithms in this repo:

[tarcieri]

I'd suggest at least the following are safe to recommend:

• aes-gcm
• aes-gcm-siv
• aes-siv
• chacha20poly1305
• eax

I don't think there are any algorithms implemented in this repo we should actively recommend people avoid, however some specific thoughts on why not to recommend certain algorithms:

ccm: obsoleted by eax

I don't think we should actively recommend against CCM as it is popular in the embedded space. However I think there were a number of bad decisions made in the design of CCM which are addressed by EAX. Some of those include:

• The length of the plaintext message and AAD need to be known in advance
• AAD is MAC'd last rather than first, which together with the above issue complicates online/streaming encryption
• AES-CCM uses needlessly complex message framing with variable-length length tags

xsalsa20poly1305: obsoleted by chacha20poly1305

• The ChaCha(20) stream cipher family provides better per-round diffusion than the Salsa20 family.
• ChaCha20 is a full AEAD algorithm, whereas XSalsa20Poly1305 does not support AAD.
• ChaCha20Poly1305 is specified in RFC 8439. XSalsa20Poly1305 has no associated RFC.
• The XChaCha20Poly1305 construction provides the same extended nonce benefits as XSalsa20Poly1305.

[newpavlov]

Note that I plan to introduce generic GCM and SIV crates, making the aes variants thin wrappers around them.

[tarcieri]

The aes-gcm and aes-siv crates are already generic around a block cipher, as it were.

[newpavlov]

The idea is to publish them under gcm and siv names respectively, to make them consistent with other crates.

[tarcieri]

Sure, we can do that, although I'd probably suggest trying to tackle RustCrypto/traits#444 first as for at least the aes-gcm case it requires implementing some specific interactions between e.g. the aes and ghash crates.

[rustonaut]

It might be worth to replicate or link the comparison of various characteristics and usage recommendations from libsodium. E.g. max bytes for a single (key, nonce), max messages with random nonces, or "safe" options to choose a nonce.

I.e.: https://doc.libsodium.org/secret-key_cryptography/aead

In general giving recommendations without context is a bit tricky so I would recommend to always pair them with some documentations under which conditions they are safe. I mean in general a project implementing crypto is probably not the best guid for designing any protocol involving cryptography or similar (it's grate for implemting protocols people with extensive cryptographic knowledge reviewed but that doesn't need recommendations for algorithms) . But from personal experience I know that people will do so, so we might as well help them to take slightly more informed decisions.

E.g. if we look at AES-GCM we can recommend it if messages aren't too large, you don't use random nonces, there is no possible attack vectore where attackers can cause a nonce reuse and hardware acceleration is available. Then you could give it a "yes". But otherwise it's not "neutral" but a very clear no. Similar if there isn't a good reason to have it AES128 should be avoided not because it's broken but because there is increased risk that attacks against AES128 might become viable (in ways where AES256 would still be safe).

Like to elaborate (rant) a bit on AES-GCM ...

... it has a pretty bad failure mode on nonce reuse where it can be possible for attackers to calculate the private key, where for e.g. ChaCha20 the failure mode is more on the level of allowing decrypting the two affected messages (AFIK). Even ignoring that and you still would only be around up to 2^32 "safe" messages with random nonces for AES256-GCM something which depending on use case might be very much archival, especially if the attacker can cause messages to be send in some way. Then you add in a very long history (and fundamental issues) of side channel attacks on software impl of AES where you basically can assume that for pure software impl it's either slow or has side channel vulnerabilities. Lastly we can top it of with some complicated issues related to AES256/512 not scaling up the inner block size leading to some edge cases where your security is effective only as if it's AES128.

So while AES is widely used and has wide hardware and library support and is often a good choice because of it I would never give a generic recommendation for AES-GCM even through there are many use cases in which it is secure to use. The very wide use of AES-GCM isn't because it's the best, but because it's widely supported with hardware acceleration and can be safely used iff you are very careful and know about it's issues.

And lets not even start about topics like Random Key Robustness (which is not just affecting AES-GCM, but also ChaCha20Poly1305 etc.) being overlooked all the time by developers not specialized in crypto.

---

Disclaimer: I'm not a cryptography specialist, just a uh, lets say cryptographic security aware developer.