Hacker News Reader

Comment by tptacek | Hacker News Reader

No. Not only is Sodium (more accurately: NaCl) not a TLS library, but it doesn't even implement the primitives that TLS needs; it can't really even serve as a component of another TLS library.

View on HN

Not that you're not absolutely right about NaCl & Sodium, but isn't the GP talking explicitly about Sodium and not NaCl?

When you say 'more accurately: NaCl', is there something particular you're getting at, or are you speaking from experience of NaCl rather than Sodium (or are you talking about the fact that the bindings seem to be named/built for the original NaCl?)

Edit: or do you just think it's still better to call it NaCl given that it's a fork of, or I suppose a refined implementation of NaCl?

it's more accurate to discuss NaCl since that's what libsodium is. NaCl is the combination of crypto primitives and the "box" abstraction. libsodium is just the repackaging and clean-up of the original NaCl implementation. If you're discussing crypto, you're going to be looking at the papers on NaCl.

Mm that's roughly the impression I got, but I hadn't thought of the papers - thanks for the clarification!

Any SSL implementation worth its salt needs to implement historical primitives like RC4 and MD5. libsodium will not and should not implement these because they conflict with the goal of providing an idiot-proof crypto library.

This has nothing to do with what I asked. Also, this I know. Sorry? :P

Isn't it better to not include stuff that's insecure, even if they have historic value? Isn't this a big part of the problem of some (even OpenSSL) software?

Reply on news.ycombinator.com