Re: [Cfrg] Curve manipulation, revisited

David Gil <> Fri, 26 December 2014 21:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 008911AC3C0 for <>; Fri, 26 Dec 2014 13:51:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.001
X-Spam-Status: No, score=-15.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_DEF_WHITELIST=-15] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Drxz6Eh3SNpi for <>; Fri, 26 Dec 2014 13:51:06 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 630751AC399 for <>; Fri, 26 Dec 2014 13:51:06 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4/y.out) with ESMTP id sBQLowH1065507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <>; Fri, 26 Dec 2014 13:50:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=cobra; t=1419630659; bh=8Uhjzov5AZAJCw0DQ1sm09ZcSR6HclAUH9MJa164naE=; h=Date:From:Reply-To:To:Cc:Subject; b=wOxRagYL3sod4YLI7CgcYLYKk3I0OMDqLjMqRYN72DZeBYLMcT9osyJW0C1/KpFnZ /B2fYXeECio5Yvymwi5vIhbbtJm2yewTCdBGKwiCsG5SfsQz2MVof8BCqAha+WewHF atpYHlIfD7k56s0qOhej7VPTlfrwAgBP5FIA+k+w=
Received: (qmail 41316 invoked by uid 1000); 26 Dec 2014 21:50:58 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ginc1024; t=1419630658; bh=YvJsHIkH0iqc2Uvk3d3Z/oI+2Z2Tms81yPBxUGCyK+4=; h=Date:From:Reply-To:To:Cc:Message-ID:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; b=aCi09VTTwcfnSsTtT7QJ1nX+FgmotsUZUIL7YECA5QHg1KEElIDVC9DAL+vtUmW1TQdfY+KQFyFJcmSRSZ/j0kGKVuW/QMOr+MqTUyO3raV3eiWYrZfgr3bgMOYqB7SLjFGHS24B53gkcw3mg5CWXkDozOPRjy6MNEitmntYvbI=
X-YMail-OSG: ENX9ZUIVM1mXcPANwSN3C7XUrgbMpjTuLr9nipyqbZ3PM23GT1qI3jjy7VBsGeR uR6M8oTkLUavRv1GniqYopOW_4GNvDLDgxLJ8GXlsPyR5bNdoM3NKWMCe7gHwieu7JtEDDMbWxCT CGXQqDHxffIQEXt6ObFO3b3yEAEmoIeulEzJp9Myd3bFTctin_OByPn_OZn_xg4Xu2qdZRMplLBl ZWcv4289PUZJws4J9NX7rdaX9B3Xb6CYbYpKc_Q--
Received: by; Fri, 26 Dec 2014 21:50:58 +0000
Date: Fri, 26 Dec 2014 21:50:57 +0000
From: David Gil <>
To: Adam Langley <>
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [Cfrg] Curve manipulation, revisited
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: David Gil <>
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Dec 2014 21:51:08 -0000

On Thursday, December 25, 2014 1:05 PM, Adam Langley <> wrote:
[replying to someone else]
> . . .               On the other hand, each additional curve dilutes
> implementation resources and implementation bugs happen.

I assume that you mean finite fields, not curves?

(This would seem to be just as good of an argument for generating
Edwards curves over the Salinas primes, which are rather widely

On Thu, Dec 25, 2014 at 8:38 PM, David Gil <> wrote:
>> In particular, w.r.t. Yahoo's eventual release of an End-to-End
>> messaging extension, we will generate EC keys for extension users
>> on a curve subgroup with log2(#K) >= 376. The additional computational
>> expense is, frankly, negligible.
> I think my argument here is the same as above. (Although, in this
> situation, you would have the advantage of being able to use the
> simplest, clearest code possible . . . 

Alas, no, I don't have that advantage: WebCrypto [has more-or-less
decided][w3c_curves] that they will only implement CFRG-recommended
curves. I need WebCrypto support -- for non-extractable keys.
But I also need to have something that is relatively clean to
implement in JS, for support of legacy-ish browsers.

And I'm not convinced that the NUMS curve proposal can be implemented with decent performance in simple and clear JS.

> . . . because performance isn't a concern.)

And alas, it is: JavaScript is not particularly ideal for k-time
bignum arithmetic. The choice of finite field has a major impact
on performance.


> TOP SECRET just needed to have a bigger number than SECRET :)

Sure; but why then not secp224r1/SHA-224 and secp256r1/SHA-256?

And does a code-breaking agency have any reason to publicly
*overestimate* the probability a cryptosystem might be broken?

(Or: perhaps they chose randomly ;)


[w3c_curves]: "[W3C Web Crypto WG] CfC : Call for Consensus on the integration of new curves in Web Crypto API - vote before the 16th of sept"