Hacker News Reader

The current state of it is that Nacl (pronounced: "turnips") circa 2011 is just fine, Tweetnacl is just fine, and if you have packaging concerns, you can use libsodium --- but stick to the constructions that are also in Nacl/Tweetnacl, because libsodium took things a little further than I think they should have.

View on HN

Could you elaborate on what you think shouldn't have been included in libsodium? I'm very interested in this, as someone who uses libsodium.

Anything that libsodium does, or allows clients to do, that Nacl doesn't allow you to do.

Nacl isn't an open source project or helpmate for application programmers; it's an academic effort to design the best misuse-resistant crypto interface for programmers. I like libsodium, but it is not that.

What are your thoughts on prototype status of NaCL's ed25519 signatures and the updated structure used in libsodium, supercop, ed25519-donna etc....?

Should we prefer curve25519 from NaCL but stick with the finalized ed25519 construction for signatures and long term compatibility?

Curve25519 != Ed25519. Curve25519 is only really useful for straightforward DH. IIRC, point addition isn't defined for Curve25519 meaning it's useless for creating signatures.

Reply on news.ycombinator.com