[HN Gopher] Cryptographic Right Answers: Post Quantum Edition
___________________________________________________________________
Cryptographic Right Answers: Post Quantum Edition
Author : lvh
Score : 85 points
Date : 2024-08-15 08:36 UTC (14 hours ago)
(HTM) web link (www.latacora.com)
(TXT) w3m dump (www.latacora.com)
| CodeVenturer wrote:
| The article mentions that PQC artifacts like keys and signatures
| are significantly larger. I wonder how this will impact mobile
| and IoT devices where resources are limited. Are there any
| promising developments or optimizations in PQC for constrained
| environments?
| hannob wrote:
| What you got now as new standards is already the result of
| multiple iterations of improvements in key size reductions and
| performance improvements. But you'll likely not get drop-in
| replacements for existing public key crypto in post-quantum
| variations. It appears signatures are even more challenging
| regarding size than encryption in the post-quantum world.
|
| It may be worth noting that choosing the algorithms that are
| now chosen, which are primarily lattice-based, is already kinda
| a compromise. They're not the ones with the highest trust in
| security, which would've been McEliece and SPHINCS (though the
| latter has been standardized as a fallback). But those come
| with key and signature sizes that are entirely impractical for
| the most common use cases.
|
| It appears most of the crypto community came around thinking
| that the somewhat-smaller lattice algos are now "almost
| certainly secure". But surely there's at least one famous
| cryptographer raising his voice that he still has concerns.
| candiddevmike wrote:
| AIUI part of the problem with size is due to hybrid setups.
| Size could probably be reduced if you only used a PQC algorithm
| instead of combining it with existing crypto.
| nmadden wrote:
| 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/
| kaliszad wrote:
| Thank you for the update. This is really useful. It would be
| really great, if you could commit to an update a few years down
| the road at the latest. E.g. "I will release an update no later
| than August 15th 2027". 3 years in the fast-changing world
| shouldn't be such a burden and it would help to settle many
| discussions somewhat reasonably with appeal to authority :-D No
| seriously, having something that can be considered current advice
| would be great.
| chupasaurus wrote:
| Besides PQC only password handling has _some_ changes from
| 2018, which I assume was made because of TLSv1.3 and ECC, so
| you get the idea.
| BoppreH wrote:
| 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 McEliece, perhaps, but the algorithms in the tables are
| "only" 2 orders of magnitude larger.
| stratom wrote:
| The field is too young that we can be absolutely sure. That's
| why most suggest to use hybrid cryptography for now.
| BoppreH wrote:
| True, and hybrid cryptography is definitely the way to go.
|
| 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.
| er4hn wrote:
| 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-...
| Ahmed_rza wrote:
| Great post! I was worried for a long time about this thing as I'm
| also working in DeFi field. It's great that governments are
| taking the quantum computer threat seriously
| michaelt wrote:
| 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?
| defrost wrote:
| an algorithm _publicly published_ in 1977.
|
| The Ellis, Cocks and Williamson algorithm has existed since at
| least 1973.
| Rhapso wrote:
| 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.
| kientuong114 wrote:
| 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 wrote:
| 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.
| maxbond wrote:
| > 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).
| slooonz wrote:
| > 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).
| wepple wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| lumb63 wrote:
| 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 wrote:
| _> 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 wrote:
| Which piece of advice is no longer good since the last
| version of the blog post was published 6 years ago?
| tptacek wrote:
| 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 wrote:
| 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 wrote:
| 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.
| librasteve wrote:
| Good list of early supporters near the bottom of the post text -
| Chrome, OpenSSH and iMessage are relevant for me.
| dadrian wrote:
| Hybrid kyber is actually enabled by default in Chrome on
| desktop, you don't need to go to chrome://flags to enable it.
| Rhapso wrote:
| There are tables at the end describing the algorithms key sizes.
| be mindful of "(Size in bytes)" not bits. They cover that these
| algorithms use bigger keys, but it is 4 kilobytes.
| throw0101d wrote:
| NIST announcement:
|
| * 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...
| ccppurcell wrote:
| As I understand it, the only reason pqc is of "practical" concern
| is the issue of "store now, decrypt later".
|
| 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?
| candiddevmike wrote:
| Sneakernet or OTP
| red_admiral wrote:
| The NSA has a copy of your ciphertexts on their disks today.
| What could stop them from trying to decrypt it in 5 years'
| time? It's not like they will be held back by any Terms &
| Conditions.
|
| 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.
| dogsledsleddog wrote:
| I don't think that is true, current PFS algorithms are
| probably all just an inconvenience PQ, but I think they
| suggest strategies where one has to have a key at the time of
| a negotiation or even be part of a decision in a negotiation
| to ever have the session key as long as the parties discard
| it.
| thadt wrote:
| Strong pre-shared keys will continue to remain secure, even
| against a quantum computer.
|
| 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.
| Panino wrote:
| > 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.
| Gh0stRAT wrote:
| 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.
| thadt wrote:
| 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.
| IncRnd wrote:
| Have crypto agility, so that when you want to transition
| algorithms, the move will be as seamless as possible. You can
| start to use a blended or hybrid crypto today, where you
| simultaneously use both classical and pqc algorithms. For your
| classical algorithms, you should adjust your keys' security
| strength in accordance with your threat model. See CNSA 2.0 for
| a starter reference. For data in motion, you can use two VPNs,
| configured appropriately.
|
| 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.
| upofadown wrote:
| >Avoid: HMAC-MD5, HMAC-SHA1 and such. The underlying hash
| function has to be safe.
|
| 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.
| woodruffw wrote:
| I think the phrasing in this post could be better, but the
| basic observation is sound: if the last use of a weak hash
| function in your codebase is in HMACs, then it's better to
| upgrade to a stronger underlying hash function and apply a
| blanket ban to the weak ones. Similarly, in a greenfield
| codebase, there's no reason to pick an HMAC construction based
| on a weaker hash when collision-resistant ones are universally
| available.
| rgovostes wrote:
| "Classical cryptography" used to refer to historical ciphers,
| Vigenere and the like, tapering off after the World War 2-era
| cipher machines and definitely not used to describe asymmetric
| algorithms. There should be a different term for pre- (non-?)
| quantum cryptography from the modern era. We already suffered the
| redefinition of "crypto".
| dlubarov wrote:
| It's a reasonable point but this would probably be a losing
| battle; at this point terms like "classical security",
| "classical adversaries", etc. are common in the literature.
|
| 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.
| 1oooqooq wrote:
| Hostly, most cryptographic vulnerability today are because things
| are stuck in the NIST and FIPS regulation. Most vulnerable
| building blocks are still shipped to have their certification to
| begin with. Why there's still excitement to their work?
___________________________________________________________________
(page generated 2024-08-15 23:01 UTC)