[Bug 25618] Extensibility: Offer spec-blessed ways to extend the algorithms and curves, rather than monkey-patching the spec

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25618

--- Comment #5 from Trevor Perrin <webcrypto@trevp.net> ---
(In reply to Ryan Sleevi from comment #4)
> (In reply to Mark Watson from comment #2)
> > 
> > Would it make sense to model different families of Elliptic Curves as
> > separate algorithms ? So, the existing algorithms become ECDSA-NIST etc. and
> > we can add ECDSA-NUMS in a separate specification ?
> 
> For NUMS, no, it certainly doesn't make sense. The point of NUMS is to be
> compatible with the NIST (which is really the specification of the SECG, and
> plenty of other related bits). Brainpool also fits into this.

The NUMS Edwards curves are more similar to 25519 than to the NIST curves, IMO.

> There's no technical reason that prevents Curve25519 from not fitting into
> this pattern either, other than the proponents of Curve25519 not wanting to
> go through the effort.

25519 is intentionally presented in the form of rigidly-specified ECDH and
signature algorithms.  It's not just "not wanting to go through the effort" of
providing a more naked curve, which would of course be less effort.

In particular, the Curve25519 ECDH paper specifies the sort of details you've
left to ANSI X9.63, and the Ed25519 paper specifies the sort of details you've
left to ANSI X9.62.

Since some of these details are curve-dependent, it's reasonable to provide
them in monolithic ECDH and signature packages, i.e. Curve25519 and Ed25519.

For example, the ANSI X9.63 Section 5.4.1 ECDH primitive you specify I believe
requires encoding the full point (not just x-coordinate), and for non-cofactor
1 curves (like some of the NUMS curves) requires an extra scalar multiplication
for point validation, and doesn't account for the cofactor in the ECDH.  That's
probably NOT what you want for all the NUMS curves.

And your ANSI X9.62 ECDSA primitive with random nonce is considered by many
cryptographers to be inferior to Schnorr signatures with deterministic nonce
like Ed25519, which is more robust against hash collisions and RNG failures,
more efficient and flexible to things like threshold signatures, and has a
better security proof.

We could argue more about these "modular" vs "monolithic" design decisions, but
there are good reasons to rigorously specify algorithm details to match a
particular curve.  You haven't done this, but that doesn't mean everything
"just works" - it means you have work ahead of you to match your algorithm
specification with your curves.

Trevor

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Monday, 28 July 2014 20:01:25 UTC