Remote profile

Alice & Bob published a resource estimate today: 22,593 cat qubits could factor RSA-2048 in about three days, and the elliptic-curve discrete logarithm on secp256k1, Bitcoin's curve, would take about an hour on at most 29,588 qubits.

https://postquantum.com/security-pqc/alice-bob-rsa-2048-cat-qubits/

What the paper achieves:
• The smallest RSA-2048 estimate I know of that runs in days, and the lowest qubits times runtime of any that comes with a paper.
• A physical compilation of Shor's algorithm for cat qubits, with layouts and schedules for every qubit of the dominant subroutines.
• A proposed common benchmark, a 512-bit discrete logarithm, that other architectures could run before RSA-2048.

What it assumes:
• No bit-flips during the run, which the paper equates with a bit-flip time of about 100 years per qubit.
• The best peer-reviewed measurement with quantum control is 22 seconds. Alice & Bob's own preliminary results reach 44 minutes, and about four hours on qubits where it has not yet shown the same level of control.
• Its largest chip with error-correction results has 12 cat qubits, running a distance-3 repetition code that is not yet below threshold.
• A variant with an extra error-correction layer relaxes the bit-flip requirement to about 1.3 hours, at about 45,000 qubits, but no gate set exists yet for that layer.

What it changes:
• No compliance date. NIST's final IR 8547 deprecates RSA and ECC after 2030 and disallows them after 2035.
• The order of work, possibly: on the same machine an elliptic-curve key takes about an hour against about three days for RSA-2048.

Free webinar on the 2026 estimates, today at 15:00 UTC, recording for everyone who registers: https://quantumacademy.com/event/webinar-q-day-estimates/

#QuantumComputing #PQC #Cryptography #InfoSec #QDay #CRQC

(One of) the year's biggest papers on what it takes to break RSA and ECC goes public tomorrow. I have read it. It is serious work, but it is also going to be badly misread. It changes what a codebreaking quantum computer could look like, if one big assumption holds. Expect this paper to dominate the conversation for days, including various sky-is-falling takes.

Luckily, our Q-Day estimates webinar was already on the calendar for tomorrow. The paper goes public one hour before we go live. This year Iceberg Quantum, Google, Oratomic and IonQ each published careful resource estimates, and each time the headlines exaggerated. Expect the same tomorrow.

We will put tomorrow's paper next to previous ones and go through:

- what it actually achieved in this paper and throughout the year (and with what assumptions)

- whether any of it moves Q-Day

- what to tell your board when it asks, because they will

Free one-hour webinar from Quantum Academy and Applied Quantum, tomorrow, 29 October, at 15:00 UTC (16:00 CET, 11:00 ET). It will be one of the first independent readings of the paper.

https://quantumacademy.com/event/webinar-q-day-estimates/

#QuantumComputing #PostQuantumCryptography #PQC #QDay #CyberSecurity #CISO #Cryptography #QuantumSecurity

NIST published the final version of IR 8547, its plan for retiring quantum-vulnerable public-key cryptography, on October 27.

NIST deprecates RSA and ECDSA signatures at 112 bits or more, EdDSA at 128 bits or more, and DH, MQV and RSA key establishment at 112 bits or more, all after 2030. All of them are disallowed under NIST standards and guidelines after 2035.

P-256, P-384, RSA-3072 and Ed25519 had no deprecation step in the November 2024 draft and are now deprecated on the same day as RSA-2048.

A deprecated algorithm is usable, with a risk the data owner must examine before deciding to continue. A disallowed one is no longer allowed for the stated purpose. Decrypting old ciphertext and verifying old signatures fall under a third status, legacy use. NIST doesn't say how long it will last for these algorithms.

From 2031, anyone following NIST's statuses needs a recorded risk decision for each classical-only key exchange or signature they keep.

For hybrid key establishment, the SP 800-56C composite technique stays allowed even with a disallowed input, and a combination with at least one approved input can be FIPS 140-validated. Under SP 800-56C Rev. 2, a hybrid secret Z || T qualifies for approved key derivation when Z comes from an approved scheme. An ML-KEM secret counts.

The IETF put ML-KEM first in X25519MLKEM768, so the ML-KEM implementation is the component that must be validated. In SecP256r1MLKEM768 and SecP384r1MLKEM1024, the ECDH secret comes first. In SP 800-227, NIST already approves combiners with the approved secret in any position, but in IR 8547 it ties the either-order rule to a promised SP 800-56C update. Vendors shipping those groups should ask their labs how they'll be treated after 2035.

I'd keep the TLS combiner inside TLS. In SP 800-227 section 4.6.3, NIST says a combiner that uses only the shared secrets doesn't, in general, preserve IND-CCA security when only one component remains secure. The security analysis in RFC 10024 relies on the TLS 1.3 transcript.

The X25519MLKEM768 key share adds about 1.2 KB, so the ClientHello can span two packets, and some servers reject it instead of falling back to classical key exchange. Log the negotiated group for each production connection, and check every hop separately.

Hybrid key exchange protects session keys only, so the RSA or ECDSA chain needs its own migration. An ML-DSA-44 signature is 2,420 bytes, against 64 to 72 for ECDSA on P-256.

NIST gives key establishment and signatures the same dates in Tables 2 and 4. In the same report, it explains that harvest now, decrypt later makes key establishment more urgent.

In Section 3.1.2, NIST still says authentication may stay classical until a CRQC is available and then switch immediately. Under Table 2, the same algorithms are disallowed after 2035 either way.

Dual signatures get a definition but no encoding and no post-2035 status. Contracts and archives that must stay verifiable for decades need evidence records renewed with post-quantum algorithms, but NIST doesn't mention them in IR 8547.

HQC is the alternative KEM, with a FIPS in development. ML-KEM-768 is the default parameter set. LMS and XMSS are named for software and firmware signing.

NIST added Ascon to the symmetric tables and printed its AEAD entry as "AES-AEAD128" by mistake. It also corrected SHAKE256's preimage strength from 512 to 256 bits. The statuses that module validation applies come from SP 800-131A, and its Revision 3 is still a draft.

Full analysis, with a draft-to-final comparison table: https://postquantum.com/security-pqc/nist-ir-8547-final/

I teach the US requirements behind these dates in PQC Compliance: United States at Quantum Academy: https://quantumacademy.com/courses/pqc-compliance-us/

#infosec #cryptography #PQC #postquantum #NIST #TLS #FIPS