11 ms·
A cryptography engineer's perspective on quantum computing timelines
- deleted 6mo ago[deleted]
- pdhborges 6mo agoWhat do you recomend as reading material for someone that was in college a while ago (before AE modes got popular) to get up to speed with the new PQ developments?
- FiloSottile 6mo agoIf you want something book-shaped, the 2nd edition of Serious Cryptography is updated to when the NIST standards were near-final drafts, and has a nice chapter on post-quantum cryptography. If you want something that includes details on how they were deployed, I'm afraid that's all very recent and I don't have good references.
- vonneumannstan 6mo agoThis seems like something uniquely suited to the startup ecosystem. I.e. offering PQ Encryption Migration as a Service. PQ algorithms exist and now theres a large lift required to get them into the tech with substantial possible value.
- hlieberman 6mo ago… really? This is simultaneously so far down in the plumbing and extremely resistant to measuring the impact of, I can’t imagine anyone building a company off of this that’s not already deep in the weeds (lookin’ at you, WolfSSL). The idea that a startup would be competitive in the VC “the only thing that matters are the feels” environment seems crazy to me.
- OhMeadhbh 6mo agoYeah... I spent the 90s working for RSADSI and Certicom implementing algorithms. Crypto is a vitamin, not an aspirin. Hardly anyone is capable of properly assessing risk in general, much less the technical world of information risk management. Telling someone they should pay you money to reduce the impact of something that may or may not happen in the future is not a sales win.
- tux3 6mo agoThis is a good take, there's really not much to argue about. >[...] the availability of HPKE hybrid recipients, which blocked on the CFRG, which took almost two years to select a stable label string for X-Wing (January 2024) with ML-KEM (August 2024), despite making precisely no changes to the designs. The IETF should have an internal post-mortem on this, but I doubt we’ll see one My kingdom for a standards body that discusses and resolves process issues.
- OhMeadhbh 6mo agoI missed you at the most recent CRFG meeting.
- adgjlsfhk1 6mo agoI think the anti-hybrid argument the article makes is clearly wrong. Even if CRQCs existed today, we still should be using hybrid algorithms because even once CRQCs exist, they will be slow, expensive, and power hungry for at least a decade. The hybrid algorithms at a minimum make the cost of any attack ~$1M, which is way better than half of the PQC algorithms that made it to the 3rd stage of the PQC competition (2 of them can be broken on a laptop)
- scythmic_waves 6mo agoIs it? Your reasoning relies on this being true: > [CRQCs] will be slow, expensive, and power hungry for at least a decade How could you know that? What if it was 5 years? 1 year? 6 months? I predict there will be an insane global pivot once Q-day arrives. No nation wants to invest billions in science fiction. Every nation wants to invest billions in a practical reality of being able to read everyone's secrets.
- adgjlsfhk1 6mo agoThe absolute low end of cost of a QC is the cost of an MRI machine ~100k-400k (cost of cooling the computer to super low temps). Sure we expect QCs to get faster and cheaper over time, but putting 100% faith in the security of the PQC algorithms seems like a bad idea with no upside.
- OhMeadhbh 6mo agoIn rebuttal, Peter Gutmann seems to think the progress towards quantum computing devices which can break commonly used public key crypto systems is not moving especially quickly: https://eprint.iacr.org/2025/1237 https://eprint.iacr.org/2025/1237
- schmichael 6mo agoThat's not a rebuttal. The post references the paper and a rebuttal to it from an expert in the field.
- OhMeadhbh 6mo agoDamn. It's like I insulted Vault. Also, I went over Filippo's post again and still can't see where it references the Gutmann / Neuhaus paper. Are we talking about the same post?
- tkhattra 6mo agoFrom Filippo's post: "Sure, papers about an abacus and a dog are funny and can make you look smart and contrarian on forums."
- commandersaki 6mo agoIs that even a rebuttal? Seems like just a dismissal without any substance. I expect in 10 years the predictions will be wrong, kind of like Y2K all over again.
- OhMeadhbh 6mo agoIf only we had a technology where an author could specify a unique identifier and name of another author's paper. Something that could cite a different paper and link to it.
- xvector 6mo agoFrom the abstract: > This paper presents implementations that match and, where possible, exceed current quantum factorisation records using a VIC-20 8-bit home computer from 1981, an abacus, and a dog. From the link: > Sure, papers about an abacus and a dog are funny and can make you look smart and contrarian on forums. But that’s not the job, and those arguments betray a lack of expertise[1]. As Scott Aaronson said[2]: > > Once you understand quantum fault-tolerance, asking “so when are you going to factor 35 with Shor’s algorithm?” becomes sort of like asking the Manhattan Project physicists in 1943, “so when are you going to produce at least a small nuclear explosion?” [1]: https://bas.westerbaan.name/notes/2026/04/02/factoring.html https://bas.westerbaan.name/notes/2026/04/02/factoring.html [2]: https://scottaaronson.blog/?p=9665#comment-2029013 https://scottaaronson.blog/?p=9665#comment-2029013
- OsrsNeedsf2P 6mo agoWhy do we "need to ship"? 1,000 qubit quantum computers are still decades away at this point
- OhMeadhbh 6mo agoSo... In 2013 I was working for Mozilla adding TLS 1.1 and 1.2 support into Firefox. It turns out that some of the extensions common in 1.1, in some instances caused PDUs to grow beyond 16k (or maybe it was 32k, can't remember.). This caused middle boxes to barf. Sure, they shouldn't barf, but they did. We discovered the problem (or rather one of our users discovered the problem) by increasing the key size on server and client certs to push PDU sizes over the limit. At the very least, you want to start using hybrid legacy / pqc algorithms so engineers at Cisco will know not to limit key sizes in PDUs to 128 bytes.
- ekr____ 6mo agoA few points here: There is already very wide use of PQ algorithms in the Web context [0], which is the most problematic one because clients need to be able to connect to any site and there's no real coordination between sites and clients. So we're exercising the middleboxes already. The incident you're thinking of doesn't sound familiar. None of the extensions in 1.1 really were that big, though of course certs can get that big if you work hard enough. Are you perhaps thinking instead of the 256-511 byte ClientHello issue addressed ion [1] [0] https://blog.cloudflare.com/pq-2025/ https://blog.cloudflare.com/pq-2025/ [1] https://datatracker.ietf.org/doc/html/rfc7685 https://datatracker.ietf.org/doc/html/rfc7685
- OhMeadhbh 6mo agoOh hey Eric. I think I was wrong saying it was 1.1. It was a middlebox that ignored max fragment negotiation, which I think was introduced in 1.2. IIRC, the middlebox claimed to support it for 1.2 connections, but silently failed by blackholing the connection. They eventually crafted a fix, but it was an annoying year waiting for network operators to upgrade the firmware on their routers.
- Sparkyte 6mo agoThere is always a price to encryption. The cost goes up the more you have to cater to different and older encryptions while supporting the latest.
- munrocket 6mo agoYes, this is why I invested in QRL crypto. With lates updates and no T1 exchange it looks like a good opportunity to grow.
- adrian_b 6mo agoIt should be noted that if indeed there has not remained much time until a usable quantum computer will become available, the priority is the deployment of FIPS 203 (ML-KEM) for the establishment of the secret session keys that are used in protocols like TLS or SSH. ML-KEM is intended to replace the traditional and the elliptic-curve variant of the Diffie-Hellman algorithm for creating a shared secret value. When FIPS 203, i.e. ML-KEM is not used, adversaries may record data transferred over the Internet and they might become able to decrypt the data after some years. On the other hand, there is much less urgency to replace the certificates and the digital signature methods that are used today, because in most cases it would not matter if someone would become able to forge them in the future, because they cannot go in the past to use that for authentication. The only exception is when there would exist some digital documents that would completely replace some traditional paper documents that have legal significance, like some documents proving ownership of something, which would be digitally signed, so forging them in the future could be useful for somebody, in which case a future-proof signing method would make sense for them. OpenSSH, OpenSSL and many other cryptographic libraries and applications already support FIPS 203 (ML-KEM), so it could be easily deployed, at least for private servers and clients, without also replacing the existing methods used for authentication, e.g. certificates, where using post-quantum signing methods would add a lot of overhead, due to much bigger certificates.
- FiloSottile 6mo agoThat was my position until last year, and pretty much a consensus in the industry. What changed is that the new timeline might be so tight that (accounting for specification, rollout, and rotation time) the time to switch authentication has also come. ML-KEM deployment is tangentially touched on in the article because it's both uncontroversial and underway, but: > This is not the article I wanted to write. I’ve had a pending draft for months now explaining we should ship PQ key exchange now, but take the time we still have to adapt protocols to larger signatures, because they were all designed with the assumption that signatures are cheap. That other article is now wrong, alas: we don’t have the time if we need to be finished by 2029 instead of 2035. > For key exchange, the migration to ML-KEM is going well enough but: 1. Any non-PQ key exchange should now be considered a potential active compromise, worthy of warning the user like OpenSSH does, because it’s very hard to make sure all secrets transmitted over the connection or encrypted in the file have a shorter shelf life than three years. [...] You comment is essentially the premise of the other article.
- janalsncm 6mo agoBuilding out a supercomputer capable of breaking cryptography is exactly the kind of thing I expect governments to be working on now. It is referenced in the article, but the analogy to the Manhattan Project is clear. Prior to 1940 it was known that clumping enough fissile material together could produce an explosion. There were engineering questions around how to purify uranium and how to actually construct the weapon etc. But the phenomenon was known. I say this because there’s a meme that governments are cooking up exotic technologies behind closed doors which I personally tend to doubt. This is almost perfect analogy to the MP though. We know exactly what could happen if we clumped enough qubits together. There are hard engineering challenges of actually doing so, and governments are pretty good at clumping dollars together when they want to.
- bitexploder 6mo agoThe Manhattan project employed some significant % of all of America. A project of that scale will likely never happen again. It was also about far more than the science. It was about industrializing the entire production process and creating industrial capability that simply did not exist before.
- janalsncm 6mo agoMy comment was not limited to the U.S. government. And the Manhattan Project cost $30B in today’s money. Compared with some of the numbers Congress has allocated recently, I’d call that a bargain.
- bitexploder 6mo agoI am skeptical you could do something of that scale for 30B today. That is just the dollar cost based on inflation. If you used CPI indexing probably hundreds of billions to a trillion dollars now.
- bastawhiz 6mo agoDoes quantum computing need that though? We don't suddenly need a large, unique supply chain for these computers. We don't need to dig up the qubits and refine them. Testing doesn't blow up the computer.
- amluto 6mo agoI was in this field a while back, and I always found it baffling that anyone ever believed in the earlier large estimates for the size of a quantum computer needed to run Shor's algorithm. For a working quantum computer, Shor's algorithm is about as difficult as modular exponentiation or elliptic curve scalar multiplication: if it can compute or verify signatures or encrypt or decrypt, then it can compute discrete logs. To break keys of a few hundred bits, you need a few hundred qubits plus not all that much overhead. And the error correction keeps improving all the time. Also... > Trusted Execution Environments (TEEs) like Intel SGX and AMD SEV-SNP and in general hardware attestation are just f**d. All their keys and roots are not PQ and I heard of no progress in rolling out PQ ones, which at hardware speeds means we are forced to accept they might not make it, and can’t be relied upon. This part is embarrassing. We’ve had hash-based signatures that are plenty good for this for years and inspire more confidence for long-term security than the lattice schemes. Sure, the private keys are bigger. So what? We will also need some clean way to upgrade WebAuthn keys, and WebAuthn key management currently massively sucks.
- hujun 6mo ago> Trusted Execution Environments (TEEs) like Intel SGX and AMD SEV-SNP and in general hardware attestation are just f*d. All their keys and roots are not PQ and I heard of no progress in rolling out PQ ones, which at hardware speeds means we are forced to accept they might not make it, and can’t be relied upon. compare to SGX, a more critical impacted component is TPM chip, secured/measured boot depends on TPM, and cost of replacing all servers and OS ...
- amluto 6mo agoA lot of TPMs are “fTPM”s, which are implemented in something resembling software. It’s an open question whether the hardware in question has usable roots of trust, but a lot of TPM applications don’t actually require endorsement. And some servers have plug-in TPMs. Of course, many critical components on a motherboard and CPU verify their firmware using non-post-quantum keys, which is another issue.
- 6mo ago
- palata 6mo agoWhat is the consequence on e.g. Yubikeys (or say the Android Keystore)? Do I understand correctly that those count as "signature algorithms" and are a little less at risk than "full TEEs" because there is no "store now, decrypt later" for authentication? E.g. can I use my Yubikey with FIDO2 for SSH together with a PQ encryption, such that I am safe from "store now, decrypt later", but can still use my Yubikey (or Android Keystore, for that matter)?
- amluto 6mo agoYour Yubikey itself is doomed. If you are doing a post-quantum key exchange and only authenticating with the Yubikey, then you are safe from after-the-fact attacks. Well, as long as the PQ key exchange holds up, and I am personally not as optimistic about that as I’d like to be.
- elevation 6mo agoLooking forward to a PQ yubikey rev. I would buy a box of them today so I could start experimenting! Another challenge of the transition is how much silicon we have yet to even implement. Smart cards? Mobile acceleration/offloading? We're at the mercy of vendors.
- ls612 6mo agoIs this also true for other TPM/snitching/DRM chips out there? IE will every existing device eventually become jailbreakable in the future or will we unfortunately not even get that benefit from all this?
- ameliaquining 6mo agoThe timeline here is for when major governments have access to CRQCs. It will be much longer than that (barring an AI singularity or something) before you have access to one.
- palata 6mo ago> If you are doing a post-quantum key exchange and only authenticating with the Yubikey, then you are safe from after-the-fact attacks. Let me rephrase it to see if I understand correctly: so it is fine to keep using my security keys today for authentication (e.g. FIDO2?), but everything else should use PQ algorithm because the actual data transfers can be stored now and decrypted later. Meaning that today (and for a few years), my Yubikey still protects me from my key being stolen when my OS is compromised. Correct?
- bjourne 6mo ago> Traveling back from an excellent AtmosphereConf 2026, I saw my first aurora, from the north-facing window of a Boeing 747. Given the author's "safety first" stance on pqc, it seems a bit incongruent to continue to fly to conferences...
- krunck 6mo agoThis would also be a good time for certain governments to knowingly push broken PQ KE standards while there is a panicked rush to get PQ tech in place.
- some_furry 6mo agoWhich governments are you thinking of?
- FiloSottile 6mo agoRemember that the entities most likely to heed those governments recommendations are those providing services to said government and its military. I feel like the NSA pushing a (definitely misguided and obviously later exploited by adversaries) NOBUS backdoor has poorly percolated into the collective consciousness, missing the NOBUS part entirely. See https://keymaterial.net/2025/11/27/ml-kem-mythbusting/ https://keymaterial.net/2025/11/27/ml-kem-mythbusting/ for whether the current standards can hide NOBUS backdoors. It talks about ML-KEM, but all recent standards I read look like this.
- adgjlsfhk1 6mo agoIMO the idea that NSA only uses NOBUS backdoors is obviously false (see for example DES's 56 bit key size). The NSA is perfectly capable of publicly calling for an insecure algorithm and then having secret documentation to not use it for anything important.
- bawolff 6mo ago> see for example DES's 56 bit key size In fairness, that was from 1975. I don't particularly trust the NSA, but i dont think things they did half a century ago is a great way to extrapolate their current interests.
- raron 6mo agoAFAIK they did a lot of illegal things in the Snowden-era, too.
- Animats 6mo agoWe'll know it's been cracked when all the lost Bitcoins start to move.
- sunshine-o 6mo agoYep, I was looking into it and from what I understand: - There is a dark outlook on Bitcoin as the community and devs can't seem to coordinate. Especially on what to do with the "Satoshi coins" - Ethereum has a hard but clear path (pretty much full rewrite) with a roadmap [0] - The highly optimized "fast chains" (Solana & co) are in a lot of trouble too. It would be funny if Bitcoin the asset end up migrating to Ethereum as another erc20 token - [0] https://pq.ethereum.org/ https://pq.ethereum.org/
- PretzelPirate 6mo ago> pretty much full rewrite This is far from my understanding. Changing out this signature scheme is hard work, but doesn't require a rewrite of the VM.
- sunshine-o 6mo agoEthereum is way more complex than let's say Bitcoin and all parts are affected. This is not just the "signature scheme". The fact that the signature size is multiplied by ~10 will greatly affect things like blockspace (what I guess is even more a problem with Bitcoin !) Also they are the only blockchain I believe that put an emphasis on allowing large number of validators to run on very modest hardware (in the ballpark of a RPI, N100 or phone). My understanding is they will need to pack it with a larger upgrade to solve all those problems, the so called zkVM/leanVM roadmap. And then there are the L2 that are an integral part of the ecosystem. So this is the greatest upgrade ever made on Ethereum, pretty much full rewrite, larger than the transition to proof of stake. I remember before the Proof of Stake migration they were planning to redo the EVM too (with something WASM based at the time) but they had to abandon their plan. Now it seems there is no choice but to do it.
- nullc 6mo ago
- phicoh 6mo agoWhat surprises me is how non-linear this argument is. For a classical attack on, for example RSA, it is very easy to a factor an 8-bit composite. It is a bit harder to factor a 64-bit composite. For a 256-bit composite you need some tricky math, etc. And people did all of that. People didn't start out speculating that you can factor a 1024-bit composite and then one day out of the blue somebody did it. The weird thing we have right now is that quantum computers are absolutely hopeless doing anything with RSA and as far as I know, nobody even tried EC. And that state of the art has not moved much in the last decade. And then suddenly, in a few years there will be a quantum computer that can break all of the classical public key crypto that we have. This kind of stuff might happen in a completely new field. But people have been working on quantum computers for quite a while now. If this is easy enough that in a few years you can have a quantum computer that can break everything then people should be able to build something in a lab that breaks RSA 256. I'd like to see that before jumping to conclusions on how well this works.
- FiloSottile 6mo agoSee https://bas.westerbaan.name/notes/2026/04/02/factoring.html https://bas.westerbaan.name/notes/2026/04/02/factoring.html and https://scottaaronson.blog/?p=9665#comment-2029013 https://scottaaronson.blog/?p=9665#comment-2029013 which are linked to in the first section of the article. > Sure, papers about an abacus and a dog are funny and can make you look smart and contrarian on forums. But that’s not the job, and those arguments betray a lack of expertise. As Scott Aaronson said: > Once you understand quantum fault-tolerance, asking “so when are you going to factor 35 with Shor’s algorithm?” becomes sort of like asking the Manhattan Project physicists in 1943, “so when are you going to produce at least a small nuclear explosion?” To summarize, the hard part of scalable quantum computation is error correction. Without it, you can't factorize essentially anything. Once you get any practical error correction, the distance between 32-bit RSA and 2048-bit RSA is small. Similarly to how the hard part is to cause a self-sustaining fissile chain reaction, and once you do making the bomb bigger is not the hard part. This is what the experts know, and why they tell us of the timelines they do. We'd do better not to dismiss them by being smug about our layperson's understanding of their progress curve.
- xoa 6mo agoYeah, sounds like it's time to take this very seriously. Sobering article to read, practical and to the point on risk posture. One brief paragraph though that I think deserves extra emphasis and I don't see in the comments here yet: >In symmetric encryption, we don’t need to do anything, thankfully This is valuable because it does offer a non-scalable but very important extra layer that a lot of us will be able to implement in a few important places today, or could have for awhile even. A lot of people and organizations here may have some critical systems where they can make a meat-space-man-power vs security trade by virtue of pre-shared keys and symmetric encryption instead of the more convenient and scalable normal pki. For me personally the big one is WireGuard, where as of a few years ago I've been able to switch the vast majority of key site-to-site VPNs to using PSKs. This of course requires out of band, ie, huffing it on over to every single site, and manually sharing every single profile via direct link in person vs conveniently deployable profiles. But for certain administrative capability where the magic circle in our case isn't very large this has been doable, and it gives some leeway there as any traffic being collected now or in the future will be worthless without actual direct hardware compromise. That doesn't diminish the importance of PQE and industry action in the slightest and it can't scale to everything, but you may have software you're using capable of adding a symmetric layer today without any other updates. Might be worth considering as part of low hanging immediate fruit for critical stuff. And maybe in general depending on organization and threat posture might be worth imagining a worst-case scenario world where symmetric and OTP is all we have that's reliable over long time periods and how we'd deal with that. In principle sneakernetting around gigabytes or even terabytes of entropy securely and a hardware and software stack that automatically takes care of the rough edges should be doable but I don't know of any projects that have even started around that idea. PQE is obviously the best outcome, we ""just"" switch albeit with a lot of increase compute and changed assumptions in protocols pain, but we're necessarily going to be leaning on a lot of new math and systems that won't have had the tires kicked nearly as long as all conventional ones have. I guess it's all feeling real now.
- scorpionfeet 6mo agoThis is exactly how customers who do threat modeling see PQC. HN can armchair QB this all they want, the real money is moving fast to migrate. The analogy to a small atomic bomb is on point.
- aborsy 6mo agoI don’t know why the author likes AES 128 so badly. AES 256 adds little additional cost, and protects against store now decrypt later attacks (and situations like: “my opinion suddenly changed in few months”). The industry standard and general recommendation for quantum resistant symmetric encryption is using 256 bit keys, so just follow that. Every time he comes up with all sorts of arguments that AES 128 is good. Age should be using 256 bit file keys, and default to PC keys in asymmetric mode.
- cwmma 6mo agohe pretty explicitly states that AES 128 is not in any imminent danger and mandating a switch to 256 would distract from the actual thing he thinks needs to happen.
- aborsy 6mo agoHow would he know? Did he publish papers on it? You can’t just throw “Grover’s algorithm is difficult to parallelize” etc. It’s not same as implementation, especially when it gets to quantum computers. It’s very specialized.
- lucb1e 6mo agoSo why argue about whether AES-256 is worth it if we can just literally replace those 3 characters and be done with the upgrade? This was the smart move already in 2001 when Shor's algorithm was known and computers fast enough that we don't notice the difference. At least to me, it seems like less bikeshedding will be done if we abandon AES-128 and don't have to deal with all the people left wondering if that's truly ok Then again, something something md5. 'Just replace those bytes with sha256()' is apparently also hard. But it's a lot easier than digging into different scenarios under which md5 might still be fine and accepting that use-case, even if only for new deployments
- tptacek 6mo agoBecause you cannot "just literally replace those 3 characters and be done with the upgrade".
- kro 6mo agoThe argument to skip hybrid keys sounds dangerous to me. These algorithms are not widely deployed and thus real world tested at all. If there is a simple flaw, suddenly any cheap crawler pwns you while you tried to protect against state actors.
- kro 6mo agoI wonder, what is the impact of this to widely deployed smartcards like credit cards / EID passports? Aren't they relying on asymmetrical signing aswell?
- lucb1e 6mo agoYes. They will need to switch, so that hardware needs to be swapped out
- commandersaki 6mo agoRemindMe! 3 years "impending doom"
- griffzhowl 6mo agonoob question: can't we just use longer classical keys, at least as a stop gap?
- adgjlsfhk1 6mo agoThey're a pretty bad stopgap: https://bas.westerbaan.name/notes/2026/04/02/factoring.html https://bas.westerbaan.name/notes/2026/04/02/factoring.html. Going to RSA-32000 only buys you ~a year once QCs can factor RSA-2048. In order to get a standard that would resist quantum attacks for realistic time, we would need MB to GB keys at least (see https://eprint.iacr.org/2017/351.pdf https://eprint.iacr.org/2017/351.pdf for a hilarious post-quantum RSA attempt that used terabyte size keys)
- oncallthrow 6mo agoNo, and even if we could, it would require a migration of approaching the same difficulty of a migration to PQ, at which point why not just migrate to PQ
- upofadown 6mo agoSo this is the exciting paper: * https://arxiv.org/pdf/2603.28627 https://arxiv.org/pdf/2603.28627 The new thing here seems to be the use of the neutral atom technique. Supposedly we are up to 96 entangled qubits for a second or two based on neutral atoms. Shouldn't that be enough capability to factor 15 using Shor's?
- codethief 6mo ago> Trusted Execution Environments (TEEs) like Intel SGX and AMD SEV-SNP and in general hardware attestation are just f*d. All their keys and roots are not PQ and I heard of no progress in rolling out PQ ones, which at hardware speeds means we are forced to accept they might not make it, and can’t be relied upon. Slightly off-topic but: Does anyone know what the Signal developers plan on doing there to replace SGX? I mean it's not like outside observers haven't been looking very critically at SGX usage in Signal for years (which the Signal devs have ignored), but this does seem to put additional pressure on them.
- tptacek 6mo agoSignal uses SGX for features every other mainstream E2E messenger does in serverside plaintext.
- codethief 6mo agoIf by "mainstream E2E messenger" you mean WhatsApp and Facebook Messenger, sure. But I didn't realize those were the benchmark these days.
- tptacek 6mo agoWhat's the mainstream messenger you're considering that doesn't maintain serverside contact lists?
- codethief 6mo agoI never said I was considering any.[0] I'm strictly interested in what Signal is doing to keep (or even improve) its security guarantees. On that note, Signal wouldn't even depend on Intel SGX for security nearly as much if Signal PINs weren't user-chosen but instead auto-generated with enough entropy. Yes, contact discovery through phone numbers would still be challenging, but secure value recovery[1] just requires a key with enough entropy. [0]: For the record, Threema doesn't store your contact list server-side, unless you explicitly opt in. Similarly, now that Signal supports usernames, my understanding is that one could use the app without uploading one's contact list in plaintext. [1]: https://signal.org/blog/secure-value-recovery/ https://signal.org/blog/secure-value-recovery/
- nodesocket 6mo agoThe first and most obvious target will be Bitcoin. It’s market cap today is $1.4T. That’s a gigantic reward for any state actor or entity with the resources and budget to break it. Does this mean Bitcoin is going to $0? Absolutely not, it’s just going to take the community organizing and putting in the gigantic effort to make the changes. Frankly I’m not personally clear if that means all existing cold wallets need to be flashed/replaced? All existing Bitcoin miner software needs to be updated? All existing Bitcoin node software needs to be updated?
- goalieca 6mo agoBitcoin value will plummet if people lose trust in it.
- runeks 6mo ago> It’s market cap today is $1.4T. That’s a gigantic reward for any state actor or entity with the resources and budget to break it. The market cap of a cryptocurrency — or any commodity, really — is not its market value. If you have all bitcoins in existence and try to sell them you will crash the price to zero. The slope of that price graph — from the current market price to zero — determines how much you make in total. Most cryptocurrency exchanges have public order books, so you can see how much (and at what price per coin) you can actually sell into the market before you eat up all the bids. Last time I checked it was closer to $10bn than $1trn.
- btdmaster 6mo ago> “Doesn’t the NSA lie to break our encryption?” No, the NSA has never intentionally jeopardized US national security with a non-NOBUS backdoor, and there is no way for ML-KEM and ML-DSA to hide a NOBUS backdoor. The most concrete issue for me, as highlighted by djb, is that when the NSA insists against hybrids, vendors like telecommunications companies will handwrite poor implementations of ML-KEM to save memory/CPU time etc. for their constrained hardware that will have stacks of timing side channels for the NSA to break. Meanwhile X25519 has standard implementations that don't have such issues already deployed, which the NSA presumably cannot break (without spending $millions per key with a hypothetical quantum attack, a lot more expensive than side channels).
- Avamander 6mo ago> The most concrete issue for me, as highlighted by djb, is that when the NSA insists against hybrids The fact that only NSA does that and they really have no convincing arguments seems like the biggest reason why the wider internet should only roll out hybrids. Then possibly wait decades for everything to mature and then reconsider plain modes of operation.
- FiloSottile 6mo agoThus succeeding at making the telecommunications vendors used for Top Secret US national security data less secure, the obvious goal of the US National Security Agency, and the only reason they wouldn't use the better cryptography designed by Dr. Bernstein. /s Truly, truly can't understand why anyone finds this line of reasoning plausible. (Before anyone yells Dual_EC_DRBG, that was a NOBUS backdoor, which is an argument against the NSA promoting mathematically broken cryptography, if anything.) Timing side channels don't matter to ephemeral ML-KEM key exchanges, by the way. It's really hard to implement ML-KEM wrong. It's way easier to implement ECDH wrong, and remember that in this hypothetical you need to compare to P-256, not X25519, because US regulation compliance is the premise. (I also think these days P-256 is fine, but that is a different argument.)
- raron 6mo ago> Thus succeeding at making the telecommunications vendors used for Top Secret US national security data less secure, the obvious goal of the US National Security Agency NSA still has the secret Suite A system for their most sensitive information. If they think that is better than the current public algorithms and their goal is to make telecommunications vendors to have better encryption, then why doesn't they publish those so telco could use it? > Truly, truly can't understand why anyone finds this line of reasoning plausible. (Before anyone yells Dual_EC_DRBG, that was a NOBUS backdoor, which is an argument against the NSA promoting mathematically broken cryptography, if anything.) The NSA weakened DES against brute-force attack by reducing the key size (while making it stronger against differential cryptanalysis, though). https://en.wikipedia.org/wiki/Data_Encryption_Standard#NSA's_involvement_in_the_design https://en.wikipedia.org/wiki/Data_Encryption_Standard#NSA's... Also NSA put a broken cipher in the Clipper Chip (beside all the other vulnerabilities).
- ggm 6mo agoThis is the first well reasoned write up which makes me walk back from my "QC is irrelevant, and RSA is fine" position a bit. Well done! Thank you for putting this into terms a skeptic can relate to and understand. It helped me re-frame my thinking on risks here.
- tennysont 6mo agoA huge part of that, for me, was this from Scott Aaronson: > Once you understand quantum fault-tolerance, asking “so when are you going to factor 35 with Shor’s algorithm?” becomes sort of like asking the Manhattan Project physicists in 1943, “so when are you going to produce at least a small nuclear explosion?” That quote, alone, removed a lot of assumptions I had been carrying around.
- rogerrogerr 6mo agoCan anyone give the next layer of detail here? I understand the implications of this analogy, but looking for the underlying reasons the analogy is apt.
- apt-apt-apt-apt 6mo agoAIUI, the scientists achieved a self-sustaining nuclear chain reaction around 1943. That was the hard part, not even a small bomb yet, but a bomb just needed more fuel and scale. Fault tolerance is the hard part for QC, once it's achieved, the difference between factoring 35 and RSA-2048 is an engineering challenge, not an impossibility.
- nickelpro 6mo agoFault tolerance is a hard problem, assembling qubits for simultaneous gate operations is another hard problem. There are several dozen others. It is exceptionally unlikely CRQC will be achieved in our lifetimes, if ever. The closer example is economically-viable fusion power production, which today has better odds than CRQC but remains solidly in the "maybe" zone after decades of global investment. Even though fusion weapons had been achieved half a century beforehand. The bombs were actually relatively easy problems, in the scheme of things. It is never wise to listen to people who's jobs and funding are connected to the development of a technology on when that technology will arrive. The answer is always "soon".
- deleted 6mo ago[deleted]
- atlasagentsuite 6mo ago[flagged]
- bhaak 6mo ago> They weirdly[1] frame it around cryptocurrencies and mempools and salvaged goods or something [...] > [1] The whole paper is a bit goofy: it has a zero-knowledge proof for a quantum circuit that will certainly be rederived and improved upon before the actual hardware to run it on will exist. They seem to believe this is about responsible disclosure, so I assume this is just physicists not being experts in our field in the same way we are not experts in theirs. The zero-knowledge proof may come across as something of a gimmick, but two of the authors (Justin Drake and Dan Boneh) have strong ties to cryptocurrency communities, where this sort of thing is not unusual. I also don’t think it’s particularly strange to focus on cryptocurrencies. This is one of the few domains where having access to a quantum computer ahead of others could translate directly into financial gain, so the incentive to target cryptocurrencies is quite big. Changing the cryptographic infrastructure we rely on daily is difficult, but still easier than, for example in Bitcoin, where users would need to migrate their coins to a quantum-resistant scheme (whenever such a scheme will be implemented). Given the limited transaction throughput, migrating all vulnerable coins would take years, and even then, there would remain all those coins whose keys have been lost. Satoshi is likely dead, incapacitated, or has lost or destroyed his keys, and thus will not be able to move his coins to safety. Even if he has still access, the movement of an estimated one million BTC, which are currently priced in by the market as to be permanently lost, would itself be a disruptive price event, regardless if done with good or bad intentions. If you know which way the price will go (obviously way down in this case), you can always profit from such a price move, even if Satoshi's coins were blacklisted and couldn't be sold directly.
- TacticalCoder 6mo ago> Given the limited transaction throughput, migrating all vulnerable coins would take years ... How? I just googled: about 55 million addresses with bitcoin in them, about 144 blocks per day, about 3000 to 5000 tx per block. In something like 100 days all the coins would be moved to other addresses. I gotta say it'd be hilarious if to speed up that migration-to-quantum-resistant-addresses process, the Bitcoin community were to finally allow bigger blocks. EDIT: I take it if the network had to have full blocks for 100 days, then "shit would happens". Maybe they should force an orderly move: e.g. only addresses ending with "3a" are eligible to be moved in a block whose hash ends with an "3a", etc. to prevent congestion?
- BitsAndObjects 6mo agoThe OP should take a look at Secqai - potentially serverclass motherboard management processors and beyond which will implement PQ security and hardware enforced memory safety (from what I recall): https://www.secqai.com/ https://www.secqai.com/
- BitsAndObjects 6mo agoThis is in response to the comments in the article about TEEs and similar - such as TPMs - not catching up fast enough. Also companies like PQShield. The hardware (IP) exists to solve this in time, and is being integrated into products gradually. No idea how widespread it will become or over what timescale.
- wuiheerfoj 6mo agoI buy the argument 'we should prepare for Q-Day as crypto agility is hard', but the newest paper doesn’t change the timeline meaningfully. Given TFA accepts that error correction is the bottleneck for progress, and the gap between any and lots of error correction is small, and we presently have close to 0 error correction then nothing has practically changed with reduced qubit requirements. Of course, it’s totally fine to have and announce a change of view on the topic, though I don’t see how the Google paper materially requires it.
- kwar13 6mo agoOne of the author is from the Ethereum Foundation. Super interesting paper to read. This goes beyond just cryptocurrency. I wrote about it here a while ago: https://kaveh.page/blog/bitcoin-quantum-threat https://kaveh.page/blog/bitcoin-quantum-threat
- Tyyps 6mo agoI think people have to be extremely careful with this kind of opinion. In particular seeing such a push for post-quantum crypto while the current state of the art for quantum factorisation is 15 and 21 and the fact that current assumptions (for KEM in particular) are clearly not as studied as dlog. It's maybe good to remember that SIDH was broken in polynomial time by a classical computer 3 years ago... I'm really concerned by the current rush for PQ solutions and what are the real intentions behind it. On a side note there might even be a world where a powerfully enough quantum computer that break 2048 bigs RSA will never exists (Hooft, Palmer... Recent quantum gravity theory).
- mikestorrent 6mo agoThe largest number factorised on a quantum computer is 8,219,999 on a D-Wave machine (a quantum annealer, so not capable of running Shor's, but capable of being an actual shipping product you can use, unlike gate model machines). https://www.nature.com/articles/s41598-024-53708-7 https://www.nature.com/articles/s41598-024-53708-7 > Overall, 8,219,999 = 32,749 × 251 was the highest prime product we were able to factorize within the limits of our QPU resources. To the best of our knowledge, this is the largest number which was ever factorized by means of a quantum annealer; also, this is the largest number which was ever factorized by means of any quantum device without relying on external search or preprocessing procedures run on classical computers.
- nextaccountic 6mo agoThe D-Wave machine doesn't benefit from the quantum speedups discussed in the article
- Tyyps 6mo agoThis is quantum annealing and it has nothing to do with Shor (I should have been precise sorry). It is not clear at all that quantum annealing provides any speedup compared to a classical computer.
- mikestorrent 6mo ago
- burnerRhodov2 6mo agoTlDR: The real problem is building a system that can survive noise, errors, and decoherence. Once you solve that, scaling it up is non-trivial but has a very exponential path.
- sans_souse 6mo agoI know this may be outside of scope but I am very curious as to any thoughts you may have of a potential for ternary system at hw level?
- vasco 6mo ago> I simply don’t see how a non-expert can look at what the experts are saying, and decide “I know better, there is in fact < 1% chance.” Remember that you are betting with your users’ lives. Problem is the experts don't tell the truth, they say whatever game theory version of the world they came up with will make people do what they think people should do. If experts just said the literal truth it'd be different, and then when they would walk it back would be understandable. But when later it becomes clear the experts said outright lies because they thought it'd induce the right behavior, that goes out the window.
- thesz 6mo agoGiven that quantum computing (QC) can speed up training of neural networks (LLMs), it would be wise for Google to invest into QC as much as possible. Google with Softbank invested about $230M into QC last year. Microsoft, IBM and Google have spent on QC $15B combined, through all of the time they researched it. $15B spent in 20 years, less than $1B per year, by three companies. Google spent upwards of $150B last year in datacenters. This may tell us something about how close we are to a working quantum computing.
- elwray 6mo agoFor the uninitiated, could you share your perspective on how feasible quantum computing is? Isnt it built on quantum entanglement which seems to break universal speed limit? Is this a feasible engineer or just a scientists imagination?
- enesz 6mo ago[flagged]
- NeoBild 6mo agoThe BLAKE3 angle here is interesting — we switched from SHA-256 to BLAKE3 for hash-chaining in a local multi-agent security orchestrator precisely because of this kind of forward-looking pressure. Not the same threat model, but the instinct to not build new systems on classical primitives feels validated by this post.
- hacker_88 6mo agoY2K 1.5
- nathanmcrae 6mo agoSide question, but does anyone know why specifically 2^-32 is the target floor for attacker success (in footnote 3)? I found another mention of the 2^-32 target in [0], but I'm not even certain they're related. [0] https://csrc.nist.gov/csrc/media/Events/2023/third-workshop-on-block-cipher-modes-of-operation/documents/accepted-papers/Practical%20Challenges%20with%20AES-GCM.pdf https://csrc.nist.gov/csrc/media/Events/2023/third-workshop-...