[michaelt]

I've always found it a bit disquieting how many times people feel the need to update these "cryptographic right answers" blog posts.

This is what, a fourth or fifth version since 2009?

Meanwhile everything from ubuntu's apt-get to my connection to HN is secured with 2048-bit RSA - an algorithm invented in 1977 and in widespread use since at least 1995.

Am I getting crypto advice that will keep my data safe for 30+ years, if the advice changes every 3 years?

[tptacek]

Yes. It's past time for this concept to be put to rest. It started out as a joke and has taken on a life of its own; moreoever, it has looped back over onto itself, to the point where it's advocating a sort of DIY SOTA vibe that is going to get people hurt --- the opposite of what the joke was going for originally.

[mwcampbell]

I suspect that cperciva, who wrote the first "cryptographic right answers" post in 2009 and doesn't seem to have intended it as a joke, would disagree.

[tptacek]

Yes, and I wrote the next two. The joke was about Colin's post --- "these 'right answers' are neither common best practices nor what cryptographic hipsters are advocating". The joke has always been "these should be titled Colin's Right Answers or Thomas' Right Answers [eek]" or whatever.

Nobody has deliberately included bad advice. That's not what I'm saying.

[slooonz]

> Meanwhile everything from ubuntu's apt-get to my connection to HN is secured with 2048-bit RSA - an algorithm invented in 1977 and in widespread use since at least 1995.

That’s a bit misleading, considering RSA is only used for certificate verification. Key exchange and symmetric encryption is handled by somewhat more recent algorithms (ECDH / AES-GCM).

[kientuong114]

The right answer is not always about straight-out security: 2048-bit RSA is not broken and won't be broken for the foreseeable future, but we know that it is much less efficient and more error-prone than e.g. ECDH. So why suggest the former when the latter is a better alternative?

You should consider these "right answers" as if the question were, "I want to develop a new product today. What cryptographic primitive should I use?"

[SAI_Peregrinus]

Even that is more subtle. RSASSA-2048-PKCS#1v1.5 is fine if leaking that you signed the same plaintext more than once isn't a threat. If that is a threat then you need RSASSA-2048-PKCS#1v2, (AKA RSA-PSS-2048).

RSAES-2048-PKCS#1v1.5 has implementation-dependent security; implementations keep getting broken due to padding oracle attacks. RSA-KEM-2048 is fine, though slower than ECDH.

[wepple]

Perhaps the meta-message here is that you absolutely have to design for cryptographic agility.

You may not need to jump to the next best thing every 3 years, but as certain constructs are proven weak, you’ll need to start migrating systems and data off of them to modern equivalents.

[tatersolid]

> you absolutely have to design for cryptographic agility

Yes, but for heaven’s sake don’t design something with “cipher suite negotiation” which has been an endless source of vulnerability over the years in SSL/TLS, IPsec, PGP…

Instead one should advance the version of the entire protocol or file format when you need to upgrade the cryptography. Then you deprecate old versions as quickly as possible. WireGuard and age have no algorithm negotiation at all.

[nmadden]

The best way to do cryptographic agility is to associate the algorithm with the key and negotiate keys (from a given set) only. Google’s Tink library does this very well. See https://neilmadden.blog/2018/09/30/key-driven-cryptographic-... for some more background. Version numbers are just algorithm identifiers in another form.

[lifthrasiir]

In the other words, you only need cryptographic evolvability, not agility.

[wepple]

Yeah, very very important point

[maxbond]

> Am I getting crypto advice that will keep my data safe for 30+ years, if the advice changes every 3 years?

If you drill into the details a lot of things haven't changed. Eg, the key size and HMAC recommendations go back to the original version (among others).

[lumb63]

The “right answer” also depends on attack vector. If you are trying to protect against nation-state-level tampering or data leaks for two full generations, the enemy moves much quicker, and so you will need to advance much more quickly, to outpace what you think they might do to outpace you in the future.

If you are only trying to prevent your ISP from seeing your traffic, which they are not trying particularly hard to do, then that level of protection would be overkill.

[michaelt]

> If you are trying to protect against nation-state-level tampering or data leaks for two full generations, the enemy moves much quicker, and so you will need to advance much more quickly

It's supposed to protect my users' data for two full generations, but the advice is only good for 3 years?

[maxbond]

Which piece of advice is no longer good since the last version of the blog post was published 6 years ago?

[Rhapso]

On one side, there is good in "This is the best prediction of the future we have right now and we update it as our knowledge changes".

They also have a consulting product to sell you. When you build your entire society on "greed as a virtue", it is reasonable to assume it as a primary motivation for a profit seeking entity.

[defrost]

an algorithm publicly published in 1977.

The Ellis, Cocks and Williamson algorithm has existed since at least 1973.