Subject: [Cfrg] new curves vs. algorithms

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 Jan 2014 12:57:05 +0000

Hiya,

I've a question that I think might be worth looking
at when the "new curves" work has settled down a
bit more. (Since I'll forget about it:-) I'm gonna ask
now, but I hope this doesn't get debated until later.

Given that the implementations of the nist curves and
these new curves are radically different and perhaps
quite likely to be done by different folks, is there
a benefit in treating these as if they were entirely
different algorithms in terms of codepoints in
protocols, or are we better off just regarding them
as different curves for the same algorithm.

I'm not sure what answer I prefer, nor if it makes
that much difference, but we should ponder it before
we eventually get to allocating OIDs or other protocol
codepoints. A lot of that is protocol specific but
some is likely generic and might be considered by cfrg.
(When I say "considered" I mean I think it could be
useful if cfrg have given some thought as to how to
get these new curves used. That could be just mail
list traffic though, and need not be text in an RFC.)

I hope the criteria to be used when considering this
(if its significant) would be to go with whatever will
make implementation and deployment easier, since the
impact might be more on APIs and libraries rather than
on protocols, but doing the wrong thing might make it
harder to get broad support for the new stuff, e.g.
if some v. popular implementations had APIs that made
it hard to do both nist and "new" curves depending
on whether the new ones are viewed as a different
algorithm or alg-param.

Or maybe its a dumb question, in which case sorry
for wasting the bytes:-)

Cheers,
S.

---

From: Alyssa Rowan <[email-masked]>
Date: Fri, 17 Jan 2014 20:00:07 +0000

On 17/01/2014 12:57, Stephen Farrell wrote:

> […] is there a benefit in treating these as if they were entirely
> different algorithms in terms of codepoints in protocols, or are we
> better off just regarding them as different curves for the same
> algorithm.

I think that's _very_ protocol-specific, even feeding from what
implementers and existing libraries find most amenable to updates.

I think the only really important thing is that everyone's
crystal-clear about what is what, exactly. (Same as with naming, really?)

Example: For TLS, ECDHE with Montgomery curves (notably curve25519) is
pretty straightforward! draft-joseffsson-tls-curve25519-03
specifically proposes to use the existing ECDHE ciphersuites with
NamedCurve curve25519 (and probably so on for each of the suitable
"Chicago curves" supported); and an implicit opaque ECpoint.point
(currently being debated as to endianness and length).

That seems a sensible approach to me: less code rewrite, less messing
about with library internals, and hopefully the ability to incorporate
the existing great routines out there already to accelerate actual
deployment for something considered an urgent requirement (efficient
forward security).

But conversely, please _don't_ try to just use ECDSA with these
curves. I think that'd be a bit of a square peg in a round hole: you
might be able to make it fit if you really hammered it, but you risk
cutting corners if you did! <g>

There's a discussion in progress around a potential Schnorr-style
signature scheme suitable for use with Edwards (and/or Twisted
Edwards) curves instead and which wouldn't eat entropy when signing -
probably based heavily on djb/Lange's Ed25519 paper, but a bit more
generalised/updated/cleaned-up to fit the other curves we document?
(We're still in the early planning phase.)

I'd think an entirely different signature algorithm like that _would_
warrant a different algorithm ID - but of course that's a future
something for WGs at such a time there's got a solid proposal for it.

- -- 
/akr