| This is a fork of tptacek's 2015's Cryptographic Right Answers Gist [1]. I think the original 2015 file is somewhat better than this fork. The fork is more up-to-date, but just offers too many options and is probably to confusing for a beginner. As far as I know, the latest "official" update to Cryptographic Right Answers is the Latacora blog post from 2018 [2]. Both the the 2015 version of Right Answers and the OP best practice guide mention (non-extended) ChaCha20-Poly1305, but if you look at their order of priorities, using NaCl/libsodium/monocypher is always mentioned first. That gives you XSalsa20-Poly1305 (NaCl, libsodium default) or XChaCha20-Poly1305 (monocypher, optional for libsodium). the non-extended ChaPoly20 is mentioned as lower priority than the extended versions, but higher priority than AES-GCM, which also features short nonces. The same argument goes for ECC. The actual "Use" line in the document mentions NaCl, libsodium and monocypher, all of them use X25519 by default, although monocypher does not seem to offer an asymmetric encryption primitive. The main issue is the confusing language talking about ECC, when we know than some ECC (yes, I'm looking at you ECDSA) is not strictly better than RSA [3]. None of the answers in the OP guide seems wrong per se (I didn't review this thoroughly FWIW and I'm not an expert). But I'm still recommending this one, since it's simpler, and "simpler" is the entire point of this kind of guide. You want to avoid programmers shooting themselves in the foot - and shooting yourself in the foot is really easy when you're implementing cryptography. [1] https://gist.github.com/tqbf/be58d2d39690c3b366ad [2] https://latacora.micro.blog/2018/04/03/cryptographic-right-a... [3] Except when you define "better" as "Lets you jailbreak your PlayStation 3". |
Neither do NaCl and Libsodium. Their `crypto_box()` is a construction that does key exchange, derives a key from the resulting key exchange, and finally use that key to perform symmetric authenticated encryption. I simply omitted that particular construction for Monocypher.
I've often asked be why. My reason is that the NaCl libraries (all 3 of them) are low-level, and a straightforward application of `crypto_box()` lacks the security properties we've now come to expect of modern key exchanges, most notably forward secrecy. To get up to that level would require implementing Noise, and I personally feel that's a tad out of scope. I reckon however that higher-level libraries that implement full protocols however are sorely needed.