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

Nigel Smart <> Sat, 28 June 2014 16:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4EB621A0380 for <>; Sat, 28 Jun 2014 09:58:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fQOeqNMD8n-i for <>; Sat, 28 Jun 2014 09:58:24 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0F2161A037A for <>; Sat, 28 Jun 2014 09:58:23 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Sat, 28 Jun 2014 16:58:24 UTC
Received: by with SMTP id k48so6450251wev.34 for <>; Sat, 28 Jun 2014 09:58:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:sender:message-id:date:from:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=5lGwdifcUQa/bxrbCmnPX9Id9IIzBuoYav4OXMz7PrI=; b=AiT6SPjSNAa5ZyzeyLbPeR/2PnkwaEUHOfY9PueSlOXE+lasFNmGmHtV/wgnK6vLBu cPYrMQDQWd1w+v2lIc/U+zbySdJSG1eUgH1HPRbo51ESOQqSKkAxxy3Zt63kFeXpr+vx IRlYfO8AWRpYGMHEihgzdCEVI2MMNLNQc1bhHlR8qVSq0iggD249hgrdcmkHOeL1EHbp bomAoEx+rTl4urK+X6K8tcppmqLW7V/x/OzwwRhDgE+QNklGkpFO0X42MTZaTRp2X+/E P94iABRrctGKtnhoMOHGn/zo4LFWzSZeLHlVvowJiBjrM+ZVZxVyYCvlNSMerpdDotLv 2zTA==
X-Gm-Message-State: ALoCoQl2BT7nJfsPomA3dn8Gi/Yf1bccVbUwj7bQkIRaJ90yApLiRbHzzW3PPYdGUGnsVhEWJL4z29EM1X3Njr3wVGHTL9Uyw44xQ26GwThElsnRBUG35vihfRo7UJ8sznQVhcvytqwB
X-Received: by with SMTP id j6mr18506250wiy.71.1403974699417; Sat, 28 Jun 2014 09:58:19 -0700 (PDT)
X-Received: by with SMTP id j6mr18506247wiy.71.1403974699336; Sat, 28 Jun 2014 09:58:19 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id p3sm29026995wjw.13.2014. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Jun 2014 09:58:18 -0700 (PDT)
Sender: Nigel Smart <>
Message-ID: <>
Date: Sat, 28 Jun 2014 17:58:16 +0100
From: Nigel Smart <>
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Sat, 28 Jun 2014 16:58:27 -0000


> One way to attempt to unify the diverse world of ECC curves is to focus
> on the underlying field, as opposed the curve itself. Consider Fp
> operations with p=2^255-19 or p=2^256-189. In other words, for
> n={256,384,512}, chose the closest C: p=2^n-C is a prime and make this p
> "MUST". People who demand random primes will have to play along and
> accept less "randomness" in their curves.

Alas there could be some issues with primes close to powers of two.
See our recent side channel attacks on EC-DSA with the Eurovision
titles on ePrint "Just a Little Bit" etc. Such a p forces the
group order to also be close to a power of two (by Hasse's Theorem).

Whilst these papers show there are problems with the NIST choices
in this respect, the above choices of p would be even worse.

So unifying in this respect would be a bad idea IMHO.

Prof. Nigel P. Smart         | Tel +44 (0)117 9545163
Computer Science Department, | Fax +44 (0)117 9545208
Woodland Road,               | Email
Bristol, BS8 1UB, UK         |