Not in theory. In bytes, measured in this browser, from keys generated a moment ago.
Tool 1 of 7 · check your own system
This needs JavaScript; it runs entirely in your browser. Nothing you paste or look up is sent anywhere except, if you choose the domain tab, a public certificate-transparency log.
One paste, or one domain name: this is the fast path. It reads what you give it with the same parser as the full Inventory below, then hands it straight to the Sequencer for a live verdict. If you already know the four instruments on this page, skip straight past this to the Size Cliff.
Your current position
Nothing tracked yet.
Everything above runs on what you paste or type in, so it only ever sees what you already knew to bring it. The harder, more useful version checks your systems the way an outsider would: probing your own public endpoints directly, the same evidence an attacker or an auditor would gather, without needing you to hand anything over first. That probe service doesn't exist yet. Leave an email and you'll hear when it does.
One email, when it ships. We never sell or share this.
Seven tools: Quick Checkone paste, one answer The Size Cliffwhat PQ costs on the wire The Inventoryread your own artefacts The Sequencerwhen you can finish The Oddsagainst 32 real forecasts The Harvest ClockMosca's inequality, played The Proofrun the cryptography yourself
Post-quantum TLS is not slow because the mathematics is slow. ML-KEM is fast: thousands of key generations a second in JavaScript. It is expensive because the objects are large, and the network was built around the assumption that they are small.
The key exchange is the famous problem and the smaller one. A hybrid key share pushes the ClientHello past one packet. That is a one-time cost, and browsers already work around it.
The signature is the real problem. A certificate chain carries several signatures, and a post-quantum signature is roughly fifty times larger than the one it replaces. Past a threshold the server's reply no longer fits the initial congestion window, and every new connection pays an extra round trip.
And the obvious metric misleads. Pick a signature scheme by public-key size and you will choose the one with an eight-kilobyte signature. Move the controls below and watch which choice breaks.
That asymmetry stopped being a forecast some time ago. A 2026 measurement of the live internet found 49.3% of scanned domains already negotiating hybrid post-quantum key exchange, against 0% adoption of post-quantum certificates (Dubey & Varshney, arXiv:2606.16473, "Measurement Study of Post-Quantum Readiness of Internet: 2026"). The cheap half of the problem is nearly half deployed; the expensive half hasn't started. Part of why: a signature's job ends the moment a handshake finishes, so it can wait until a quantum computer is closer to real: the exact "harvest now, decrypt later" logic the Odds below puts a number on, run in reverse.
Tool 2 of 7 · measured, not modelled
This figure needs JavaScript; it generates real post-quantum keys in your browser. Nothing is sent anywhere.
Every cryptographic number below is the length of a real object (a key, a ciphertext, or a signature) that your browser generated when you clicked. Building it this way catches errors a lookup table would inherit: several published sources give an ML-DSA-65 signature as 3,293 bytes, but sign one and measure it and the answer is 3,309, which is what FIPS 204 specifies.
The distinction is stated on every row rather than averaged away, because mixing the two is how confident wrong numbers get published.
So the absolute totals are a model; the differences between two choices are exact. The framing is identical on both sides of any comparison, so it cancels, and the difference is the whole subject. When the widget says a hybrid key share costs 1,184 bytes more than X25519, that number is measured, not assumed.
The limits it is measured against are real: a 1,460-byte TCP payload is what fits in one packet on a standard 1,500-byte Ethernet MTU, and the initial congestion window has defaulted to ten segments since Linux 2.6.39 (May 2011); the IETF standardized the same value two years later as RFC 6928 (April 2013). A server flight past 14,600 bytes waits for an acknowledgement before it can finish.
Set the signature to SLH-DSA-128s. Its public key is 32 bytes: smaller than ML-DSA-65's 1,952, and exactly the same size as Ed25519's. By the metric most people reach for first, it is the compact choice.
Its signature is 7,856 bytes. A chain carries more signatures than public keys, so the scheme with the smallest key produces by far the largest handshake. SLH-DSA earns that cost fairly, resting only on the security of a hash function with no lattice assumption to be wrong about, but the trade is the opposite of the one the key size advertises.
A fifth algorithm exists, and it is deliberately not in the widget above. On 11 March 2025, NIST selected HQC (Hamming Quasi-Cyclic) as a backup encryption standard specifically because it rests on a different hard problem than ML-KEM (error-correcting codes, not structured lattices) so a single mathematical break cannot take down both at once. A draft standard is due in 2026, with a final expected in 2027 (NIST, nist.gov, 11 Mar 2025). It stays out of the size widget above for the same reason every other number on this page is generated live rather than read from a table: no production-grade, browser-safe HQC implementation is in wide use yet to generate a real key with. And it will very likely stay out of CNSA 2.0 specifically: the NSA's own FAQ states plainly that it does not currently plan to add future NIST post-quantum standards to that suite, keeping the algorithm list fixed through the transition rather than chasing every new addition.
Check yourself
Post-quantum TLS costs more on the wire than classical TLS. Which part is the bigger problem?
ML-KEM is fast, and the hybrid key share is a one-time cost that browsers already work around. The signatures are the real problem: a chain carries several, a post-quantum signature is roughly fifty times larger than the one it replaces, and once the server’s reply passes about 14,600 bytes it has to wait for an acknowledgement, so every new connection pays an extra round trip.
Check yourself
SLH-DSA-128s has a 32-byte public key; ML-DSA-65 has 1,952 bytes. For a TLS handshake, which is the more compact choice?
A chain carries more signatures than public keys, so the scheme with the smallest key produces the largest handshake. SLH-DSA earns that cost (it rests only on the security of a hash function), but the trade is the opposite of the one its key size advertises.
Tool 3 of 7 · discover what you run
📎 Drop .pem/.crt/.cer/.pub/.json files here, or
, read straight into the box below, alongside anything already pasted.
This tool parses in your browser. It needs JavaScript. Nothing you paste is transmitted; there is no server to transmit it to.
The tool below this one plans a migration across whatever estate you describe. Its own list of limits admits the obvious: it discovers nothing. A migration programme lives or dies on the inventory, and the inventory is the hard part.
So start here instead. Paste the artefacts you already have (a certificate chain, the contents of an authorized_keys file, a JWKS document) and this reads them. Not pattern-matches them: reads them, decoding the ASN.1 byte by byte, the same structure openssl x509 walks. Every field in the table is taken out of the artefact. Nothing is entered by you, and nothing is looked up in a table of what a key of that name is supposed to be.
The parse is also checked against a second implementation. For every key your browser's own WebCrypto can import, we hand it the exact bytes and read the algorithm back from the browser. Agreement earns the row a CONFIRMED tag. Where WebCrypto has no algorithm at all (ML-DSA and SLH-DSA today, Ed25519 on older browsers) the row says PARSED: our decoder alone read it, nothing independent has.
A certificate contains two algorithms, not one. There is the key it carries, and there is the algorithm its issuer used to sign it. They are usually different, and they usually belong to different people. An inventory with one algorithm column per certificate silently loses half the estate, and the half it loses is the half you may not control.
Load the example and look at api.example.com: an ECDSA P-256 key, signed sha256WithRSAEncryption. Rotating that leaf to ML-DSA changes nothing about the RSA signature above it. If that issuer is your own internal CA, it is a prerequisite and the sequencer below will schedule it as one. If it is a public CA, it is not an engineering task at all: it is a procurement conversation, on somebody else's timetable.
Your harvest-now-decrypt-later exposure is not in any of these files. In TLS 1.3 the certificate key signs; it never encrypts. The key exchange that protects the traffic is an ephemeral ECDHE or X25519 share negotiated per connection, and it appears in no certificate, no authorized_keys file and no certificate-derived CBOM.
That distinction decides which risks are retroactive. A signature algorithm broken in 2032 cannot forge a 2026 handshake after the fact; forgery only works forwards. A key exchange broken in 2032 decrypts every recording anybody made of it in 2026. So the asset with the worst exposure in most estates is the one no file will hand you, and the tool tells you to add it by hand rather than scoring you on whatever it happened to be able to read.
cyclonedx-cli before you file it anywhere that matters; we cannot run the official validator inside a page with no network.Check yourself
A signature algorithm and a key-exchange algorithm are both broken in 2032. What does each break let an attacker do to traffic recorded in 2026?
A signature broken in 2032 cannot forge a 2026 handshake after the fact: forgery only works forwards. A key exchange broken in 2032 decrypts every recording anybody made of it in 2026. That is why the asset with the worst exposure in most estates is the key exchange, which no certificate file will hand you.
Tool 4 of 7 · sequence the migration
This tool computes in your browser. It needs JavaScript. Nothing you type is sent anywhere; there is no server to send it to.
The figure above measures a decision. This one measures you. Describe what you run (the rows below start from a realistic example, and every one is editable) and it will tell you which of your assets are already past saving, in what order to migrate, and whether your deadline is reachable at all.
The idea that makes this different from a readiness scorecard. Mosca's inequality says you are exposed when X (how long the data must stay secret) plus Y (how long migration takes) exceeds Z (how long until a quantum computer can break it). Almost everyone plugs in an asset's own effort as Y. That is wrong the moment anything depends on anything. Your real Y is when the plan reaches that asset: an embedded fleet sitting behind a code-signing pipeline sitting behind a certificate authority does not take eight quarters, it takes however long all three take in sequence at your actual capacity. So the schedule feeds back into the risk, and changing the order changes who is exposed. Change it below and watch the last column move.
And nobody knows Z. Predicting it is what every other tool in this space does and none of them can justify it. So the last column does not predict: it reports the breakeven, this asset is exposed unless a cryptographically relevant quantum computer is further away than N years. That is a claim you can check against your own belief instead of adopting ours.
The table above says which quarter each asset finishes; a planning meeting wants to see it. Same numbers (assess(), unchanged) as a bar per exposed asset, against the deadline you picked above.
Build a plan above to see it drawn here.
The same plan, checked against four dated lines drawn from the instruments named at the bottom of this page. Nothing new is computed here: this is the sequencer's own feasibility() run once per date instead of once against whichever one you last clicked above. Read the four as dates, not as a roll-call of instruments: Executive Order 14412 contributes two of them, 2030 is also CNSA 2.0's exclusive-use date for signing and networking and the EU roadmap's high-risk date, and 2035 comes from a NIST report that is still a draft. The EU roadmap's end-of-2026 milestone is deliberately absent: it asks you to have an inventory, which is the tool above, not a migration this scheduler can pass or fail.
Build a plan above to see it checked here.
Two more dates are worth knowing even though the scheduler above does not check either of them (both are procurement gates, not migration deadlines) so a pass/fail run against an estate would misstate what they do. 1 January 2027 is when CNSA 2.0 requires new National Security System acquisitions to be compliant by default, earlier than and different from the 2030 exclusive-use date already run above, and it binds what you can buy, not what you must have already replaced. 21 September 2026 is when NIST moves every remaining FIPS 140-2 validation certificate to Historical status: existing validated modules keep working, but CMVP's own guidance is that agencies should not put a Historical-status module into a new procurement from that date on. Neither date changes what your estate needs to survive; both change what you are allowed to buy next.
Check yourself
Your team is big enough for a post-quantum migration, but the chain certificate authority, then code signing, then the device fleet takes longer, in sequence, than the time you have left. What does hiring more people do?
There are two different infeasibilities. If you are short of total capacity, hiring helps and no ordering does. If the dependency chain is longer than the time remaining, you have enough people and it still cannot be done: each step waits for the one before it.
Tool 5 of 7 · put a distribution behind the date
This tool computes in your browser. It needs JavaScript, and it reads the plan you build in the Sequencer above, so nothing here is typed twice.
The Sequencer above gives every exposed asset a breakevenZ: the year a quantum computer would have to exist before your plan stopped protecting it. That number is exact arithmetic sitting next to a number nobody has: nobody knows when a cryptographically relevant quantum computer (CRQC) will exist. Reading "15.75 years" as a verdict is exactly the mistake the rest of this page exists to catch, so this tool puts a real distribution behind it instead of leaving you to supply your own gut feeling, and lets you test it against the estate a hospital, a bank or a utility would recognise.
The Global Risk Institute's Quantum Threat Timeline Report 2024 (Mosca & Piani, December 2024) asked 32 named experts for a likelihood range at five time horizons, from 5 to 30 years. Their answers, read straight off the report's own chart, are the only ten numbers this tool trusts: an optimistic and a pessimistic bound at each of the five horizons. Everything between them is linear interpolation, stated as a modelling choice, the same way the Size Cliff above states what it measured versus what it modelled. Past 30 years the survey stops, and so does this tool's precision: it reports a floor on your risk rather than inventing a tail nobody surveyed.
There is one true future, not one per asset. Every line in your estate is judged against the same drawn year, because that is what "nobody knows Z" really means: Z is a single unknown shared by everything you own, not an independent coin flip on every row. So "your whole plan is breached" always works out to exactly the odds of your single riskiest asset, and shrinking that one number by reordering the plan is the same game the Sequencer above already had you playing. This tool just prices it, against opinions 32 people were willing to put their names to.
Test a specific year and the answer is plain arithmetic: a chosen year either beats an asset's breakevenZ or it doesn't. The distribution only earns its keep on the harder question: not "am I safe if it happens in 2035," but "how worried should I be." Two thousand rolls answer that by counting, and the running tally converges on the same number the curve gives exactly.
And a probability is not a plan. The tool sweeps all four migration orderings and a capacity increase behind the scenes and tells you which single change moves the number, usually free (reorder) before it is ever paid (hire), then writes the whole thing out as a plain-text briefing you can hand to someone who was not in this browser tab.
This stopped being a research question. Each of these is a published instrument with a number in it, though they do not all carry the same force, and the list says which is which:
And the reason none of those dates can simply be waited out: harvest now, decrypt later. Traffic captured today is decrypted whenever the capability arrives, so the exposure is retroactive. Michele Mosca's inequality states it in one line: if X (how long your data must stay secret) plus Y (how long your migration takes) exceeds Z (how long until a cryptographically relevant quantum computer), you are already late. The arithmetic is certain; Z is a guess, and nobody knows it. That is exactly why X and Y are the only two you control.
What a machine capable of this would have to be is a separate question, answered with resource estimates rather than adjectives, on the Bitcoin page.
Check yourself
Your records must stay secret for 10 years, a migration would take 5, and the earliest plausible date for a machine that breaks your encryption is 12 years away. By Mosca’s inequality, where do you stand?
Mosca’s inequality: you are exposed when X (how long the data must stay secret) plus Y (how long migration takes) exceeds Z (how long until a machine can break it). 10 + 5 = 15 is more than 12, so data encrypted today is still secret-bearing after it could be read. Nobody knows Z; X and Y are the two you control.
It comes up in almost every conversation about this page, and it deserves a precise answer: quantum key distribution (QKD) is real, it works, and it is not what this page is about. Everything above (the Size Cliff, the Inventory, the Sequencer) is a software answer, changing the algorithms your existing internet already runs. QKD is a hardware answer, built on completely different physics, and mixing them up is how migration plans end up skipping the part they should be doing.
The core trick differs from everything else on this page. A classical or post-quantum key exchange proves a secret was shared correctly through mathematics: the hard problem an eavesdropper cannot solve. QKD instead uses a fact about measurement itself: encode a bit in a quantum state, and measuring it in the wrong basis disturbs it. The same no-cloning theorem this site's own Machinery page proves forbids an eavesdropper from covertly copying the state first and measuring the copy. Listen in, and the two ends of the channel can detect it directly, as a rise in errors on bits they sacrifice to check. Nothing on this page can do that: a stolen ML-KEM ciphertext leaves no trace of having been read.
BB84 (Bennett & Brassard, Proc. IEEE Int. Conf. Computers, Systems and Signal Processing, Bangalore (1984), 175–179) is the original protocol and still the reference point: Alice sends single photons, each encoding a bit in one of two conjugate bases (say, rectilinear or diagonal polarization), chosen at random; Bob measures each in a randomly chosen basis of his own; afterwards, over an ordinary public channel, they announce only their basis choices and keep the bits where the bases happened to match, discarding the rest. An eavesdropper who measures in the wrong basis (which she must, half the time, with no way to know Alice's choice in advance) collapses the state and introduces detectable errors in the kept bits. The no-cloning bound behind this is solid; the exact noise threshold depends on which security proof you use.
B92 (Bennett, Phys. Rev. Lett. 68, 3121–3124 (1992)) simplifies this to just two non-orthogonal states rather than four, proving that the disturbance argument never needed BB84's extra structure, only non-orthogonality itself, at the cost of being more sensitive to loss in a real fibre.
Ekert91 (E91) (Ekert, Phys. Rev. Lett. 67, 661–663 (1991)) takes a completely different route to the same guarantee: instead of single photons in chosen bases, Alice and Bob each hold one half of an entangled pair, and security is certified by checking that their correlations violate a Bell inequality: the exact CHSH statistic this site's own CHSH game lets you win at over the classical 75% ceiling. A classical eavesdropper who tries to pre-script the correlations is bound by the same 75% limit the game teaches; entanglement present in the channel is the only way to beat it, which is what makes the violation itself the security proof, not an assumption bolted on afterward.
This is not a thought experiment: it has flown, twice, on the same satellite. China's Micius satellite demonstrated decoy-state BB84 from orbit to a ground station at kilohertz key rates over distances up to 1,200 km (Liao, Cai et al., Nature 549, 43–47 (2017)), and three years later demonstrated the entanglement-based E91 approach directly, distributing a secret key between two ground stations 1,120 km apart without a trusted relay in between, at a measured rate of 0.12 bits per second (Yin et al., Nature 582, 501–505 (2020)). That number is not a typo, and it tells the story in one figure: real, working, entanglement-secured key distribution across a continental-scale distance, at a rate that would take over a minute to hand you a single 8-byte number.
That rate is close to the physical limit of what QKD can do at that distance, which is exactly why it is not a candidate for the problem this page exists to solve. Several national cybersecurity agencies say so plainly: the NSA's own Quantum Computing and Post-Quantum Cryptography FAQ (August 2021) states it does not support using QKD to protect national security communications and does not expect to certify QKD products until its limitations are overcome, judging post-quantum cryptography "more cost effective and easily maintained." A 2025 peer-reviewed comparison (Aquina, Cimoli, Das, Hövelmanns, Weber, Okonkwo, Rommel, Škorić, Tafur Monroy & Verschoor, EPJ Quantum Technology 12, 51 (2025)) surveys the same conclusion across ANSSI (France), BSI (Germany), NLNCSA (Netherlands) and NCSC (UK), the UK agency's own position being that it "does not endorse the use of QKD for any government or military applications." The reasons named are concrete, not political: QKD needs dedicated, special-purpose optical hardware rather than a software update, so it cannot run over the internet this page's tools measure; it does not remove the need for classical or post-quantum cryptography at all, because the classical channel used to compare bases still has to be authenticated or the whole protocol is open to a man-in-the-middle, and that authentication step is exactly the kind of signature this page's Size Cliff measures; distance without repeaters tops out well short of global reach, so long links fall back to trusted relays (physical boxes that must themselves be defended) reintroducing the very single point of failure QKD was meant to remove; and the same sensitivity to disturbance that reveals an eavesdropper also hands an attacker a cheap denial-of-service lever, since jamming the channel and eavesdropping on it look identical from the error rate alone.
This is not an argument that QKD is a failure: Micius is a real, hard-won achievement, and QKD is the right tool for a narrow set of point-to-point links where everlasting confidentiality is worth the dedicated fibre and the cost. It is an argument that QKD and post-quantum cryptography answer different questions. This page's question, how do you re-key the internet as it already exists, at internet scale, before 2030–2035, has exactly one candidate answer among the two, and it is the one every tool above measures.
Check yourself
Why is quantum key distribution not the fix for the problem this page is about?
QKD is real: it has flown, twice, on the same satellite. But it is a hardware answer, not a software update, so it cannot run over the internet the tools here measure; and the classical channel used to compare bases still has to be authenticated, which is the kind of signature the Size Cliff measures.
Tool 6 of 7 · the inequality, played
Nothing above is new: this is the same inequality, made playable instead of read once and left as a paragraph. Move the three sliders. Most starting positions come back already late, and correctly so: for the great majority of X, they are.
This needs JavaScript; it is plain arithmetic, run in your browser. Nothing you move here is sent anywhere.
This is deliberately the simplest instrument on the page. For a real estate instead of a guess, use the Sequencer; for a real distribution behind Z instead of one slider, use the Odds above. This one exists to make the inequality itself click in ten seconds.
Tool 7 of 7 · stop citing it, run it
Every tool above this one measures or models. None of them ever runs the cryptography end to end, which means that up to this point “post-quantum cryptography works” has been an assertion on this page, carried by citation. So: run it. Real ML-KEM-768 and ML-DSA-65, in this tab, on your text, with the results checked rather than tabulated.
The part that matters is not the signature verifying. A function that returned true unconditionally would look identical on screen. The evidence is in the refusals: flip one bit of a 3,309-byte signature and verification has to fail.
This needs JavaScript and ES modules; it generates real post-quantum keys in your browser. Nothing you type here is sent anywhere; there is no server to send it to.
One thing worth staying for, in act one: a tampered ML-KEM ciphertext raises no error. FIPS 203 specifies implicit rejection, so decapsulation quietly returns a different 32-byte secret instead of complaining. The handshake then dies later, somewhere that looks unrelated. If you are integrating a KEM and your error path is waiting for an exception, it will wait forever.
Stated plainly, because a page about cryptography that oversells itself is worse than useless.
Found an error on this page? Tell us. The correction runs louder than the original.