Earlier quoted context omitted.
> Since then, public cryptographic research has been ahead or even with state work. How can we know that? > Who knows what is happening inside the NSA or military facilities? Couldn't have NSA found an issue with ML-KEM and try to convince people to use it exclusively (not in hybrid scheme with ECC)?
Follow nsa suite-b and what the USA forces on different levels of classification.
A cryptography engineer's perspective on quantum computing timelines
221–230 of 260 posts
Re: A cryptography engineer's perspective on quantum computing timelines
#222Earlier quoted context omitted.
It's definitely not that "The research on lattice-based crypto is still young compared to EC/RSA."
Perhaps you would care to enlighten us ignorant plebs rather than taunting us? My understanding (obviously as a non expert) matches what cyberax wrote above. Is it not common wisdom that the pursuit of new and exciting crypto is an exercise filled with landmines? By that logic rushing to switch to the new shiny would appear to be extremely unwise. I appreciate the points made in the article that the PQ algorithms are…
Re: A cryptography engineer's perspective on quantum computing timelines
#223Earlier quoted context omitted.
Couldn't NSA have not known about an issue with ML-KEM, and thus wanted to prevent its commercial acceptance, which it did simply by approving the algorithm? What's the PQC construction you couldn't say either thing about?
> Couldn't NSA have not known about an issue with ML-KEM, and thus wanted to prevent its commercial acceptance, which it did simply by approving the algorithm? Could, but they did not do that. So, the question is to be stated: Why?
Re: A cryptography engineer's perspective on quantum computing timelines
#224Earlier quoted context omitted.
How do you mean the risk profile is comparable, when ECDH is nearly guaranteed to be broken in five years and Kyber is two decades old? The two have nothing to do with each other, the ECDH component of a hybrid becomes worthless before you next replace your smartphone, and bloating the protocol can only hurt adoption. Yes, djb keeps making the same crankish complaint without any evidence or reason, that doesn't mean…
> How do you mean the risk profile is comparable Exactly in the way the succeeding sentence defines: "For both cases there are credible expert opinions that say the risk is incredibly overrated and credible expert opinions that say the risk is incredible underrated." > when ECDH is nearly guaranteed to be broken in five years Most of your argument (and that of many others pushing the contra-hybrid point) hinges on th…
Re: A cryptography engineer's perspective on quantum computing timelines
#225Earlier quoted context omitted.
> from a classical security point of view PQC cannot be trusted [citation needed] https://words.filippo.io/crqc-timeline/#fn:lattices
Just a little selections of recent attacks on a few post quantum assumptions: Isogenie/SIDH: https://eprint.iacr.org/2022/975 Lattices: https://eprint.iacr.org/2023/1460 Classical McEliece: https://eprint.iacr.org/2024/1193 Saying that you can trust blindly PQ assumptions is a very dangerous take.
Leaving aside that you actually didn't cite a lattice attack paper, the "dual attack" on lattice cryptography is older than P-256 was when Curve25519 was adopted to replace it. It's a model attack, going all the way back to Regev. It is to MLKEM what algebraic attacks were (are?) to AES.
You know you're in trouble in these discussions when someone inevitably cites SIDH. SIDH has absolutely nothing to do with lattices; in fact, it has basically nothing to do with any other form of cryptography. It was a wildly novel approach that attracted lots of attention because it took a form that was pin-compatible with existing asymmetric encryption (unlike MLKEM, which provides only a KEM).
People who bring up SIDH in lattice discussions are counting on non-cryptography readers not to know that lattice cryptography is quite old and extremely well studied; it was a competitor to elliptic curves for the successor to RSA.
With that established: what exactly is the point you think those three links make in this discussion? What did you glean by reading those three papers?
Re: A cryptography engineer's perspective on quantum computing timelines
#226Earlier quoted context omitted.
Yeah and some of the figures often quoted like consuming 14% of the electricity produced in the US are wrong, it was below 1%. https://ui.adsabs.harvard.edu/abs/2011APS..APRH13004R/abstra...
It was like 0.5% GDP. It wasn’t insane, but still, you are right. It was very focused. What do we get out of the F-35 program? By comparison, it has eaten (projected total lifetime cost) 2 trillion dollars. It is 4.5% of the GDP. I had no idea. This is just a military and government contractor subsidy. What are we doing…
Re: A cryptography engineer's perspective on quantum computing timelines
#227Earlier quoted context omitted.
I’ve worked with Bas. I respect him, but he is definitely a QC maximalist in a way. At the very least he believes that caution suggests the public err on the side of believing we will build them. The actual challenge is we still don’t know if we can build QC circuits that factorize faster than classical both because the amount of qubits has gone from ridiculously impossible to probably still impossible AND because we…
Don't recognise you from your username, but thanks for the respect. (Update: ah, Vitali! Nice to hear from you.) If you look back at my writing from 2025 and earlier, I'm on the conservative end of Q-day estimates: 2035 or later. My primary concern then is that migrations take a lot of time: even 2035 is tight. I'm certainly not an expert on building quantum computers, but what I hear from those that are worries me.…
My concern is that there's so much human and financial capital behind quantum computing that the "experts" have lots of reason to try to convince you that it's going to happen any day now. The cryptographic community is rightly scared by the potential because we don't have any theoretical basis to contradict that QC speedups aren't physically possible, but we also don't have any proof (existence or theoretical) that proves they are actually possible.
The same diagrams that are showing physical q-bits per year or physical qbits necessary to crack some algorithm are the same ones powering funding pitches and that's very dangerous to me - it's very possible it's a tail wagging the dog situation.
The negative evidence here for me is that all the QC supremacy claims to date have constantly evaporated as faster classical algorithms have been developed. This means the score is currently 0/N for a faster than classical QC. The other challenge is we don't know where BQP fits or if it even exists as a distinct class or if we just named a theoretical class of problems that doesn't actually exist as a distinct class. That doesn't get into the practical reality that layering more and more error correction doesn't matter so much when the entire system still decoheres at any number at all relevant for theoretically being able to solve non-trivial problems.
Should we prepare for QC on the cryptography side? I don't know but I'm still less < 10% chance that CRQC happens in the next 20 years. I also look at the other situation - if CRQC doesn't ever happen, we're paying a meaningful cost both in terms of human capital spent hardening systems against it and ongoing in terms of slowing down worldwide communications to protect against a harm that never materializes (not to mention all the funding burned spent chasing building the QC). The problem I'm concerned about is that there's no meaningful funding spent trying to crack whether BQP actually exists and what this complexity class actually looks like.
Re: A cryptography engineer's perspective on quantum computing timelines
#228Earlier quoted context omitted.
I'm not sure who particularly cares about the stuff Signal is doing with SGX anyway. It always struck me as a 'because we can' move and if you're paranoid enough to worry about it then you're probably paranoid enough to not trust any manufacturer-based attestation anyway (All SGX does is make Intel the root of trust, and it's not like Signal would be less secure than any other third party if SGX were broken).
> I'm not sure who particularly cares about the stuff Signal is doing with SGX anyway. Security researchers like Matthew Green seem to care[0], the Signal people surely do, I myself do, too. Isn't that enough to raise that question? > if you're paranoid enough to worry about it You make it seem like that's an outlandish thought, when in reality there have been tons of reported vulnerabilities for SGX. And now QC repr…
Re: A cryptography engineer's perspective on quantum computing timelines
#229Earlier quoted context omitted.
> I'm not sure who particularly cares about the stuff Signal is doing with SGX anyway. Security researchers like Matthew Green seem to care[0], the Signal people surely do, I myself do, too. Isn't that enough to raise that question? > if you're paranoid enough to worry about it You make it seem like that's an outlandish thought, when in reality there have been tons of reported vulnerabilities for SGX. And now QC repr…
I mean, if you're worried about Signal being a bad actor you also should probably be worried about Intel being a bad actor, and they hold the keys to SGX (especially because the biggest threat, if you're worried about this at all, is going to be governments compelling the involved companies to hand over data or attempt to intercept messages). And Signal is also a third party to your communications, that's how it work…
Re: A cryptography engineer's perspective on quantum computing timelines
#230Earlier quoted context omitted.
> How do you mean the risk profile is comparable Exactly in the way the succeeding sentence defines: "For both cases there are credible expert opinions that say the risk is incredibly overrated and credible expert opinions that say the risk is incredible underrated." > when ECDH is nearly guaranteed to be broken in five years Most of your argument (and that of many others pushing the contra-hybrid point) hinges on th…
I would be interested in seeing you rattle off the "pros and cons" of this argument, just as a synchronization mechanism for the thread so we'd know if we're on the same page.
Pro hybrid: Negligible performance impact (negligible for battery devices, negligible for data send over the wire (number of packets -> sub-discussion about specific circumstances, time on the air for cellular), negligible for speed, negligible code size increase), little implementation effort as every library already has ECC in it, ML-KEM is too new (yes actually old, but far less research interest, implementations new), conservative design choice
Pro ML-KEM only / produce a TLS RFC for non-hybrid ML-KEM: Reduction in complexity, reduction of transitions (non-hybrid is going to be the final state, so lets skip ahead already), lattice crypto is actually an old branch of cryptography (discussion over different metrics), NSA says its secure for government use, NSA stipulates use of non-hybrid and we want/need to be compatible, we want/need to have a well defined place to have a reference, if people are going to write an RFC to document non-hybrid ML-KEM let us at least have influence over what is written there, better performance (speed, data on the wire, number of packets in handshake, energy budget), actually the non-hybrid TLS connection is intended to be the inner one while the outer transport is secured with classic cryptography (or vice versa) so hybrids are a complete waste, for any interesting timeline ECC is broken anyway so it is a useless burden, we just want choice dammit, don't undermine the process dammit.
Pro hybrid only / don't produce a TLS RFC for non-hybrid ML-KEM: Let's not make it easy for people to choose wrongly by accident/incompetence/malice, actually no complexity reduction as implementations still need to implement hybrids to be compatible, TLS WG publishing something has weight and might sway others to consider non-hybrid ML-KEM, NSA might have pushed for non-hybrid ML-KEM because they believe only they can break it, don't care if US institutions are pushing for non-hybrid ML-KEM for weird internal political reasons, don't you see how this is all a ploy to weaken our crypto again?, don't undermine the process dammit.
Did I forget any important talking point? The TLS WG discussion is actually quite tiresome. For anybody new the party, here is a random pointer for a current thread: https://mailarchive.ietf.org/arch/msg/tls/7OGS_X1e-zG8O0eRJP...