Percival Ptacek Latacora
2009 2015 2018
Online backups tarsnap tarsnap tarsnap
Symmetric key length 256-bit 256-bit 256 bit
Symmetric “Signatures” HMAC HMAC HMAC
Random IDs 256-bit 256-bit 256-bit
Hashing algorithm SHA256 (SHA-2) SHA-2 SHA-2
Password handling scrypt scrypt scrypt
PBKDF2 bcrypt argon2
Website security OpenSSL OpenSSL AWS ALB/ELB
AWS ELBs LetsEncrypt
Client-server OpenSSL OpenSSL AWS ALB/ELB
app security BoringSSL OpenSSL
AWS ELBs LetsEncrypt
Asymmetric encryption  NaCl/libsodium NaCl/libsodium
Asymmetric signatures  NaCl NaCl
Diffie-Hellman  DH-2048 Nothing
Encrypting Data: AES-CTR HMAC NaCl/libsodium default KMS
 RSASSA-PSS with SHA25 or MGF1+SHA256 in tricolor systemic silicate orientation
 2048-bit Group #14 with a generator or 2
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.
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.
If you're looking for a recommendation: just use OpenSSL and keep it up to date.
I love that I can't instantly tell which of those three footnotes is a real thing.
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?)