Re: [Cfrg] Security proofs v DH backdoors

Ilari Liusvaara <> Fri, 28 October 2016 14:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2DDEF129AE1 for <>; Fri, 28 Oct 2016 07:08:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GH-BzrGEfNrC for <>; Fri, 28 Oct 2016 07:08:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 151431294B8 for <>; Fri, 28 Oct 2016 07:08:30 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F6D612B56; Fri, 28 Oct 2016 17:08:29 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id BOGn2oSHkLmn; Fri, 28 Oct 2016 17:08:29 +0300 (EEST)
Received: from LK-Perkele-V2 ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 337E02313; Fri, 28 Oct 2016 17:08:29 +0300 (EEST)
Date: Fri, 28 Oct 2016 17:08:27 +0300
From: Ilari Liusvaara <>
To: Peter Gutmann <>
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Cc: CFRG <>
Subject: Re: [Cfrg] Security proofs v DH backdoors
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 28 Oct 2016 14:08:33 -0000

On Wed, Oct 26, 2016 at 04:32:49AM +0000, Peter Gutmann wrote:
> Ilari Liusvaara <> writes:
> >I think there was one TLS implementation that tries to verify the groups sent
> >(of course, not all can be verified, even if those aren't maliscously
> >constructed).
> (Hey, I've got to get the maximum mileage out of this one :-).  LTS has
> already foiled attacks that postdate its publication, so you know it's a good
> thing).

Unfortunately, LTS is a non-starter as web browsers are concerned. And
it is pretty much non-starter as far as everything else is concerned.

It also does not fix the reasons why web browers are first moving DHE
behind fallback and now deimplementing it entierely (because you can't
realistically reject any DHE parameters, but if you dont reject insecure
ones, you get serious security problems. Catch 22.).

Heck, the web browser vendors don't seem to be interested in DHE in TLS
1.3, even after -15 fixed the "DHE downnegotiation" problem (TLS 1.3
draft 15 and forward are not affected by the major trouble DHE causes
in prior TLS versions).

And the "backup" of DHE is unfortunately RSA key exchange, which is
well-known to be very broken (serious security problems).

So the only asymmetric key exchange that actually works is ECDHE
(P-256 or X25519).