Hacker News new | past | comments | ask | show | jobs | submit login

While the rule for devs is, "never roll your own crypto", what is the authoritative resource for what we should use?



It depends on what you're trying to accomplish.

Rule of thumb is: just use TLS 1.3 if you can. That includes using TLS 1.3 in mutual auth mode if you need to validate both client and server identities. It comes with a lot of PKI for free to help address the "how do you know you can trust the other guy on the line?" problem. If you want the client/server to trust a restricted list of servers/clients, most clients and servers have that capability.

If SSL/TLS won't suffice and you just need to create an end to end "thing" with proof of identity, then libsodium is probably fine.

If you're looking for a more general purpose crypto library where you need to mix and match algorithms, I'd recommend something like Google Tink (https://github.com/google/tink), or the high level interface to the native API's that come with the OS. On OS X that's the native security framework (https://developer.apple.com/documentation/security), and on Windows that's the .NET cryptography library (https://docs.microsoft.com/en-us/dotnet/api/system.security....).

If you need even more flexibility and are willing to do the research to avoid the footguns, there's always OpenSSL/LibreSSL, but that comes with a huge footgun warning.


> It comes with a lot of PKI for free to help address the "how do you know you can trust the other guy on the line?"

I would hesitate to trust a high stakes system (like, controlling a regional power grid) with TLS's default PKI. There are hundreds of certificate authorities out there, all of which can vouch for everything. Compromising one certificate authority is enough to mount a man in the middle attack.

Granted, this is not a trivial attack, and TLS as it is now is mostly sufficient for your regular online shopping. More critical applications however need a dedicated PKI.


Absolutely, which is why I included the extra point:

If you want the client/server to trust a restricted list of servers/clients, most clients and servers have that capability.

If you are running a regional power grid, TLS as a technology is still fine, but you should absolutely not trust the default PKI.


Oops, missed that, sorry.


> Trail of Bits recommends using Curve25519 for key exchange and digital signatures. Encryption needs to be done using a protocol called ECIES which combines an elliptic curve key exchange with a symmetric encryption algorithm. Curve25519 was designed to entirely prevent some of the things that can go wrong with other curves, and is very performant. Even better, it is implemented in libsodium, which has easy-to-read documentation and is available for most languages.

(it's unclear from the text whether ECIES is implemented in libsodium or only Curve25519, the internet seems to believe nacl (/libsodium) implements its own superior variant of ECIES called crypto_box)


ECIES is part of a family of things that are all more or less just ElGamal with a symmetric primitive attached. libsodium implements one version of that with Curve25519 + secretbox (which in turn is XSalsa20.) It's really mostly just superior in the sense that it's a) fully specified, including test vectors b) all the knobs twiddled for safety, c) incidentally, very performant.


I don't think ECIES uses any PKI. The setup is: given a DH pubkey P, generate a DH ephemeral key Q, do the DHKE to derive k, encrypt your message m, then send (Q, E_k(m)).


It doesn't, but I also didn't say it did?


My bad, I meant to say that it doesn't use any public key encryption like ElGamal. Or at least, I've only ever seen ECIES implemented with ECDH + symm enc




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: