IETF Logo Mail Archive

Re: [TLS] Why Edwards? (was Re: TLS process thread)

Nico Williams <nico@cryptonector.com> Tue, 15 April 2014 04:27 UTC

Return-Path: <nico@cryptonector.com>
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 43B9E1A02F0 for <tls@ietfa.amsl.com>; Mon, 14 Apr 2014 21:27:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level:
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] 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 0-lkAjyuktbs for <tls@ietfa.amsl.com>; Mon, 14 Apr 2014 21:27:15 -0700 (PDT)
Received: from homiemail-a67.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 68A901A024D for <tls@ietf.org>; Mon, 14 Apr 2014 21:27:15 -0700 (PDT)
Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id D1C9827BC064 for <tls@ietf.org>; Mon, 14 Apr 2014 21:27:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=CHFNcCU7BYAlT66k1a94 GlLrATc=; b=b1ug4sp3BkN/rhmzCwY92mcFsc7zUWWdsEmVvWvIfX5tpdYupG7o D/e4U7KpgaiUHvgPqfSbkRVgpYJONQ/76bAmivIZyLr/BxvnOc6phn/tRqHdfl9C v1I2m9ZU+bD4vblOOPVt5wZb4jIu0C5hRSB1AtAH0bhgkQrIO0WlW5A=
Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPSA id 85A8D27BC069 for <tls@ietf.org>; Mon, 14 Apr 2014 21:27:12 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id l18so8897143wgh.31 for <tls@ietf.org>; Mon, 14 Apr 2014 21:27:11 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.160.166 with SMTP id xl6mr569258wib.42.1397536031210; Mon, 14 Apr 2014 21:27:11 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Mon, 14 Apr 2014 21:27:11 -0700 (PDT)
In-Reply-To: <CACsn0cn1EBhtvtq4X3J0h1TUq5nGvRyP818oY4rhqfqJA4aELg@mail.gmail.com>
References: <CACsn0cn1EBhtvtq4X3J0h1TUq5nGvRyP818oY4rhqfqJA4aELg@mail.gmail.com>
Date: Mon, 14 Apr 2014 23:27:11 -0500
Message-ID: <CAK3OfOhCn1h7+wO8PCLK0_+ZRnJ_OxNSCinz_f_Enn3DqUjHDg@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/u9NewpxI2u3mKrn9e8M-KM27aHI
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Why Edwards? (was Re: TLS process thread)
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: Tue, 15 Apr 2014 04:27:19 -0000

FWIW, I believe the matter is very clear now: Weierstrass curves out,
Edwards curves in.  For all the reasons Watson gave, and, really, for
all the reasons that DJB has given.

DJB is so convincing on this subject that the burden of proof is on
anyone opposing the switch to Edwards curves.

That we have NIST curves code lying around is not a sufficient
argument: it will either not be constant time or its performance will
not be anywhere near as good as implementations of comparable Edwards
curves.  The first consideration (no side channels) is unarguably a
hard requirement; the second (good performance) is close enough to a
hard requirement that it might as well be.

Nico
--

v2.23.0 | Report a Bug | By Email