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