3 ms·

The scary warnings from cryptographers specifically pointed people at NaCl's high-level APIs like crypto_box and warned of the dangers of rolling your own compo

by makomk 10y ago

The scary warnings from cryptographers specifically pointed people at NaCl's high-level APIs like crypto_box and warned of the dangers of rolling your own compositions of primitives. You can do that just as well or badly with almost any major crypto library, but the point of the NaCl advocacy was to steer inexperienced people away from that towards higher-level constructions. So that's what the Tox developers did: they used the high-level, safe, supposedly misuse resistant crypto_box API's implementation of public-key authenticated encryption. And it blew up in their faces, and then you accused them of incompetently rolling their own crypto because, essentially, they didn't roll their own crypto and the pre-baked version turned out to be horrifically unsuitable for actual use. They do not use crypto_scalarmult directly anywhere, and stuff like hashing group elements is done however DJB felt appropriate when he was writing the high-level composition of primitives.

detaro 10y ago
For context for other readers: https://nacl.cr.yp.to/box.html https://nacl.cr.yp.to/box.html and I assume the relevant quote is The crypto_box function is not meant to provide non-repudiation. On the contrary: the crypto_box function guarantees repudiability. A receiver can freely modify a boxed message, and therefore cannot convince third parties that this particular message came from the sender. The sender and receiver are nevertheless protected against forgeries by other parties. In the terminology of https://groups.google.com/group/sci.crypt/msg/ec5c18b23b11d82c https://groups.google.com/group/sci.crypt/msg/ec5c18b23b11d8..., crypto_box uses "public-key authenticators" rather than "public-key signatures." Users who want public verifiability (or receiver-assisted public verifiability) should instead use signatures (or signcryption). Signature support is a high priority for NaCl; a signature API will be described in subsequent NaCl documentation.
lvh 10y ago
You appear to be repeating your argument almost verbatim. I've gone into detail why this doesn't hold. Furthermore, I think you'll find I did not accuse anyone of incompetence, I have merely been explaining the issue repeatedly and in detail kindly and courteously. I refuse to take responsibility for what other people say, and I have continuously and repeatedly offered my services, for free, and literally wrote a book and then gave it away for free. If people want to discuss security, I'm game. But given the amount of energy I've spent removing the discussion from individuals and bringing it back to technology, I do not have to put up with having a bunch of accusations leveled at me.

by makomk 10y ago

detaro 10y ago

For context for other readers: https://nacl.cr.yp.to/box.html https://nacl.cr.yp.to/box.html and I assume the relevant quote is The crypto_box function is not meant to provide non-repudiation. On the contrary: the crypto_box function guarantees repudiability. A receiver can freely modify a boxed message, and therefore cannot convince third parties that this particular message came from the sender. The sender and receiver are nevertheless protected against forgeries by other parties. In the terminology of https://groups.google.com/group/sci.crypt/msg/ec5c18b23b11d82c https://groups.google.com/group/sci.crypt/msg/ec5c18b23b11d8..., crypto_box uses "public-key authenticators" rather than "public-key signatures." Users who want public verifiability (or receiver-assisted public verifiability) should instead use signatures (or signcryption). Signature support is a high priority for NaCl; a signature API will be described in subsequent NaCl documentation.

lvh 10y ago

You appear to be repeating your argument almost verbatim. I've gone into detail why this doesn't hold. Furthermore, I think you'll find I did not accuse anyone of incompetence, I have merely been explaining the issue repeatedly and in detail kindly and courteously. I refuse to take responsibility for what other people say, and I have continuously and repeatedly offered my services, for free, and literally wrote a book and then gave it away for free. If people want to discuss security, I'm game. But given the amount of energy I've spent removing the discussion from individuals and bringing it back to technology, I do not have to put up with having a bunch of accusations leveled at me.