2009: https://www.daemonology.net/blog/2009-06-11-cryptographic-ri...
2015: https://gist.github.com/tqbf/be58d2d39690c3b366ad
2018: https://www.latacora.com/blog/2018/04/03/cryptographic-right...
2024: https://www.latacora.com/blog/2024/07/29/crypto-right-answer...
So not every 3 years, but if you read through you'll notice a _lot_ of each update pretty much says "use the same advice as last time."
It's not clear who wrote the most recent Latacora post, but it's Thomas Ptacek's company, and the original 2009 post was by Colin Percival. If you've been around here for a while you'll probably recognise those names, they's #1 and #60 here: https://news.ycombinator.com/leaders At least in my head, both have serious credibility over many years in this subject space.
The 2018 Latacora post says:
"This content has been developed and updated by different people over a decade. We’ve kept what Colin Percival originally said in 2009, Thomas Ptacek said in 2015, and what we’re saying in 2018 for comparison. If you’re designing something today, just use the 2018 Latacora recommendation."
Is it possible to defend against this attack in a classical way? Some sort of time limit on decryption? Or an argument that it's impossible?
Wireguard, for example, provides the ability to add a pre-shared key for endpoints, which it mixes in during key exchange. Wireguard sessions collected under such a configuration should remain safe when attacked by a future quantum computer, assuming that the shared keys remain secret.
Pre-shared keys are just inconvenient to handle safely.
You can transfer PSKs safely and easily with OpenSSH 9.0 (released 2022-04-08) or later, which uses sntrup761x25519-sha512@openssh.com as the default key exchange method.
The only way you can do any "not after X time" decryption even for honest-ish users is if the decryption involves getting extra key material from some server that erases it or shuts down at some point. But even that doesn't help if someone can break the crypto.
There are a number of things you can do today, more than I listed. I suggest you discuss with an appsec person who is familiar with your threat model.
I'm curious what's the general opinion on the production-readiness of these solutions. Open Quantum Safe, for example, discourages it's use in production, and recompiling nginx to use PQC-BoringSSL feels risky since I'm not intimately familiar with both projects ("did I miss a --enable-security flag?").
> the PQ keys are 4 orders of magnitude larger
For McEliece, perhaps, but the algorithms in the tables are "only" 2 orders of magnitude larger.
- https://www.microsoft.com/en-us/research/project/post-quantu... - https://engineering.fb.com/2024/05/22/security/post-quantum-... - https://blog.cloudflare.com/kemtls-post-quantum-tls-without-...
But there's more to it than just resistance to cryptanalysis: crashes, memory leaks, disabled security features (e.g., ASLR), irregular performance, supply chain attacks...
PQC requires extra code, and every added instruction carries some risk.
To me what's worse is "zk" used to describe applications of verifiable computation with no secrets involved, but that seems like a losing battle also.
* https://www.nist.gov/news-events/news/2024/08/nist-releases-...
See
* FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM / CRYSTALS-KYBER)
* FIPS 204, Module-Lattice-Based Digital Signature Standard (ML-DSA / CRYSTALS-Dilithium)
* FIPS 205, Stateless Hash-Based Digital Signature Standard (SLH-DSA / SPHINCS+)
From:
* https://csrc.nist.gov/News/2024/postquantum-cryptography-fip...
* https://www.federalregister.gov/documents/2024/08/14/2024-17...
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?
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).
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?"
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.
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.
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.
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).
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.
It's supposed to protect my users' data for two full generations, but the advice is only good for 3 years?
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.
The Ellis, Cocks and Williamson algorithm has existed since at least 1973.
Interestingly enough, there is a proof out there that more or less states the opposite for HMAC-MD5 and HMAC-SHA1:
* https://eprint.iacr.org/2006/043.pdf
The issue here is that MD5 and SHA1 are broken for collisions. But no one could figure out an actual attack for HMACs based on them. The linked paper is an attempt to explain that.
