Re: [TLS] DH security issue in TLS

Andrey Jivsov <crypto@brainhub.org> Wed, 04 December 2019 01:52 UTC

Return-Path: <andrey@brainhub.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3352812000F for <tls@ietfa.amsl.com>; Tue, 3 Dec 2019 17:52:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.95
X-Spam-Level:
X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.073, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9yAVNjaSy9m for <tls@ietfa.amsl.com>; Tue, 3 Dec 2019 17:52:33 -0800 (PST)
Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E47312001A for <tls@ietf.org>; Tue, 3 Dec 2019 17:52:32 -0800 (PST)
Received: by mail-qk1-f171.google.com with SMTP id a10so5595258qko.9 for <tls@ietf.org>; Tue, 03 Dec 2019 17:52:32 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=2+q+Cp+frvvpk/AEfCwpt249/lx3XyvGcKoZSp7HGuc=; b=A/XcL0OFmi/j5U6iwZza9L/YrUEbKsXvrd1DOBHTsKcdeshRPPgm08yrgJ8YyNcDf0 ZG0iigLguHp1DjsVnETEn9QZSrAXwK8bGobcAp6N9mBOuApZk+Z/zcp3ZRI3xHFhnQXo dGlacozs99KTXEtJa9UtHv84c5HvRaHXstYs3fmpdqJxcc7mtyedsjWNQpJS/ckR/OdU 3b04XuzZ5+j11bS/fCj0SJ41ofC7kNQW4RfxQNhw62eQxbjEHioWUdKmcOBlsET4a3cV pax8Xi3dXVsuC1UnMqVKN6t+Gba3/Sf1P4n58rgpc/p1YJ5BUuwmUhBf40ge2FG5fx6M za/A==
X-Gm-Message-State: APjAAAVgUl/3FN9CQ4e3Jo96euG9UpV/Ee5goUhAzNQFdV7Gtg8bl84T 4dg2E2u6nxFBhNzUu1XOwJ7Ae7kBPXNwbNtfMJSFmQ==
X-Received: by 2002:a37:4d02:: with SMTP id a2mt451378qkb.355.1575424351762; Tue, 03 Dec 2019 17:52:31 -0800 (PST)
MIME-Version: 1.0
References: <CAEQGKXQAd=j_UyBEQPv7frmcDn_=DoBbvEccCkLPr4odSDcqQw@mail.gmail.com> <BN8PR11MB36661739568DB959F7C9D2C4C1420@BN8PR11MB3666.namprd11.prod.outlook.com>
In-Reply-To: <BN8PR11MB36661739568DB959F7C9D2C4C1420@BN8PR11MB3666.namprd11.prod.outlook.com>
From: Andrey Jivsov <crypto@brainhub.org>
Date: Tue, 3 Dec 2019 17:52:21 -0800
Message-ID: <CAKUk3btOGtDtsAoU+VZTE0YPpmF-Xi0H7_MHMFqYo8PuKFbMNA@mail.gmail.com>
Cc: Pascal Urien <pascal.urien@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000dce75c0598d71027"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/CCJoLpK4A6nLERgpvN5a2_Lf5dI>
Subject: Re: [TLS] DH security issue in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Dec 2019 01:52:35 -0000

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
>