Ryan Sleevi writes:

What use case makes the "NaCl" algorithms (whose specification is merely 'use NaCl', which boils down to "Use Salsa+Curve25519") worthwhile?

Here's the abstract of "The security impact of a new cryptographic library" (http://cr.yp.to/highspeed/coolnacl-20120725.pdf): This paper introduces a new cryptographic library, NaCl, and explains how the design and implementation of the library avoid various types of cryptographic disasters suffered by previous cryptographic libraries such as OpenSSL. Specifically, this paper analyzes the security impact of the following NaCl features: no data flow from secrets to load addresses; no data flow from secrets to branch conditions; no padding oracles; centralizing randomness; avoiding unnecessary randomness; extremely high speed; and cryptographic primitives chosen conservatively in light of the cryptanalytic literature. The paper cites and analyzes cryptographic failures in SSH, ECDSA in SSL, RSA in SSL, Linux disk encryption, the PlayStation 3, et al. What's particularly convincing is to look at _newer_ failures, such as the very recent "Lucky 13" attack recovering plaintext from SSL, and observe that those failures would have been prevented by precisely the NaCl features identified in this document. ("Lucky 13" relies on padding oracles and on these prohibited forms of data flow.) These NaCl features are at a quite different level from the "features" advertised by cryptographic APIs from the dark ages (e.g., "we support MD5 and RSA-512"), and in many cases are in direct conflict with those "features". This is one of the reasons that NaCl has a simple high-level API. Of course, simplicity has other benefits. As for specification, there's a state-of-the-art "Cryptography in NaCl" document (http://cr.yp.to/highspeed/naclcrypto-20090310.pdf) that has complete self-contained definitions of every aspect of key generation, encryption, and authentication involved in NaCl's crypto_box(); plus an end-to-end example expressed both as * self-contained Python/Sage test scripts that compute every detail of the crypto and * simple test programs using NaCl, of course producing the same results; plus security notes. Someone who wants to write a new implementation that interoperates with crypto_box() doesn't need to read anything else. I'm not saying that this is the end of the story---implementors should also learn about crypto_sign(), constant-time code, and more---but it's way ahead of the documentation mess that one has to read to reimplement other existing protocols with similar functionality.

And how can we be sure that the problems that NaCl sets out to solve are the same problems developers want or need to solve, especially when all the evidence suggests otherwise?

The main reason for a developer to use a cryptographic library is to protect data against espionage, sabotage, etc. There's ample evidence that most cryptographic libraries _don't_ actually manage to protect data---and imitating their decisions is simply going to produce more security disasters. Of course, this doesn't imply that NaCl is what developers want, but high-profile applications such as DNSCrypt are in fact using NaCl in ways that seem easily generalizable to other applications. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE