Comment by cperciva | Hacker News Reader

Comment by cperciva | Hacker News Reader

Parent Full thread

I regret the error (but not the recommendation; don't make your own custom RSA-based transport protocol).

I think this is our largest point of divergence. If the world had sane TLS libraries, I would absolutely say "run TLS with all the backwards compatibility crap turned off" -- but we don't have sane TLS libraries. I am not confident in my ability to turn off all the unwanted "features" of SSL/TLS stacks, and I'm not confident that anyone can write code which will turn off all the unwanted features and keep them turned off in future library versions. It's not much of an exaggeration to say that I consider the OpenSSL maintainers to be actively hostile; if I have to run their code at all I really want it to be inside a sandbox.

Yes, writing your own transport protocol is nontrivial. But if you write your own transport protocol, you don't need to worry about "the user upgraded to a new version of OpenSSL and now your connections are all HeartBleeding". A sane library would have had this feature turned off by default; OpenSSL is not a sane library.

I think this is our largest point of divergence.

While I'm on the topic:

Password handling: I skip bcrypt because the only reason to not use scrypt is if you need a US Government endorsed scheme. But yeah, it's (slightly) better than PBKDF2.

Cryptographic primitives: I think "use NaCl" is cheating a bit as far as answers go; that may be reasonable advice to implementors but it's not a protocol specification. So I'm reading those as "use foo, via the NaCl library".

As for what the foo in question should be: I'm gradually becoming more comfortable with curves, and 25519 in particular; similarly with sbox-free symmetric crypto (e.g., djb's dances and Keccak). At this point I'd say it comes down to how conservative you are; I wouldn't say that someone using XSalsa20+Poly1305 is wrong to do so.

To be pedantic, Keccak does have a 5 to 5 bit S-box. But like 3-Way, NOEKEON, Serpent, etc, it's disguised---bitsliced---as a short sequence of boolean operations.

If you want to be really pedantic, every boolean operation is just a 2->1 bit S-box...

Is there not a recommended replacement library for OpenSSL? I'm thinking of LibreSSL for example that has leaner API but probably not the same amount of resources as OpenSSL.

Go's tls library is fine, but that's not really an OpenSSL replacement. Just use OpenSSL. BoringSSL is fine if you're its audience, but if you are you don't need me to tell you that :) Finally: LibreSSL is the result of a set of circumstances that have changed.

If you're looking for a recommendation: just use OpenSSL and keep it up to date.

Reply on news.ycombinator.com