Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> For symmetric encryption, if you’re recommending Salsa20/ChaCha20, it is absolutely necessary to discuss nonce management, since this is a major footgun people coming from AES may not be familiar with.

The most popular AES mode here is AES-GCM, where nonce reuse is even more catastrophic than it is with ChaPoly. People coming from AES thus are familiar with nonce-reuse problems, unless they’re (i) incompetent or (ii) only ever used a nonce-misuse resistant construction, and those are still pretty niche.

Agreed that extended nonces are the safest default.

> “Use ECC” is too generic as advice for asymmetric encryption.

Which is why that’s not the actual advice? There’s a discussion about why ECC is better, but when it comes to the actual recommendations, I read:

  Asymmetric Encryption
    Use: NaCL, libsodium, or monocypher

  Asymmetric Signatures
    Use, in order of preference: 
    1. NaCL, libsodium, or monocypher
    2. Ed25519
    3. RFC6979 (deterministic DSA/ECDSA)
> Also, I think monocypher was written independently of NaCl, it’s not a fork.

As the author of Monocypher I can answer that one: though I did independently implement it, my choice of primitives puts its squarely in the NaCl family, and closest to libsodium. I even use libsodium to generate most of my test vectors. And with the exception of Elligator and streaming encryption we use compatible wire formats. And finally I did shamelessly stole some code from the Ref10 implementation of Curve25519, and the bignum arithmetic is still there.

Under my definition of a fork (clone repo then branch off), it’s not. But under a looser definition… I’m not too mad about it.

(Now I’m wondering how much of a fork of NaCl libsodium actually is…)



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: