Re: [Cfrg] revised requirements for new curves

[Alyssa Rowan <[e-mail]>]

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

On 08/09/2014 11:23, Paterson, Kenny wrote:
> Intellectual Property
> 
> IP1. Required: securely, simply and efficiently implementable
> world-wide under royalty-free licensing terms. [C]
> 
> IP2. Desired: securely, simply and efficiently implementable
> world-wide in a patent-free manner. [RC]

I think it'd be invaluable for potential proposals to have a clear
statement about the patent status of a (secure, simple and efficient)
reference implementation, at least - otherwise, it's hard to know how
we can best evaluate these criteria, particularly alongside PE1 and PE2?

It'd be even more helpful for adoption downstream if those reference
implementations were suitable, and permissable, for wide practical use.

Would a patent search help? Someone recently said to me that elliptic
curve cryptography was a [patent] minefield (albeit less so as some
older patents, such as point-compression, expire) - and if we can
clear, or at the very least map, as much of that minefield as
possible, many potential barriers to adoption could be removed.


On 08/09/2014 15:42, Phillip Hallam-Baker wrote:
> I didn't see consensus that we needed 192 bit curves.
> 
> These seem superfluous to me If I want speed then I will go to 128
>  bits. If I want high assurance I will go to 256. 192 is neither 
> fish nor fowl.
> 
> In a perfect world folk can make fine tuned choices between speed 
> and security but I only have two security levels: paranoid and
> till the sun goes supernova secure level paranoid.

I concur entirely with this, agl's points, and Markulf's.

≈WF128 curves can I think deliver the strong, but very efficient
functions IETF protocols are going to want for cryptography everywhere.

≈WF256 curves can deliver about the best we can probably expect from
elliptic curves, until quantum computers eventually show up and crash
that party. If you want to be extra-careful, and some do, that's the
way to go.

≈WF192 is not a great compromise either way IMHO, especially as there
are no convenient 2^x-n primes with very small n in the immediate
vicinity of 384-bit.

Plus, 2 new curves are easier to specify and implement correctly than
3. (1 is of course easier still - as with agl, if we had to pick one,
I'd pick ≈WF128 - but I'd suggest keeping ≈WF256, too.)

If it's optional, I definitely say drop 192 from requirement SE6. You
don't exactly see people queuing up to use AES-192, do you (or even
SHA-384 for anything but NSA Suite B)?

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUFeqKAAoJEOyEjtkWi2t6Cu8P/iT6XNwwPSCqQBZXKvD0NwpB
Fa37gNWkozQvbF6elk4tGllH/fhRlxD3/6DZQeTm8ZHW/WpH4q2XF3o6V3gk/Pl7
GCri7xpGcizPdfmQ2HvgJnK6uVqzcyRGpvjz/lsbrq8vDBlPO5O0NffIWrMSUQ6B
oB1RZBU0D8Y9C79Cd0PoTyF/CfXh0ktj3eke/8tHli/Jepn3L+3TnilXODYXYRX9
deoxA/fTJ3xAZQx29iEwVMCmMi9Wj4L1naVmEpj0yh/Gy5JRHtKG2uT076Nux/DG
adHYdy9rAIFRMtTWPNbJxQyblrgede+W05kd3fkn0IuuUHxY0QVeGpViruP8HB3I
EPHon7wBTOE11CfOnmhIm6jurVwz1HXtSJehRE3Z+tVo9pJ+vq1FGpanj0g8PgXj
h3vAIcOY00IrltzAxuj9YsQuSyl9Gxz4Krd5ri3RZU+7Xs2Z1iLEr3e3Jg6p1D1D
tTcHAobcJ4zrm/FS750rQAFma6Ze5tydhsDmQAsfmlb8OyYws0reTNkKzxAH0NRt
vVhVa/Tel49cC6wZf4psdjUAs1CAh6ACTw5n0FokHoMADKnnx7iWDYY4zkm2O7et
nwi92g5XjddtlWStc9Yy+RR4cHJwcZvutgeineHCwNcGtjrhFswpDJnqNH8xI/8o
QEWL8wRCRsV7hu22Brzb
=ppd9
-----END PGP SIGNATURE-----