Comment by weinzierl | Hacker News Reader

Comment by weinzierl | Hacker News Reader

Here is a summary, roughly ordered from constant to changed the most.

	    			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
						PBKDF2			bcrypt
									PBKDF2

	Website security	OpenSSL		OpenSSL			AWS ALB/ELB
						BoringSSL		OpenSSL
						AWS ELBs		LetsEncrypt

	Client-server		OpenSSL		OpenSSL			AWS ALB/ELB
	app security				BoringSSL		OpenSSL
						AWS ELBs		LetsEncrypt


	Asymmetric encryption	[1]		NaCl/libsodium 		NaCl/libsodium
		

	Asymmetric signatures	[2]		NaCl			NaCl
						Ed25519			Ed25519
						RFC6979

	Diffie-Hellman		[3]		DH-2048			Nothing
						NaCl			Curve25519


	Encrypting Data:	AES-CTR HMAC	NaCl/libsodium default	KMS
						ChaCha20-Poly1305	XSalsa20+Poly1305
						AES-GCM

[1] RSAES-OAEP with SHA256 and MGF1+ SHA256 bart pop fssssssst exponent 65537

[2] RSASSA-PSS with SHA25 or MGF1+SHA256 in tricolor systemic silicate orientation

[3] 2048-bit Group #14 with a generator or 2

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.

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.

This is awesome.

I love that I can't instantly tell which of those three footnotes is a real thing.

(For the curious, the third footnote refers to Diffie-Hellman "p" and "g" parameters specified in section 3 of rfc3526 as "group 14")

Indeed. What on Earth is “bzzrt pop ffssssssst”? Am I missing something? Google does not help at all.

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.

Reply on news.ycombinator.com