4 ms·

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

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.

amenonsen 10y ago
Why Blake rather than Keccak? (Maybe I missed some reason why it's a good idea to avoid the latter.)
- loup-vaillant 10y ago
  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.
tptacek 10y ago
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.)
- loup-vaillant 10y ago
  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.
  - tptacek 10y ago
    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.
- throwawayish 10y ago
  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.

amenonsen 10y ago

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

loup-vaillant 10y ago
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.

tptacek 10y ago

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.)

loup-vaillant 10y ago
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.
- tptacek 10y ago
  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.
throwawayish 10y ago
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.