Re: [TLS] DH security issue in TLS

https://tools.ietf.org/html/rfc7919#section-5.1 prohibits x=(p-1)/2 because
this results in a peer's public key g^x= 1.

Allowing this makes some man-in-the middle attacks on TLS easier, because
the attacker can predict the value of the ephemeral secret key on another
leg of the connection.

On Tue, Dec 3, 2019 at 3:03 PM Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com>
wrote:

> See SRF
>
>
>
> *From:* TLS <tls-bounces@ietf.org> *On Behalf Of * Pascal Urien
> *Sent:* Tuesday, December 03, 2019 5:16 PM
> *To:* tls@ietf.org
> *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
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>