How to attack TLS in PQC decade, part I

Transcript

1. How to attack TLS in PQC decade, Part I Daobing Li 2026-04-10
2. News last week Bitcoin uses secp256k1 curve. And TLS ECDHE and ECDSA use secp256r1 (P-256). The two curves are very similar. So, in 2029, Bitcoin is in danger, TLS based on ECDHE/ECDSA also in danger.
3. How TLS works (e.g. TLS 1.3) • Authentication: verify identity, avoid MitM 1. Server sends Certificate(who am I) + CertificateVerify(a proof) 2. Client verify the server identity 3. Server also can verify the client identity(mTLS) • Key Exchange(KEX): generate a shared-secret 1.Client provides the supported param: groups + key_share 2.Server pick a group and send key_share (or HRR) 3.Now Client and Server got a shared-secret • Data Transfer: secure messaging 1. Derive a session key with shared-secret, use it encrypt and sign the data
4. TLS 1.3 handshake (without mTLS/HRR/...) Client Server ClientHello + groups + key_share ServerHello + key_share {EncryptedExtensions} {Certificate} {CertificateVerify} {Finished} {Finished} [Application Data] {XXX}: means the handshake packet is encrypted
5. How to attack TLS • Attack Key Exchange • Attack Authentication • Attack Data Transfer • And o Downgrade attack o Brute force
6. How to attack TLS • Attack Key Exchange (Part I) • Attack Authentication (Part II) • Attack Data Transfer (Part II) • And o Downgrade attack (Part I) o Brute force (Part I) • And o The Design & Evolution of TLS (Part II)
7. TLS: Downgrade attack Client Attacker Server 1. TLS 1.2 CH 2. TLS Alert / TCP RST Server does not support TLS 1.2, switch to 1.1 3. TLS 1.1 CH Can't attack, block it Attackable, forward it and start attack 4. TLS 1.1 CH
8. TLS Downgrade attack - How to prevent it o Make the client know that the server can support higher version ▪ TLS 1.3 server - Return a specified random if client version is lower than TLS 1.3 o Make the server know that client had tried a higher version ▪ RFC 7507： TLS Fallback Signaling Cipher Suite Value (SCSV) ▪ for Preventing Protocol Downgrade Attacks ▪ Client send an extra cipher(TLS_FALLBACK_SCSV) to the server
9. How to attack Key Exchange • Key Exchange o RSA (TLS 1.0 ~ TLS 1.2) o DHE (TLS 1.2, "deprecated" in TLS 1.3) o ECDHE (TLS 1.2, TLS 1.3) o MLKEM (TLS 1.3, PQC) o Hybrid (TLS 1.3 PQC)
10. Key Exchange: RSA (for TLS 1.2 or before) • How it works? o Client: send ClientHello to server o Server: send RSA cert to client (including public key) o Client: generate a random secret (PMS, pre-master secret), encrypt it with the public key, send it to server o Server: decrypt the PMS with private key o Now Client and Server have a shared-secret(PMS) • Sounds perfect, what's the problem?
11. How to attack RSA KEX? • decrypt the PMS with private key o Attacker can record all the valuable TLS traffic o If a private key leaked, attacker can find the matched TLS traffic, and decrypt it. • So, we have DHE (Diffie-Hellman Ephemeral)
12. Key Exchange: DHE (TLS 1.2 & TLS 1.3) • Client: send ClientHello to server (an example for TLS 1.2) • Server: o Choose prime number p, a generator number g, a random private key x o Send client: p, g, gx (mod p) • Client: o Choose a secure random number y o Send server: gy (mod p) • Now o Server: based on gyand x, it can calculate (gy)x = gxy (mod p) o Client: based on gx and y, it can calculate (gx)y = gxy (mod p) o shared-secret is gxy (mod p) • No worry about private key leaking, it's called PFS(perfect forward secrecy)
13. How to attack DHE • Problem: Send client: p, g, gx (mod p) • Whether attacker can get x from the above data? o NP problem, but we can have a try when number is not huge. • Considering o Let f(x) = gx (mod p) o If we know that x0 that f(x0) = 2, and x1 that f(x1) = 3, can we resolve f(x) = 6? o YES, x = x0+x1, f(x) = f(x0+x1) = f(x0) * f(x1) = 2*3 = 6 o Can we resolve f(x) = 24 or 48 or 96? YES o Can we resolve f(x) = (2^a * 3^b) % p? YES o What if we also know f(x2) =5/7/11/... can Resolve More
14. How to attack DHE • Are you sure you can know that x0 which f(x0) = 2 o Frankly said, it's hard to calculate x0 o But what if p and g is fixed, and attacker has state-level computational resources? o It can pre-compute for all the small primes • It's called LOGJAM attack (2015) o https://en.wikipedia.org/wiki/Logjam_(computer_security) o 512 bits: broken o 1024 bits: maybe broken by state-level computational resources • RFC 7919: Negotiated Finite Field Diffie-Hellman Ephemeral Parameters • for Transport Layer Security (TLS) o Introduce named group for DHE starts with 2048bits • So we have FFDHE/ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) o FFDHE: 2048bits or larger pre-defined DHE, why we need a pre-defined? Not a random?
15. Key Exchange: ECDHE (TLS 1.2 & TLS 1.3) • Process is almost same with DHE, but it uses Elliptic Curve. So, it is immune to prime factorization-based exploits
16. How to attack (EC)DHE (small subgroup) • DHE/ECDHE still bases on mod p o Expect: about p different private keys can generate p different public keys • How do you know the public key can use all the numbers [1, p-1] • For example, for DHE, if g=2, p=31 o Public key is (2^x) % 31 o Expect: 30 different public keys: 1-30 (order 30) o Got: ONLY 5 public keys: 1, 2, 4, 8, 16 (order 5)
17. How to attack (EC)DHE (small subgroup) • If DHE/ECDHE reuse private key x, it will become DH/ECDH in a limit time • Client (attacker) sends a key_share k with order=5 • Server sends a Server Hello followed by EE(EncryptedExtension) o If EE can be decrypted with k, it means the private key x = 1 (mod 5) o If EE can be decrypted with k*k, it means the private key x = 2 (mod 5) o … • Client sends a key_share k with order=2/3/5/7/11, … • Got the private key with Chinese remainder theorem • We can get > 1bit info for private key from every round, for 256bit secret key o About 100 round will get the private key • So, re-use key_share is DANGER if subgroup problem exists
18. How to attack (EC)DHE (small group) • DHE: FFDHE should have no problem, random DHE: vulnerable • P-256 o Good news: There is no small group iff the point is on the curve. o Bad news: Not all the implementation checked whether the point is on the curve. • X25519 o Bad news: the order is not equal to p-1, it's about (p-1)/8 o Good news: the standard define how to check the public key, and it does not need to check whether the point is on the curve (feature for Montgomery curve). • WARNING: Don't blindly trust any new curve.
19. How to attack (EC)DHE (side channel) • DHE o Choose prime number p, a generator number g, a random private key x o How do we calculate public key y = (g^x) % p? o Sample code in python: o Problem ▪ Compare speed for x = 0x100001 and 0x1fffff ▪ The first one will be much faster o So a side channel attack can detect the count of '1'(popcnt) in the bits of private key • The P-256 curve in ECDHE has the same problem
20. How to attack (EC)DHE (part 2, side channel) • Why popcnt matters? o Consider you have a 128bit password, the attacker need to try about 2128 times to get the correct password o What if the attacker know that your password popcnt is 64? Only 2124 times needs, we lost 4 secure bits oWhat if the attacker know that your password popcnt is 30? Only 97 secure bits left o Any information of your secret can decrease the secure bits.
21. How to attack (EC)DHE (side channel) • X25519 / X448 o Montgomery Ladder o Constant time for public key calculation
22. How to attack (EC)DHE (PQC) • PQC Shor's algorithm: can resolve any period finding problem • For example, DHE (ECDHE has the same problem) o Given private key a, we have public key A = (g^a)%p; o With A, g, p, how to get a
23. How to attack (EC)DHE: Summary • Small subgroup attack o DHE: vulnerable o For FFDHE/P-256/..., no problem, need to check the point on the curve o For X25519/X448, no problem • Side channel attack o P-256/P-384/P-521: vulnerable o X25519/X448: no problem • Shor's algorithm o All: vulnerable • We need PQC KEX
24. PQC algos: status 2023 (not today) CRYSTALS- KYBER was chose and was renamed to ML-KEM with some normative changes. Daniel J. Bernstein - sued the U.S. government, challenging export restrictions on encryption - Inventor Chacha20 & Poly1305 - lead researcher on the Ed25519
25. Key Exchange: ML-KEM • Shor's algorithm can crack all the NP problem with periodicity (like Finite Group) • So we need to find some new NP problem which is not based on periodicity • So we have MLKEM(Module-Lattice-based Key-Encapsulation Mechanism) which break the period by a random error
26. Key Exchange: ML-KEM (Problems) • MLKEM: it's too large o key_share size for 128-bit secure bits ▪ X25519: 32B, P-256: 64B, MLKEM512: 800B o key_share size for 192-bit secure bits ▪ X448: 56B, P-384: 94B, MLKEM768: 1184B • Why too large is a problem o ClientHello will be larger than MSS (~1460B) o split into two TCP segments, some firewalls will have bugs on it • The Space Shuttle's width was determined by a horse's behind. o 1500MTU determines which algorithm could be used.
27. Key Exchange: ML-KEM (Problems) • What if we find that ML-KEM is vulnerable？ o Like MD5, which is deprecated after Wang Xiaoyun found the collision o Bernstein wrote a 55-pages pdf to IETF to explain why he wants to block pure ML-KEM to be RFC: https://cr.yp.to/2026/20260408-non-hybrid.pdf • How about use X25519 and MLKEM at the same time? o The shared secret is coming from the combination of X25519 & MLKEM kex results o If Quantum Computer is ready: MLKEM part is still strong enough o If MLKEM is vulnerable: X25519 part is still strong enough o It's called hybrid ▪ draft-ietf-tls-hybrid-design-16: Hybrid key exchange in TLS 1.3
28. Key Exchange: MLKEM & Hybrid • Quantum Computer is not ready, why Google and others already deployed X25519MLKEM768 o Correct, crack ECDHE needs about 20M physical Qubits(or 2400 logical Qubits) o In 2026, the best Quantum Computer has 6000 physical Qubits o But attacker can HNDL(Harvest now, Decrypt Later) ▪ Attacker can record all the valuable TLS traffic ▪ If quantum computer is ready, attacker can decrypt it.
29. How to attack Key Exchange • KEX o RSA: private key leak, non-PFS(perfect forward secrecy) o DHE: LOGJAM attack(pre-computing) o FFDHE/ECDHE: small subgroup / side channel / non-PQC ▪ X25519/X448: only non-PQC o MLKEM/Hybrid: PQC
30. Brute force attack? • No brute force attack in practice o But all the design is based on brute force attack analysis • Why do we think 112/128 secure bits is good enough o Landauer's Principle(1961) ▪ 1bit needs 2.9*10-21J under 25 °C ▪ For 112 bits password, 1013 J is needed, which is 4M kW h (in theory) ▪ For 128 bits password, 1018 J is needed, which is 274G kW h (in theory) ▪ In practical, maybe we need 1,000,000 times more than that o Open Question: ▪ How about attack under 0K (with liquid helium)?
31. Secure bits will change • SHA1 o 1995, SHA1 was invented, 80 secure bits for collision o 2005, Wang Xiaoyun, Finding Collisions in the Full SHA-1, 69 secure bits o 2017, Marc Stevens, The first collision for full SHA-1, 63 secure bits o 2020, Gaëtan Leurent, …, 61 secure bits • RSA o RSA2048: before GNFS(1990), it's ~1024 secure bits, after, 112 secure bits • AES o AES128: now 128 secure bits o After PQC: 64 secure bits (Grover's Algorithm) • So always add a buffer if you need a longterm secret(cert, …)
32. Security Level by OpenSSL (before PQC) Secure Bits KEX CERT Cipher HASH 0 0 Any Any Any 1 80 DH-1024 RSA1024 RC4 / 3DES SHA1* 2(most client) 112 DH-2048 RSA2048 SHA224 3 128 P-256/X25519 RSA3072/P- 256/ED25519 AES128 SHA256 4(CNSA 1.0*) 192 P-384/X448 RSA7680/P- 384/ED448 AES-192 SHA384 5(CNSA 2.0*) 256 P-521 RSA15360/P- 521 AES- 256/CHACHA SHA512
33. Security Level by OpenSSL (After PQC) Secure Bits KEX CERT Cipher HASH 2(most client) 112 DH-2048 RSA2048 SHA224 3 128 P-256/X25519 RSA3072/P- 256/ED25519 AES128 SHA256 4(CNSA 1.0*) 192 P-384/X448 RSA7680/P- 384/ED448 AES-192 SHA384 5(CNSA 2.0*) 256 P-521 RSA15360/P- 521 AES- 256/CHACHA SHA512 Red: secure bits change to 0 Yellow: secure bits change to half
34. PQC Security Level Type Algo Classical Secure Bits Quantum Secure Bits KEX MLKEM512 128 100-110 MLKEM768 192 160-170 MLKEM1024 256 230-240 Cert ML-DSA-44 128 ~100 ML-DSA-65 192 ~160 ML-DSA-87 256 ~230 Cipher AES-128 128 64 AES-256 258 128 • Why RFC(draft-ietf-tls-ecdhe-mlkem-04) does not choose MLKEM512? o The quantum secure bits is not large enough (< 112)
35. Summary • Downgrade o <= TLS 1.2: client tell server have tried higher version o TLS 1.3: server tell client that it support higher version • KEX o RSA: private key leak, non-PFS(perfect forward secrecy) o DHE: LOGJAM attack(pre-computing) o FFDHE/ECDHE: small subgroup / side channel / non-PQC ▪ X25519/X448: only non-PQC o MLKEM/Hybrid: PQC • Brute force o Secure bits / buffer when design / PQC choices
36. Thanks for your attention • Bombe: a machine that broke Enigma, which the Germans thought was unbreakable.