3 ms·

Why is it necessary to volunteer expert time every time someone publishes a new piece of code that by their own admission is not a significant improvement over

by lvh 10y ago

Why is it necessary to volunteer expert time every time someone publishes a new piece of code that by their own admission is not a significant improvement over TweetNaCl? Time is limited; if something doesn't do a good job arguing why you need it, pointing people to things that are packaged, updated, have been consistently maintained and reviewed is _solid engineering advice_.

Cyph0n 10y ago
> Why is it necessary to volunteer expert time every time someone publishes a new piece of code I would agree if the author presented a very clearly flawed and poorly thought out implementation, but this is clearly not the case here. There is a quality threshold after which spouting out "No, use NaCl!" becomes a waste of time. > by their own admission is not a significant improvement over TweetNaCl? Not everything in the real world has to be a significant improvement. > [...] if something doesn't do a good job arguing why you need it Not everyone is good at marketing his/her creations. It's pretty tough to do well in my opinion, and there's always "that guy" who's never satisfied by any explanation. > [...] _solid engineering advice_ I would agree with you in most other scenarios, but the author of this library mentioned NaCl in the first paragraph. The author also took the time to list the motivation behind this work, as well as the reasons why this could provide potential improvements over prior work. So I don't see how "NO, use NaCl!" is 'solid' advice in this case.
- lvh 10y ago
  But we've engaged with those motivations, and found them lacking -- so libsodium is still what tqbf and I recommend. (Not NaCl! libsodium is sufficiently interestingly different that you should use it, not NaCl.) It is not true that any attempt at new crypto software will just be shut down; for example, I think Noise is awesome. I think STROBE is pretty cool too, but I'm not telling people to implement STROBE. I'm telling people to use libsodium. Telling people to use the probably-already-packaged, carefully reviewed, random-nonce supporting package they had available yesterday _is_ solid engineering advance, and I stand by that claim.
  - Cyph0n 10y ago
    I definitely agree that going around adopting freshly written and poorly tested crypto libraries is A BAD IDEA EVERY TIME. Absolutely no argument there. I still got a very "stop what you're doing and move on" vibe from the parent comment as well as the response on the Reddit thread, and I feel that it wasn't fair in this case. I apologize if I misunderstood.
    - lvh 10y ago
      To go back to said comment to see what was actually said: > First: it needs to be made clearer why anyone would use this rather than Nacl/Sodium. ... and a comment about how a few test vectors is not a serious cryptographic audit. So it seems that the parent agrees with you, and nobody told anyone to stop doing what we're doing. The thing we (well, I; I don't want to put words in tqbf's mouth) did say repeatedly, is "the answer is still libsodium". It seems like that, too, is something you agree with.
      - Cyph0n 10y ago
        I'm sure that could have been phrased in a way that got the point across without patronizing the submitter. I wonder how many potentially great cryptographers had their ambitions killed off because of statements like this?
        lvh 10y ago
        Which patronizing statement? Is "it needs to be made clear..." patronizing? Surely asking why you'd want to use something is reasonable.
  - loup-vaillant 10y ago
    > random-nonce supporting package Wait a minute, what's that? Does it just mean nonces big enough to be random, or something more I should consider for inclusion in Monocypher?
    - 10y ago
loup-vaillant 10y ago
> 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.

by lvh 10y ago

Cyph0n 10y ago

> Why is it necessary to volunteer expert time every time someone publishes a new piece of code I would agree if the author presented a very clearly flawed and poorly thought out implementation, but this is clearly not the case here. There is a quality threshold after which spouting out "No, use NaCl!" becomes a waste of time. > by their own admission is not a significant improvement over TweetNaCl? Not everything in the real world has to be a significant improvement. > [...] if something doesn't do a good job arguing why you need it Not everyone is good at marketing his/her creations. It's pretty tough to do well in my opinion, and there's always "that guy" who's never satisfied by any explanation. > [...] _solid engineering advice_ I would agree with you in most other scenarios, but the author of this library mentioned NaCl in the first paragraph. The author also took the time to list the motivation behind this work, as well as the reasons why this could provide potential improvements over prior work. So I don't see how "NO, use NaCl!" is 'solid' advice in this case.

lvh 10y ago
But we've engaged with those motivations, and found them lacking -- so libsodium is still what tqbf and I recommend. (Not NaCl! libsodium is sufficiently interestingly different that you should use it, not NaCl.) It is not true that any attempt at new crypto software will just be shut down; for example, I think Noise is awesome. I think STROBE is pretty cool too, but I'm not telling people to implement STROBE. I'm telling people to use libsodium. Telling people to use the probably-already-packaged, carefully reviewed, random-nonce supporting package they had available yesterday _is_ solid engineering advance, and I stand by that claim.
- Cyph0n 10y ago
  I definitely agree that going around adopting freshly written and poorly tested crypto libraries is A BAD IDEA EVERY TIME. Absolutely no argument there. I still got a very "stop what you're doing and move on" vibe from the parent comment as well as the response on the Reddit thread, and I feel that it wasn't fair in this case. I apologize if I misunderstood.
  - lvh 10y ago
    To go back to said comment to see what was actually said: > First: it needs to be made clearer why anyone would use this rather than Nacl/Sodium. ... and a comment about how a few test vectors is not a serious cryptographic audit. So it seems that the parent agrees with you, and nobody told anyone to stop doing what we're doing. The thing we (well, I; I don't want to put words in tqbf's mouth) did say repeatedly, is "the answer is still libsodium". It seems like that, too, is something you agree with.
    - Cyph0n 10y ago
      I'm sure that could have been phrased in a way that got the point across without patronizing the submitter. I wonder how many potentially great cryptographers had their ambitions killed off because of statements like this?
      - lvh 10y ago
        Which patronizing statement? Is "it needs to be made clear..." patronizing? Surely asking why you'd want to use something is reasonable.
- loup-vaillant 10y ago
  > random-nonce supporting package Wait a minute, what's that? Does it just mean nonces big enough to be random, or something more I should consider for inclusion in Monocypher?
  - 10y ago

loup-vaillant 10y ago

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