Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,

Hanno Böck <hanno@hboeck.de> Thu, 26 June 2014 22:13 UTC

Return-Path: <hanno@hboeck.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835661B2EDD for <tls@ietfa.amsl.com>; Thu, 26 Jun 2014 15:13:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.898
X-Spam-Level: *
X-Spam-Status: No, score=1.898 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 Xb4NZFer_2Fy for <tls@ietfa.amsl.com>; Thu, 26 Jun 2014 15:13:07 -0700 (PDT)
Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95FCD1A050E for <tls@ietf.org>; Thu, 26 Jun 2014 15:13:07 -0700 (PDT)
Received: from localhost (91-64-49-24-dynip.superkabel.de [::ffff:91.64.49.24]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, AES128-SHA) by zucker.schokokeks.org with ESMTPSA; Fri, 27 Jun 2014 00:13:05 +0200 id 000000000000002E.0000000053AC9AF1.00003F38
Date: Fri, 27 Jun 2014 00:12:15 +0200
From: Hanno =?UTF-8?B?QsO2Y2s=?= <hanno@hboeck.de>
To: tls@ietf.org
Message-ID: <20140627001215.75dffc43@hboeck.de>
In-Reply-To: <53AC97B8.2080909@nthpermutation.com>
References: <53AC97B8.2080909@nthpermutation.com>
X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-16184-1403820785-0001-2"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Zh35IPm0sqAoC1srl4kTUtDEAMk
Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 26 Jun 2014 22:13:10 -0000

On Thu, 26 Jun 2014 17:59:20 -0400
Michael StJohns <msj@nthpermutation.com> wrote:

> AFACT, one of the main reasons for looking at Curve25519 (possibly
> more important than performance or security) is that there is a fear
> that the US Government has placed trapdoors in the current set of
> curves (NIST P256, P384, P521 etc).   The argument against the
> "provably random" creation claim with respect to those curves appears
> to be that many "seed" values could have been generated to generate
> curve parameters and those curves tested to find "weak" curves of a
> particular flavor and the seeds for weak curves retained.  In other
> words, we don't know how the seed values were generated and it could
> be nefarious.  I haven't as yet found any argument against the
> generation process, nor specifically against the elliptic curve math.

I think another major argument against NIST curves was that it's hard
to implement them in constant time. DJB had this and other issues
explained in a blog post [1].

As we saw a lot of timing attacks lately (Lucky Thirteen, Comeback of
Bleichenbacher attack in Java and OpenSSL) and I'd expect we'll see
more of that I think timing safety should be a crucial feature of all
future TLS algorithms.


[1] http://blog.cr.yp.to/20140323-ecdsa.html

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

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