Re: [Cfrg] Curve manipulation, revisited

[Harry Halpin <[e-mail]>]

On 12/26/2014 10:50 PM, David Gil wrote:
> On Thursday, December 25, 2014 1:05 PM, Adam Langley <[e-mail]> 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 <[e-mail]> 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.

Quick point of clarification re W3C's position - we have an formal
position that *if* the decision is made by CFRG  made by March 12th [1],
we will return to Last Call Working Draft. After a month or so, if
implementers believe the proposal is mature, there are no objections,
and it is possible to achieve interop within a reasonable time-frame,
then we will add it to the algorithms listed in the spec for interop
testing and return to implementation interop.

If the decision is made *after* March 12th, we can amend the
recommendation using the "errata" process detailed here [2] (and likely
to be made easier in future) and return to interop testing.

>From WebCrypto's side, we can only recommend that browsers follow CFRG's
recommendation, but if we do not end up with two inter-operable
implementations of the CFRG recommendation by the time we exit Candidate
Recommendation, we will drop that curve from the Recommendation although
the "errata" path can be taken at any time, even after WebCrypto has
achieved Recommendation status. This lets "legacy" browsers upgrade when
they see fit.

In summary, we can add a curve at anytime, and only a curve that has
genuine interop will stay in the W3C spec. So while we have a preferred
deadline, CFRG is not bound to it and we can cope with CFRG's decision
whenever it is made.

We do not want to hurry CFRG's decision along, and believe the decision
should be made purely on technical merits, as makes sense for a Research
Group, and in public as is fitting given the amount of public attention
on crypto post-Snowden. In that regard, the earlier draft of technical
requirements (not sure what happened to it) was very useful and any
proposal should ideally be judged against such requirements.

The Working Groups like TLS or W3C Web Crypto can then deal with the
politics around implementation, but obviously we do understand having
major implementers on board with the CFRG decision helps. If there's
anything we can do to help, just ask.

   cheers,
      harry

[1] http://www.w3.org/TR/2014/CR-WebCryptoAPI-20141211/
[2] http://www.w3.org/2005/10/Process-20051014/tr.html#errata


> 
> 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"
> 
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
>