[bsder]

I would go for TweetNaCl instead.

The problem I have with most of the crypto libraries is that their attack surface is absolutely enormous.

Most people don't need SSL. Most people don't need a zillion choices.

Most people need a single choice that actually works and is resistant to programmer error.

[mtrpcic]

Isn't the attack surface limited to the methods used in the application though? Even if libsodium has a vulnerability in some ABC method, unless the application in question uses that code path, it's not an immediate risk (Obviously it should get patched and stable, secure software is preferred over the alternative). I'm just trying to understand how the "attack surface" is calculated, and how a potential vuln in an unused method is a huge risk.

[bsder]

> Isn't the attack surface limited to the methods used in the application though?

No, because the combination of how you put them together can make you vulnerable.

For example, if you are encrypting lots of messages that all have the same header, certain crypto algorithms can be made to leak the key.

Do you know which combinations those are? I sure don't by default.

The fact that an end programmer even has to think about this is the problem.

In any cryptosystem, the application programmer is the person who knows the least about crypto. If he has to make any decision, you can expect he will get it wrong.

[cvwright]

Good points. I was about to say something about how libsodium will take care of most of that for you.

For example, I thought they provided some facility for avoiding nonce reuse vulnerabilities by automatically generating pseudorandom nonces for the user.

But then I double checked their API docs and they don't do this at all! Argh!

[cjbprime]

Look into the history of OpenSSL vulns -- many are in obscure TLS paths that application developers did not intend to be supporting.

I think Heartbleed's even an example? Apparently there's some TLS ping ("heartbeat") command in the protocol that I'm pretty sure no-one actually asked for or uses in their applications, but there it is in the code, and so you're vulnerable as an application author.

[derefr]

That's a different kind of thing—TLS is an extensible protocol, where its various extensions (i.e. code paths) are activated by patterns of data on the wire. libsodium is just a set of components—you can know at compile time exactly which functions in libsodium will or will not ever be called by your program, and can, if you like, use a linker that does LTO to prune the majority of the library out.