Comment by loup-vaillant | Hacker News Reader

Comment by loup-vaillant | Hacker News Reader

I get the point, but the current state of affair encourages me to make it even worse. I'm currently working on a tweetNaCl-like library that will integrate not only Chacha20, but also Blake2b and Argon2i, based on the same ideas.

The repeated application of simple ARX based rounds is a damn good idea: it's efficient even for software implementations, it's often "naturally" constant time, and it's simple. Implementing this stuff is easy: if it's Valgrind clean and passes the test vectors, it probably works. It also makes audits and reviews much easier.

Similarly, Wegman-Carter authenticators such as Poly1305 are kind of a no-brainer: no forgeries are possible unless you break the cipher itself! Also, fast. Modular arithmetic and potential limb overflow makes them harder to get right but still.

Finally, there is simply no escaping elliptic curves. I don't trust the NIST curves. 25519 is not too complex, fast, and doesn't leave enough space in its constants for a backdoor (DJB made sure the design constraints were tight).

I mostly agree with this article, but I don't mind a monoculture if it means I get boring crypto.

None of "simple", "fast", and "not backdoored" capture the real reason why Curve25519 is so deservedly popular; the real issue is that Curve25519 is misuse-resistant: random strings are, for 25519 ECDH, valid public keys, and the arithmetic rules for the curve he chose permit straightforward constant-time implementations.

I haven't spoken to a cryptographer who believes the NIST curves are backdoored (or, for that matter, in any of the elaborate hocus-pocus around the Brainpool curves being untrustworthy). But the NIST curves are difficult to use safely, which is why nobody likes them.

The NIST backdoor stuff is an argument that appeals more to message board nerds than to practitioners.

(Is NIST itself trustworthy? Fuck no. The Dual_EC CSPRNG seems pretty clearly to have been a backdoor at this point.)

Good point, forgot how brittle the other curves were. I believe many require unbiased randomness or something?

> I haven't spoken to a cryptographer who believes the NIST curves are backdoored

From what I can infer, I would say this is highly unlikely. That still leaves enough room for things to be interesting, so… nope. I won't touch NIST curves willingly with my current knowledge.

No, the NIST curves simply can't use random strings as points at all: randomly chosen vectors can be points that aren't valid on the intended curve, but rather on curve of much smaller order; repeatedly submitting insecure curve points can allow attackers to recover private keys via CRT. It's a pretty awesome attack and not hard to implement in a test environment.

The unbiased randomness issue is with the ECDSA construction, which requires a totally, uniformly random k value for every signature. Bernstein's Ed25519 construction is deterministic, and doesn't have this problem.

I don't think the backdoor in the NIST curves, if any, is that the curves themselves are not secure, but that they are so hard to implement that it's practically guaranteed that implementations have more-or-less critical issues / side channels.

But that's pretty much true of all the curves of that vintage, right?

Yes. It's also hard to know whether "they" didn't try "hard enough" to get "better" curves or whether "they" didn't know any better(†) or whether "they" intentionally made these "bad" curves. That's why I don't want to call it a backdoor.

(†) We know that historically NSA had secret cryptography knowledge, the most famous example being differential cryptanalysis and the subsequent hardening of DES (although IBM also knew about that). Since it's a secret agency we cannot know the current state of their secret knowledge; my gut tells me though that since crypto has become a much more open/scientific discipline in the last 10-15 years that they probably don't have much of that anymore.

Why Blake rather than Keccak? (Maybe I missed some reason why it's a good idea to avoid the latter.)

I have no good reason to avoid Keccak. As far as I know, it is safe. It did win SHA3 after all. On the other hand, all SHA3 finalists were deemed good enough, and the reasons for Keccak's victory was in part to promote diversity —which I can understand. I couldn't just ignore the other finalists.

I've heard that Blake was faster than MD5, and just as safe as Keccak. That decided it. I'm glad I did it, because the code is simple, and turned out to use the same ARX design as Chacha20.

Now I can imagine using Keccak instead. But then I'd be tempted to base the entire symmetric cipher-suite on the sponge construction, to share code and cryptanalysis.

Reply on news.ycombinator.com