[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfrg
Subject:    Re: [Cfrg] new curves vs. algorithms
From:       Alyssa Rowan <akr () akr ! io>
Date:       2014-01-17 20:00:07
Message-ID: 52D98BC7.8030207 () akr ! io
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJS2YvGAAoJEOyEjtkWi2t6440P/3MufKOeJwwSzxCZf+AE9xAl
/b0yndszhECQYIoQsoWPD6qZWL63UIsJy2vwUb3DvLlA/fLKuclnNclinrR0ZxOW
IsuoMHlUQ1utZr3MD14vujB/L2nyS5sGb1wJwq8k2ORZHCLnUIOSVP6AtIlBNLBq
oJK9fiNdAnDsDbeZ79MjmvmXUQ243tZHZU7XCs1ZQba6txIp0RBGuaNGrKMfIs7f
x/12kap8YoCovhSy2FMzOXNFM3f+CBeDipvYZj0Le0+EoV9wCTcQVPFxAZimdDGq
eSy9fFzvYMVpLOjWBee6EMJ89U4gOvbJukORALp7Wqej2nkJjA6uCMzfIDOV8o9R
rTlzM8Xt3rLBnghL8jjIcIm5hOnUA8MBPHouakFXi5NqTV5IkX/M26B0cW6i09NI
aCX+kycLCLiGpoY9Lp3w9yXm06ibmhMmjjMqZDsG/hJE+5XsMfLD3opUaYlruVGI
S6zC8BIYQqEW3BQeIGYVXS3SJpwL1ahee5f0u4UxlkFyNeLHTW2MoMZiFGL3u/5M
+rwqbCArC/6s0iVVfJw1Epx4G86Cd42HFxGn2hJxgMclpunaRx0i2DrYEKzYkviC
YGnAZpvIeYM8gYz2bYSQAUXix9RrRSa8cGuFQT2xVNRu22BzbDZweY9KmaKMe4Hg
BFxt1OxmgoML/Wz48NSM
=O7qE
-----END PGP SIGNATURE-----

[prev in list] [next in list] [prev in thread] [next in thread]