Quick update though: for client-server security, I copy-paste misquoted Colin and just now noticed it (because Colin noticed it for me). The 2015 document correctly says Colin's client-server recommendation is "custom RSA protocol", but when I formatted this document I managed to accidentally make it say the same as his recommendation for "website security".
I regret the error (but not the recommendation; don't make your own custom RSA-based transport protocol).
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.
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.
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.
It's a joke. The joke is that RSA seems familiar, comfortable. Except actually there's a bunch of super subtle ways to mess it up, like padding, or primegen bugs. The bzzrt pop is just a reference to all of the exceptions and caveats, which all sound like arcane incantations instead of straightforward recommendations and are therefore no longer in this document.
Percival 2009 is http://www.daemonology.net/blog/2009-06-11-cryptographic-rig... - the actual summary recommendation is "Use RSAES-OAEP with SHA256 as the hash function, MGF1+SHA256 as the mask generation function, and a public exponent of 65537. Make sure that you follow the decryption algorithm to the letter in order to avoid side channel attacks."
I assume the misquote is making fun of how long that description is compared to, like, "Use 256-bit AES keys." or "Use OpenSSL." (What specific thing in the decryption algorithm should I be making sure I don't misread in order to avoid side channel attacks?)
That, and the fact that nobody who uses RSA appears to follow that recommendation --- by far the most common RSA construction is (broken) P1v15 padding.
[2] RSASSA-PSS with SHA25 or MGF1+SHA256 in tricolor systemic silicate orientation
[3] 2048-bit Group #14 with a generator or 2