6 comments

[ 2.8 ms ] story [ 23.8 ms ] thread
Text of his announcement:

Hi everybody,

I've posted information about CurveCP at http://curvecp.org; and today's release of NaCl includes command-line curvecpclient and curvecpserver tools. There are many reasons that this curvecpclient+curvecpserver software isn't ready for users yet---among other things,

  * the software hasn't gone through anywhere near my usual levels of
    testing and security review;
  * the software prioritizes simplicity over efficiency in several
    ways, missing some of the speed that CurveCP can provide; and
  * the software handles only CurveCP, without HTTPCurve, SMTPCurve,
    etc.
---but if you're a programmer interested in CurveCP then I think this software is a reasonable starting point for experimentation and further development.

---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago

For a moment there I thought he was talking about the other NaCl, which didn't seem like a very djb-like project.
Isn't the point to have this work below the application layer? We have to make a new encrypted and authenticated transport layer and also rewrite all of the application protocols?

Then again, with key distribution being done with nym urls the network stack is more like a tangled ball of yarn.

And NaCl now has signatures based on curve25519: crypto_sign_edwards25519sha512batch.
The short summary of CurveCP is that it's essentially an encrypted and authenticated TCP[1] (tunneled over UDP). The main selling point is that it's fast, partly by clever protocol design and mostly by use of highly-efficient elliptic curve cryptography.

It's really cool, but sadly probably doomed to obscurity - unencrypted TCP/SSL/IPSec are "good enough".

[1] Actually, Dan Kaminsky stated that it's perfectly usable as a UDP replacement.