A crypto library aimed at auditability

Posted Jan 9, 2014 22:53 UTC (Thu) by graydon (guest, #5009)
In reply to: A crypto library aimed at auditability by wahern
Parent article: A crypto library aimed at auditability

People regularly develop new programs that interoperate with themselves or a small set of programs developed simultaneously. Even SSL was once just a single implementation.

New formats and protocols should look at NaCl (and TweetNaCl) seriously. It's small, fast, unencumbered, uses modern algorithms with high security levels, and has removed all the API options and permutations that are easy to misuse in larger crypto libraries.

to post comments

A crypto library aimed at auditability

Posted Jan 9, 2014 23:00 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Yup. We're using it here for our protocol. For instance, it's trivially easy to serialize the NaCL state and transfer it between processes.

That way we can use a fast C++-based daemon to negotiate a connection and then send the socket and corresponding crypto keys to a slower Python-based worker process.

We tried to look for a way to serialize OpenSSL state (it should be possible, theoretically) but ran away in horror. Other TLS implementations are not really much better, since the protocol itself is pretty complicated.

A crypto library aimed at auditability

Posted Jan 9, 2014 23:20 UTC (Thu) by wahern (subscriber, #37304) [Link] (1 responses)

So which is more secure as a general matter, inventing a new protocol so you can have the satisfaction of using DJBs library, or using TLS or some other existing standard? I don't know what the answer is, despite my snarky tone. But most of the bugs with OpenSSL have been in their protocol code; and unlike most cryptographic libraries they've been exceptionally responsive to fixing side-channel attacks of their underlying primitives. So as ugly as OpenSSL is, their record isn't as bad as people tend to think.

Once upon a time cryptologic best practice said that protocols should be able to negotiate for different underlying primitives. The notion was that as primitives slowly fell to attack they could be swapped out.

DJB tended to take a different stance: he preferred a single primitive for any task which was 1) more conservative by design than competing algorithms but 2) could be tuned to increase or decrease security. But his submissions never make it far in standards competitions. He designs his algorithms and protocols with a holistic methodology, but that model doesn't fit well with the typical method of developing standards, where people agglomerate small pieces from here and there and stitch them together.

I doubt in 5 years NaCl will still be on people's radar. OpenSSL will still be with us. DJBs works with ECC in general will, I'm sure, have lasting effect. See http://safecurves.cr.yp.to/

Side note: OpenBSD recently replaced refactored their arc4random interface to use a PRNG based on DJB's ChaCha20 stream cipher. DJB also designs his algorithms to be tiny, so it's easy to drop a single source file (or even cut+paste the algorithm) into your project. No need to even create a dependency on a larger library.

A crypto library aimed at auditability

Posted Jan 9, 2014 23:58 UTC (Thu) by graydon (guest, #5009) [Link]

I am not suggesting "inventing a new protocol so you can use NaCl". I'm suggesting that if you're in a position to be selecting openssl (or one of its large competitors) as a library of raw cryptographic functions, while implementing a custom protocol, file format or message format yourself, you may also want to give NaCl a look, for the same role.

If you just want a stock cryptographic tunnel to send some bytes over a socket without being overheard, of course there are well-debugged programs that talk to file descriptors, and there's little reason to even know what the internal crypto libraries are, much less how their APIs are organized.