Re: [Cfrg] Security proofs v DH backdoors
Hanno Böck <hanno@hboeck.de> Fri, 28 October 2016 09:48 UTC
Return-Path: <hanno@hboeck.de>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BC6129A09 for <cfrg@ietfa.amsl.com>; Fri, 28 Oct 2016 02:48:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 u8tKJvcDsUBN for <cfrg@ietfa.amsl.com>; Fri, 28 Oct 2016 02:48:04 -0700 (PDT)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053F5129A04 for <cfrg@irtf.org>; Fri, 28 Oct 2016 02:48:03 -0700 (PDT)
Received: from pc1 ([2001:2012:115:3d00:8e6b:8908:764f:9343]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Fri, 28 Oct 2016 11:48:00 +0200 id 0000000000000046.0000000058131ED0.00004667
Date: Fri, 28 Oct 2016 11:47:58 +0200
From: Hanno Böck <hanno@hboeck.de>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Message-ID: <20161028114758.6a361db1@pc1>
In-Reply-To: <1477647359860.49982@cs.auckland.ac.nz>
References: <20161025131014.5709905.2866.6563@blackberry.com> <20161025133016.GA9081@LK-Perkele-V2.elisa-laajakaista.fi> <1477456366629.49872@cs.auckland.ac.nz> <44595.1477524032@eng-mail01.juniper.net> <20161027103214.5709905.11728.6650@blackberry.com> <20161027125120.4d260334@pc1> <1477647359860.49982@cs.auckland.ac.nz>
X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-18023-1477648080-0001-2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/YrlWA6lRa-yWRgki2OwBnxJdjng>
Cc: CFRG <cfrg@irtf.org>
Subject: Re: [Cfrg] Security proofs v DH backdoors
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Oct 2016 09:48:06 -0000
On Fri, 28 Oct 2016 09:36:07 +0000 Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote: > Secondly, DH's replacement, the ECC algorithms, are an absolute > non-starter in any kind of harsh environment. They're the most > brittle crypto you can possibly deploy, any fault of any kind > inevitably ends up leaking the private key. I know several > industries who, despite its great trendiness, won't touch the ECC > stuff because it's just too brittle to safely use. Can you elaborate what brittleness you mean? Because based on what I know I come to a different conclusion. I think modern ECC is less brittle than DH. Reading the past 4 papers on DH (+ maybe logjam and 3shake) should be enough to tell everyone that DH has a lot of brittleness in it. Brittleness of ECC: I'm aware of invalid curve attacks, which can be completely mitigated by using a twist-secure curve and point compression as far as I'm aware. Then there's the issue of ECDSA bad randomness (which affects classic DSA in the same way), but it's irrelevant for key exchanges. > Finally, specifically for the Bernstein protocol suite [0] if that's > what you're thinking of for supplanting DH, it's easy enough for > someone like Google to decree that from now on we all have to use X, > but many industries are heavily constrained and regulated and can't > just adopt whatever new algorithm comes along. So your general idea here is that there are situations where people are constrained not to use ECC with another curve, but they *can* use DH with another parameter set? I mean I can imagine that this happens (there's probably some certification out there mandating specific curves and allowing arbitrary DH parameters), but only in situations free of any cryptographic knowledge. But if there's a need for DH parameter sets: RFC 7919 has just been published recently and was already mentioned in this thread. Would it satisfy the needs of people if there simply was some kind of document (could be an RFC, but maybe also just an errata) saying that the DH parameters from 7919 may be used outside TLS? (not sure if this has to be explicitly stated, but if it helps people, why not?) -- Hanno Böck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
- [Cfrg] Security proofs v DH backdoors Dan Brown
- Re: [Cfrg] Security proofs v DH backdoors Ilari Liusvaara
- Re: [Cfrg] Security proofs v DH backdoors Hanno Böck
- Re: [Cfrg] Security proofs v DH backdoors Peter Gutmann
- Re: [Cfrg] Security proofs v DH backdoors Mark D. Baushke
- Re: [Cfrg] Security proofs v DH backdoors Dan Brown
- Re: [Cfrg] Security proofs v DH backdoors Hanno Böck
- Re: [Cfrg] Security proofs v DH backdoors Daniel Bleichenbacher
- Re: [Cfrg] Security proofs v DH backdoors John Mattsson
- Re: [Cfrg] Security proofs v DH backdoors Dan Brown
- Re: [Cfrg] Security proofs v DH backdoors Peter Gutmann
- Re: [Cfrg] Security proofs v DH backdoors Hanno Böck
- Re: [Cfrg] Security proofs v DH backdoors Michael Scott
- Re: [Cfrg] Security proofs v DH backdoors Peter Gutmann
- Re: [Cfrg] Security proofs v DH backdoors Hanno Böck
- Re: [Cfrg] Security proofs v DH backdoors Ilari Liusvaara
- Re: [Cfrg] Security proofs v DH backdoors Peter Gutmann
- Re: [Cfrg] Security proofs v DH backdoors Peter Gutmann
- Re: [Cfrg] Security proofs v DH backdoors Peter Gutmann
- Re: [Cfrg] Security proofs v DH backdoors Ilari Liusvaara
- Re: [Cfrg] Security proofs v DH backdoors Ilari Liusvaara
- Re: [Cfrg] Security proofs v DH backdoors Salz, Rich
- Re: [Cfrg] Security proofs v DH backdoors Michael Scott
- Re: [Cfrg] Security proofs v DH backdoors Tony Arcieri
- Re: [Cfrg] Security proofs v DH backdoors Hanno Böck
- Re: [Cfrg] Security proofs v DH backdoors Tony Arcieri
- Re: [Cfrg] Security proofs v DH backdoors David Adrian
- Re: [Cfrg] Security proofs v DH backdoors Watson Ladd
- Re: [Cfrg] Security proofs v DH backdoors Peter Gutmann
- Re: [Cfrg] Security proofs v DH backdoors Antonio Sanso
- Re: [Cfrg] Security proofs v DH backdoors Peter Gutmann
- Re: [Cfrg] Security proofs v DH backdoors Peter Gutmann
- Re: [Cfrg] Security proofs v DH backdoors Peter Gutmann
- Re: [Cfrg] Security proofs v DH backdoors Peter Gutmann
- Re: [Cfrg] Security proofs v DH backdoors Hanno Böck
- Re: [Cfrg] Security proofs v DH backdoors Tony Arcieri
- Re: [Cfrg] Security proofs v DH backdoors Peter Gutmann
- Re: [Cfrg] Security proofs v DH backdoors Tony Arcieri
- Re: [Cfrg] Security proofs v DH backdoors Peter Gutmann
- Re: [Cfrg] Security proofs v DH backdoors Watson Ladd
- Re: [Cfrg] Security proofs v DH backdoors Peter Gutmann
- Re: [Cfrg] Security proofs v DH backdoors Paterson, Kenny
- Re: [Cfrg] Security proofs v DH backdoors Paterson, Kenny