Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cryptographic Right Answers: Post Quantum Edition

latacora.com

Post reply on HN
Print view View original

41–50 of 61 posts

Re: Cryptographic Right Answers: Post Quantum Edition

#41

Post by tatersolid »

wepple wrote: post #26
michaelt wrote: post #8

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+ ye…

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.

> 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.

Re: Cryptographic Right Answers: Post Quantum Edition

#43

Post by tptacek »

michaelt wrote: post #8

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+ ye…

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.

Re: Cryptographic Right Answers: Post Quantum Edition

#44

Post by er4hn »

BoppreH wrote: post #6

Excellent post, I've always recommended people to this series. 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 M…

One interesting thing is that if you look at what companies that want to prepare for Store Now Decrypt Later are doing (see links at bottom) they're pretty much all using the non-production ready OQS. If you believe in hybrid encryption this is mostly okay since a failure in the PQC portion should not cause a breakage in the classical portion. Assuming that OQS has implemented the hybrid protocol correctly.

- 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-...

Re: Cryptographic Right Answers: Post Quantum Edition

#45

Post by [deleted] »

michaelt wrote: post #8

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+ ye…

[deleted]

Re: Cryptographic Right Answers: Post Quantum Edition

#46

Post by thadt »

Gh0stRAT wrote: post #38
Panino wrote: post #34

Earlier quoted context omitted.

> 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.

If your threat model includes someone with a quantum computer intercepting all of your traffic and storing it to decrypt later, you probably don't want to share your keys over a non-PQC channel unless you can guarantee that they haven't started eavesdropping on your traffic yet.

While sntrup761x25519-sha512 is a QC secure key exchange, sending a key over it doesn't count. It's not really a "pre-shared" key unless the sharing is done using organic, locally sourced sneakers. Unless FIPs, and then it's boots.

Re: Cryptographic Right Answers: Post Quantum Edition

#47

Post by nmadden »

CodeVenturer wrote: post #2

[dead]

Yes, Kyber (ML-KEM) ciphertexts can be compressed somewhat when you are sending the same message to multiple recipients. See https://csrc.nist.gov/csrc/media/Events/2024/fifth-pqc-stand... for details:

> "Asymptotically, the size of an mKyber multi-recipient ciphertext is 16 times smaller than the sum of the sizes of N Kyber ciphertexts.”

There’s a whole zoo of useful variants on the “KEM” idea, but sadly NIST decided to standardise the least flexible variant. See my blog from a few years ago for some background on the literature: https://neilmadden.blog/2021/02/16/when-a-kem-is-not-enough/

Re: Cryptographic Right Answers: Post Quantum Edition

#48

Post by nmadden »

tatersolid wrote: post #41
wepple wrote: post #26

Earlier quoted context omitted.

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.

> 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 a…

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.

Re: Cryptographic Right Answers: Post Quantum Edition

#49

Post by SAI_Peregrinus »

kientuong114 wrote: post #18
michaelt wrote: post #8

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+ ye…

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 sh…

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.

Re: Cryptographic Right Answers: Post Quantum Edition

#50

Post by maxbond »

michaelt wrote: post #33
lumb63 wrote: post #27

Earlier quoted context omitted.

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…

> 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?

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