Re: [TLS] DH security issue in TLS

["Scott Fluhrer (sfluhrer)" <[e-mail]>]

See SRF

From: TLS <[e-mail]> On Behalf Of Pascal Urien
Sent: Tuesday, December 03, 2019 5:16 PM
To: [e-mail]
Subject: [TLS] DH security issue in TLS

I wonder if g**x , with x =(1-p)/2 is checked in current TLS 1.2 implementation ?

In RFC https://tools.ietf.org/html/rfc7919
"Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)"

"Traditional finite field Diffie-Hellman has each peer choose their secret exponent from the range [2, p-2].
Using exponentiation by squaring, this means each peer must do roughly 2*log_2(p) multiplications,
twice (once for the generator and once for the peer's public key)."

Not True !!!
Even for p= safe prime (i.e.. Sophie Germain prime, p=2*q+1, with p & q prime number) secret exponent x= (p-1)/2 is a security issue since :

g**xy = 1       with y an even integer
g**xy = g**x   for y an odd integer

SRF: actually, g**xy  = 1 in both cases, as g**x = 1 (for the g, p values specified in RFC7919); this is easily seen as all listed p values are safe primes, and in all cases, g=2 and p=7 mod 8.

In any case, why would that be a security issue?  If both sides are honest (and select their x, y values honestly), the probability of one of them selecting (p-1)/2 as their private value is negligible (even if our selection logic allowed that as a possible value – it generally doesn’t).  If we have two honest parties with an adversary replacing one of the side’s key share with g**(p-1)/2, well, the protocol transmits signatures of the transcript, and so that’ll be detected. If you have an honest side negotiating with a dishonest one, well, the dishonest one could select (p-1)/2 as its private value – however, they could also run the protocol honestly (and learn the shared secret and the symmetric keys, which are usually the target), and there’s nothing the protocol can do about that.

Now, if an honest party reused their private values for multiple exchanges, a similar observation would allow an adversary to obtain a single bit of the private value.  He would do that by performing an exchange with the honest party mostly honestly, selecting a value x as his private value, but instead of transmitting g**x as his key share, he would transmit -g**x.  Then, the shared value that the honest party would derive is:

  g**xy  with y an even integer
  -g**xy  with y an odd integer

The adversary can compute both these values, and determine which is being used later in the protocol.

So, the adversary can learn a single bit of the private value (which doesn’t translate to him learning any bit of the shared secret, much less the symmetric keys) – however, he cannot leverage this to learn anything else of the private key.  I do not believe that a single bit is worth worrying about.  And, again, if we generate a fresh DH private value for every exchange (which we encourage people to do for PFS), even that single bit doesn’t apply to any other exchange.



If p is not a safe prime (like in RFC 5114) other issues occur....


Pascal