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
• 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)
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
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
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?
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)
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)
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
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?
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)
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
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.
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
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.
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
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
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
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
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.
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
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.
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
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)?
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, …)
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
SiteGround - Reliable hosting with speed, security, and support you can count on.
lidaobing
syumai
tnagao7
yug1224
youkidearitai
nrslib
licux
pocke
naokihaba
vinceamstoutz
utgwkk
terryu16
musan
nonsquared
tammyeverts
scottboms
lara
ivargrimstad
wjessup
irinanazarova
badams
caitiem20
ammeep
brad_frost
marktimemedia
