Oops, thank you for pointing out my misstatement. While there is a vulnerability with Spake2+, I misremembered the details (I must be getting old...)
The actual vulnerability is "if they know the relation between M and P, then there's an active attack and allows the attacker to test multiple keys as the result of a single exchange". Here's how it works: the attacker controls the client and tries to log into a server (who knows the keys) (and in the TLS context, the client is the Spake2+ prover and the server is the Spake2+ verifier, and I'll be using the terminology from the Spake2+ RFC) The attacker controlled client picks an arbitrary value r and sends the server X = r*P The server then selects a random value y and sends back Y = y*P + w0*N The server then computes: Z = h*y*(X - w0*M) V = h*y*L = h*y*w1*P The server then computes the corresponding transcript TT and the corresponding confirmV, which he sends. Our attacker then breaks the connection and then, for each guess in his dictionary, computes the corresponding w0', w1'. and computes: Z' = h*(r - w0'*m) * (Y - w0' * N) V' = h*w1' * (Y - w0' * N) (where m is the known discrete log of M). If his guess of the password is correct, then Z=Z' and V=V', and so the transcripts TT will match, and hence the so the computed confirmV will match what the server sent. This means the attacker is able to scan through his entire dictionary, with doing only one active exchange. This works because, if w0=w0' and w1=w1', we have: Z' = h*(r - w0*m) * (Y - w0 * N) = h * (r - w0*m) * y * P = h * y * (X - w0*M) = Z V' = h*w1 * (Y - w0 * N) = h * w1 * y * P = h * y * w1 * P = V TT (and confirmV) is a function of Z, V and known data, so those can be computed. Hence, while what I originally stated was incorrect, my point remains; by solving a single discrete log problem, the security guarantees of the Spake2+ (which is that a single active attack would be able to test a single password) becomes incorrect. And, I cannot recommend endorsing a PAKE where solving a single discrete log problem breaks the system globally, given there are other PAKE protocols that do not have this vulnerability. ________________________________ From: Michael Rosenberg <mrosenberg=40cloudflare....@dmarc.ietf.org> Sent: Thursday, May 29, 2025 12:03 PM To: Scott Fluhrer (sfluhrer) <sfluh...@cisco.com> Subject: Re: [TLS] Comment on draft-bmw-tls-pake13 Could you describe in more detail how finding relation between M and N leads to an attack? This paper<https://eprint.iacr.org/2019/1194> says that even in the most trivial relation, ie M = N, we have security under the gap squared DH assumption. -Michael On Mar 14, 2025, at 4:53 AM, Scott Fluhrer (sfluhrer) <sfluhrer=40cisco....@dmarc.ietf.org> wrote: I went through the PAKE draft on TLS 1.3, and while I certainly appreciate the use of a PAKE within TLS, I would like to highlight one potential security issue that the working group needs to be aware of. The draft has SPAKE2+ as its sole defined parameter set; SPAKE2+ has a rather interesting property that if the attacker can perform a single discrete log problem, in particular, compute the discrete log of N to the base of M, that is, find k such that kM = N, then the PAKE properties go away. That is, an active attacker can perform a single exchange, and then efficiently run through his dictionary of potential passwords and (as long as the correct password is in the dictionary) recover the password. Let me repeat this: if someone can solve a single discrete log problem (for example, if he has a slow Cryptographically Relevant Quantum Computer), then the attacker can immediately attack any SPAKE2+ implementation using that parameter set, anywhere in the world. If the working group endorses SPAKE2+, then they need to be aware of this, and should highlight it in the security considerations. _______________________________________________ TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
