Re: [Cfrg] Security proofs v DH backdoors

Hanno Böck <hanno@hboeck.de> Thu, 27 October 2016 10:51 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 458C9129499 for <cfrg@ietfa.amsl.com>; Thu, 27 Oct 2016 03:51:26 -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 pP2IbWiXqWVh for <cfrg@ietfa.amsl.com>; Thu, 27 Oct 2016 03:51:24 -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 2D664129D49 for <cfrg@irtf.org>; Thu, 27 Oct 2016 03:51:24 -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; Thu, 27 Oct 2016 12:51:22 +0200 id 00000000000000C8.000000005811DC2A.00006A45
Date: Thu, 27 Oct 2016 12:51:20 +0200
From: Hanno =?UTF-8?B?QsO2Y2s=?= <hanno@hboeck.de>
To: Dan Brown <danibrown@blackberry.com>
Message-ID: <20161027125120.4d260334@pc1>
In-Reply-To: <20161027103214.5709905.11728.6650@blackberry.com>
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>
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-27205-1477565483-0001-2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/rBonyo85w3H1AHqITLsM2CPC8ic>
Cc: CFRG <cfrg@irtf.org>, Peter Gutmann <pgut001@cs.auckland.ac.nz>
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: Thu, 27 Oct 2016 10:51:26 -0000

On Thu, 27 Oct 2016 10:32:17 +0000
Dan Brown <danibrown@blackberry.com> wrote:

> For q=(p-1)/2, literally computing c^q for client public key is very
> slow.
> 
> Why not use a faster alternative, such as checking Legendre symbol
> (c/p), use cofactor DH,‎ or use even private keys?

This line of debate and all the recently released papers show one very
concerning thing: We haven't learned how to use Diffie Hellman properly
- although it's an algorithm at the end of its life.

I think when I read the logjam paper I became aware of how tricky of an
issue this is and how many things can go wrong with DH. It was also the
time when I concluded that the best is probably to just move beyond DH.

Sure, there is probably a way to use DH in a way that reflects all
security concerns, is still reasonably performant etc. But why should
we have this discussion when we already know DH is on its way out?
Chrome already decided to disable it, others will follow.
Is there a good reason to keep DH around? One I'm aware of is that some
people think due to its larger size it's more resistant against
quantum computers. But I have heard multiple people familiar with QC
and pqcrypto that they don't buy that argument.

I'm not arguing that ECC is simpler, but I'm arguing that we have
solved a lot of these issues facing DH already in a better way for ECC:
By simply not using random parameters which whoever decides, but by
using one or two good curves that have all desired properties. We
probably could do the same for DH, but we don't have to if DH is
deprecated anyway.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42