Re: [Cfrg] Chopping out curves

[Adam Back <[e-mail]>]

I'm not sure if we should be going as far as generating new curves, or
significantly tweaking choices in the existing curves in incompatible ways
(eg new generators), I thought original idea was more to provide in RFC
format the best rigid/NUMs curves available that people are already starting
to use so they at least have a reference.

Generating new curves or significantly deviating from them or their exiting
parameter choices, creates our own NUMs risk, and a restart on the review
process, creates something that needs to have its own (maybe derivative)
name, and places CFRG in the biased editorial position of both generating &
selecting...

Adam

On Fri, Jan 17, 2014 at 07:41:53AM +0000, Alyssa Rowan wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA512
>
>On 17/01/2014 02:36, Adam Back wrote:
>
>> Uh I meant the Curve25519 and Curve3617.
>
>We have three key sizes for AES, and three hash sizes with SHA-2 and
>SHA-3 (and the candidates).
>
>I propose:
>• curve25519 (plus twist t25519)
>• curve3617
>• e521
>
>That gives us three curves with strength roughly congruent to the 128,
>192 and 256 key sizes, and about as good performance as we're going to
>get for those levels.
>
>curve25519 is likely to be used for high-performance ECDH; its twist
>is likely to be used for high-performance encryption and signing.
>
>curve3617 seems likely to be used for higher-assurance encryption and
>signing (Silent Circle intends to use it, for one).
>
>e521 is slower, but very conservative - maybe you'd want to use it for
>very careful signatures or encryption; the prime field is of course a
>well-known Mersenne prime people are already used to (thanks to
>secp521r1), and it's so rigid, three people came up with the
>parameters independently.
>
>I wouldn't cry a river if we dropped e521 from that list.
>
>Those are, I think, the two or three that applications are most likely
>to actually want to use in practice.
>
>
>Regarding the t25519 basepoint, the argument for using the ed25519
>basepoint is that it's already out there and thus already rigid, but
>yes, it is ugly.
>
>If you do choose a new basepoint, Watson (and I can see the sense in
>that), please rigidly document the choice criteria so the decision can
>be independently verified and confirmed (minimal y, right?).
>
>I haven't had my first cup of tea yet today, so I apologise if I'm
>wrong, but I believe any new basepoint would need to go through the
>SafeCurve verification tests again, because ℓ would change? - run it
>yourself for sanity checking, and please post the source files on the
>list so we can use Sage or something to verify it too, but please also
>speak to Tanja and djb about that to get wider verification.
>
>- --
>/akr
>-----BEGIN PGP SIGNATURE-----
>
>iQIcBAEBCgAGBQJS2N7AAAoJEOyEjtkWi2t6OaUQAIyZsJdPlguckuHKMY+UdCJN
>YEaRx4MXQ5BrBH2Z8HrMdrY+4mmNqogI23MzAUYjE5/TdKcQvfOYDtpW7D6ooKAx
>K+SFj553BmE6By4F3woZ/5bsRH3oifnFaT7g6OMRijGpkaN//AWIx8PdMU3LbrrB
>tXHG2ciEmlKr5rdve8EhA3c9dUZo3XE2qltiWplaK5kObskl+bpXibm0JmajMVzl
>DLi0b5lzh3l7JZVqL0gR1Nk/swd5PSXqgET2k7NhBfrP0+NbJ7niGYUFT1gVtxVz
>2Qg0aDusvlRTeFeVCxUiZV7oDQg1+JbaMxTUg6gAP6HuUCnuzy2A6D+0Dt9qajX2
>UvHezZawZhC8PL2XPIgjXhTVCiUCz6oexy1V2OCKFO+ZIGcvypIMT6N5WbVZVzIb
>G4YNv+IrUEFnfssfkueXr4huBat4gZ2HXArG4hWd/85EOvxbTng4tAkShSRJl5bS
>cYaej5Tlz5WC4evzZC+VvnHeyzVInPn9AFJdkKjQeuPgXaANeluI9SdpFW5hY3w4
>o6wmLDdnX2lxVeq8rY0pz0aXvxTm/IFpn7SlVs7RZU0upmuCzquKfAUgcjcaYaj0
>JkLPu8Iq/aSpfIF4foC7jNJn43yNN76rqpxUjXICQosbg3ybqZTzs+ppjB10SPOr
>n8JoVsmG08Boh8FpVHo2
>=8vwB
>-----END PGP SIGNATURE-----
>_______________________________________________
>Cfrg mailing list
>[e-mail]
>http://www.irtf.org/mailman/listinfo/cfrg