Re: [Cfrg] ECC reboot (Was: When's the decision?)

[Alyssa Rowan <[e-mail]>]

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

On 16/10/2014 17:08, Paterson, Kenny wrote:

> Our first task should be to finalise the requirements that we will
> use to guide the selection process. I think we are close, with a
> couple of outstanding issues:

Alright, so let's try to get things in high gear and argue those out…?

> 1. Amount of "wiggle room" that should be permitted.

Broadly: I think what we're aiming for is probably one faster/strong
curve, and one stronger/fast curve.

Given the strong preferences of some to minimise the number of curves,
it looks to me like ­≈384 is almost-definitely dropped, leaving us
with something near ≈256 and something near ≈512.

We seem to be in agreement that wiggle room on ≈256 would include
fields of 2^255-19 as well as 2^256-189 in scope.

For the paranoid-strong, performance-second ≈512, 2^512-569 very
obviously falls within scope.

I put forth that 2^521-1 also falls within scope. It's not very far
away, and it's a true Mersenne prime rather than a pseudo-Mersenne,
and they do not grow on trees - no others fall near our criteria (the
next lowest is 2^127-1 which is way too small, and the next biggest is
2^607-1). They are very attractive - attractive enough for 4 (?)
independent research groups to independently arrive on E-521, and
SECG/NIST to have independently picked the same prime years ago for
secp521r1.

[Previous discussion countering this point: Sean Parkinson @ RSA
suggested stepping over a power of 2 is "only going to hurt
performance in the future". Phillip Hallam-Baker also thought anything
that is not less than a clean multiple of a power of two "may cause
severe performance hits on future architectures", mentioning 512-bit
memory buses on graphics cards?! - although I'm not convinced that's
actually primarily relevant to an implementation of a high-strength
curve. We will, of course, evaluate performance of contenders in Phase
II, future architectures can be more-or-less anything that works well,
and performance implications usually aren't anything like so obvious…
Aren't Mersennes actually particularly _good_ performance-wise?]

I put forth that 2^414-17 and 2^448-2^224-1 might fall outside "wiggle
room" there, although I do so very reluctantly as I think it's a shame
to exclude them on that basis if they have otherwise nice properties,
and they do seem to have very good performance for their strength.

> 2. A more nuanced set of hardware requirements.

See other thread.

> So here's a proposal for a new schedule which I believe to be
> feasible: 24/10/14 (1 week from now): we finalise requirements,
> including hardware requirements.

Optimistic? One way to find out. <g>

> 31/10/14 (2 weeks from now): we agree on whatever benchmarking
> system we're going to use for performance measurements. (Right now,
> supercop seems like the front runner to me.)

Consider this an early +1 to SUPERCOP.

> 30/11/14 (6 weeks from now): we deliver our recommendations to the
> TLS WG.

Let's give it a try!

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

iQIcBAEBCgAGBQJUQA6fAAoJEOyEjtkWi2t6U8gQAJG9FmifkdZs2QQv+2gB8o2w
fWdo6FztDHIyGaUTaOLzHdKhs7+3Ts7ozH2S418zNYNZ3rHbpi68iXxg57ekAeMo
c8Nncog1ryB1K7s3BW38BZltcX2ceJrNv5Y33HEf6JwhG8lYyHDeiuSDuShXRi/B
yv/UiI5uR+JmFR7kD4LDtgIB/uaNBCL4SUjIfWb1PrFe9+Y+b9boElnarDUcDifO
RL1BbwiRuLAGKQCpfaw27dV86PxhCIGMj7aIP7xraBCVuSC6tFITY05H4MMZ85RE
5DSdDHcrKIcKm4bv3teLj3G4V6TUjJf7JW8ubhNQiicbN4isqumny8ZCWKLu1zRC
U9CQF0oRvTLGTwIYOI6UD8+dhZ6vL2ckjIDKoSZ6vss6cwNTjSkHnR1wAnstqL8T
YVOJsGj1Dth64AFpNjMRsoHEVSaU6m64QuANNBchynqOSpB9+F1EsJjpSwMk4jkU
ejkRf7b73HRus6I9AwuQeZzubUQ8gqqs5t6xxM3+YMjtTlRa5ymvfaGJFA8MeKNA
8PpuiZOmWC6PKA4L7Cd3d6lKm7YZhGQBtqGVuJB83xzomDOoNQBPDLhHF8V8zXil
4avghhLlZNwWoKFcNlc46MGK7KBSu5fqrMN0hqhz+TkUKou3eTgXLAXiXReXJ/6L
YzVvRl8bzJNkeTRar6Zp
=9Y7p
-----END PGP SIGNATURE-----