Subject: Re: [Cfrg] Curve manipulation, revisited

From: David Gil <[email-masked]>
Date: Fri, 26 Dec 2014 21:50:57 +0000 (UTC)

On Thursday, December 25, 2014 1:05 PM, Adam Langley <[email-masked]> 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
implemented...)

On Thu, Dec 25, 2014 at 8:38 PM, David Gil <[email-masked]> 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]: http://lists.w3.org/Archives/Public/public-webcrypto/2014Sep/0011.html "[W3C Web Crypto WG] CfC : Call for Consensus on the integration of new curves in Web Crypto API - vote before the 16th of sept"

---

From: Adam Langley <[email-masked]>
Date: Sat, 27 Dec 2014 01:38:08 -0800

> Edwards curves over the Salinas primes, which are rather widely

Sharing the underlying field certainly helps reduce implementation
effort, but there's still lots more work than that, including all of
the duplication of test cases that inherently comes from each
additional curve.

(Not to mention that I consider the Salinas primes to be a bug-magnet
to such an extent that replacing the field in that case would probably
still be a net-positive for correctness.)

> implement in JS, for support of legacy-ish browsers.

I would currently expect Chrome to be in the "legacy" set if you want
WebCrypto support for a larger CFRG curve.

Cheers

AGL