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

Johannes Merkle <> Mon, 07 July 2014 16:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D156D1A033C for <>; Mon, 7 Jul 2014 09:00:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.251
X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uZ1R5jLns9T6 for <>; Mon, 7 Jul 2014 09:00:20 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E63A81A0305 for <>; Mon, 7 Jul 2014 09:00:18 -0700 (PDT)
Received: from localhost (alg1 []) by (Postfix) with ESMTP id 3B7AE1A0096; Mon, 7 Jul 2014 18:00:16 +0200 (CEST)
X-Virus-Scanned: by secunet
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id Tn8f57H3tJ1q; Mon, 7 Jul 2014 18:00:07 +0200 (CEST)
Received: from mail-gw-int (unknown []) by (Postfix) with ESMTP id 7A3E31A0097; Mon, 7 Jul 2014 18:00:04 +0200 (CEST)
Received: from [] (port=36950 by mail-gw-int with esmtp (Exim 4.80 #2 (Debian)) id 1X4BKn-0007a7-NJ; Mon, 07 Jul 2014 18:00:05 +0200
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id; Mon, 7 Jul 2014 18:00:05 +0200
Message-ID: <>
Date: Mon, 7 Jul 2014 18:00:05 +0200
From: Johannes Merkle <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Alyssa Rowan <>, <>
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 Jul 2014 16:00:23 -0000

Alyssa Rowan wrote on 07.07.2014 15:14:
> Well, yes - combined with an unusual ladder choice (which one might choose for constant-time, albeit not the best
> choice now) and a critical but easily-overlooked omission.
> I appreciate there's not much we can do about implementers screwing up badly - but if we do have two primitives of
> about equal value and one fails catastrophically to a simple mistake that another does not, then as a matter of
> defence in depth, I'd generally prefer the more resilient one?
> So it is with Brainpool: its twist security is poof (by pure chance) so such a mistake would be more hazardous than
> is typical. How likely that mistake would be is another matter, and I accept your point there that it'd be a rare
> decision and hopefully would be noticed in any review.
> I still don't think Brainpool's fast enough to drive adoption, next to competition like 25519 and the Microsoft
> curves.

In this discussion, it is important to focus on the most essential arguments. "Twist security" is not among them, as
it only applies to very special cases and poor implementations. Montgomery and Edwards curves have other potential
problems due the non-trivial co-factor, so there is always something a sloppy implementor can screw up.

Computational performance is a valid argument, and where performance is your main criteria, your may go for special
primes and non-Weierstrass curves; but there are sufficient circumstances, where performance is not the principal
criteria. IMHO, it is wise to maintain curves with different properties to accommodate different demands.