4 ms·

> someone publishes a new piece of code that by their own admission is not a significant improvement over TweetNaCl? That one is a tough call for me. If I bra

> someone publishes a new piece of code that by their own admission is not a significant improvement over TweetNaCl? That one is a tough call for me. If I brag too much, I can be dangerous. Too little, and nobody uses my stuff. I'm not sure about the significance of the improvements, but they are undeniable: except for curve25519, everything is more readable, faster, and a bit more useable than TweetNaCl (curve25519 is merely more usable). There is also one significant contribution I did not brag too much about: my Argon2i implementation is much simpler than the reference implementation. I'm considering adding support for multiple lanes (maybe with threads, maybe not), and Argon2d. The result should be RFC worthy. Was re-implementing Argon2i from scratch good engineering practice? I don't know. What I do know is that I ended up uncovering a long standing bug in the reference implementation; one that complicates implementations and hurt security a little bit. I think Monocypher was worth the effort, even if just for Argon2.

lvh 10y ago
The Argon2 improvements are interesting and I'd love to hear about them. Re: usability of other core primitives: I'll bite. Places where you don't get to solve a hard coordination problem to agree on a nonce matters. I know you document that you can't use a random nonce (and that's accurate), but I think that is an important safety regression.
- loup-vaillant 10y ago
  > I know you document that you can't use a random nonce Looking back at my manual, I understand it was easy to miss. But you can. You just have to use XChacha20, which gives you a 192-bit nonce, where the chance of collision even after 2⁶⁴ messages is negligible. The high level constructions all use XChacha20, so random nonces are possible. I really should re-arrange the order of presentation. The slightly better usability mainly referred to the fact that functions that cannot fail return void. It's small, but the user is not left wondering whether the return value should be checked, or why the manual doesn't say anything about it. I tried to make the ordering of arguments consistent across the whole library. Easier interfaces have shorter names (no "easy" suffix). Then there are opinions. Primitive functions are named after the primitive, because I don't believe in hiding those to the user. Fixed sizes are hard coded, because I don't expect them to change without changing the primitive itself. Constants like CRYPTO_ENCRYPTION_KEY_SIZE obscure the point somewhat.
- Rafert 10y ago
  Seems to be https://www.reddit.com/r/crypto/comments/5m8f32/found_a_small_error_in_argon2_spec/ https://www.reddit.com/r/crypto/comments/5m8f32/found_a_smal...

lvh 10y ago

The Argon2 improvements are interesting and I'd love to hear about them. Re: usability of other core primitives: I'll bite. Places where you don't get to solve a hard coordination problem to agree on a nonce matters. I know you document that you can't use a random nonce (and that's accurate), but I think that is an important safety regression.

loup-vaillant 10y ago
> I know you document that you can't use a random nonce Looking back at my manual, I understand it was easy to miss. But you can. You just have to use XChacha20, which gives you a 192-bit nonce, where the chance of collision even after 2⁶⁴ messages is negligible. The high level constructions all use XChacha20, so random nonces are possible. I really should re-arrange the order of presentation. The slightly better usability mainly referred to the fact that functions that cannot fail return void. It's small, but the user is not left wondering whether the return value should be checked, or why the manual doesn't say anything about it. I tried to make the ordering of arguments consistent across the whole library. Easier interfaces have shorter names (no "easy" suffix). Then there are opinions. Primitive functions are named after the primitive, because I don't believe in hiding those to the user. Fixed sizes are hard coded, because I don't expect them to change without changing the primitive itself. Constants like CRYPTO_ENCRYPTION_KEY_SIZE obscure the point somewhat.
Rafert 10y ago
Seems to be https://www.reddit.com/r/crypto/comments/5m8f32/found_a_small_error_in_argon2_spec/ https://www.reddit.com/r/crypto/comments/5m8f32/found_a_smal...