[Cryptography] IETF discussion on new ECC curves.

Trevor Perrin trevp at trevp.net
Sun Jul 27 13:48:23 EDT 2014


On Sun, Jul 27, 2014 at 6:30 AM, Phillip Hallam-Baker
<phill at hallambaker.com> wrote:
> On Sun, Jul 27, 2014 at 1:16 AM, Trevor Perrin <trevp at trevp.net> wrote:
>
>> It's reasonable to ask for a work factor significantly greater than
>> 2^128 as a hedge against cryptanalysis.  But people like Adam Langley,
>> myself, and Mike Hamburg have argued that demanding the work factor
>> match a precise number (like 2^256) is over-prescriptive.
>>
>> https://www.imperialviolet.org/2014/05/25/strengthmatching.html
>> https://moderncrypto.org/mail-archive/curves/2014/000140.html
>
> The point is not whether you need exactly that amount of security. It
> is whether you can argue that the curve has not been selected for a
> hidden reason.

You can never know whether someone has "hidden reasons", nor can any
selection process be perfectly rigid.


> If it was a choice between A with exactly 2^256 and B with slightly
> less it would be one thing. But once you open up anything less than
> the full work factor its not just one alternative curve, its six or a
> dozen. And the choice is subjective.
[...]
> Absent a definitive way to choose between them, I can't really pick
> any. Its back to the 2^512-x curve

You're arguing for Microsoft's prime 2^512 - 569, but their original
paper proposed three other primes at (510, 511, and 512 bits), and one
at 521 bits [1].  How do I know you're not picking the weakest?  And
why is 512 a more rigid number than 384 or 448?

Focusing on relative efficiency would be a similarly rigid and
objective approach - there will only be a few "most-efficient" curves
(and only that many if different processors favor different curves,
which may not be the case - we're still waiting to compare Goldilocks
and 41417 across 32-bit ARM and 64-bit Intel).

Of course, focusing on performance criteria rather than arbitrary
numbers like "512" means a faster curve.

And the main reason for a new curve is speed.  The NSA backdoor in
NIST EC-DRBG is a PR debacle for the NIST/NSA curves, but the real
problem with those curves is that they are slow.

Trevor

[1] http://research.microsoft.com/pubs/209303/curves.pdf


More information about the cryptography mailing list