[Cryptography] IETF discussion on new ECC curves.

[Phillip Hallam-Baker]

On Sat, Aug 2, 2014 at 12:46 PM, Trevor Perrin <trevp at trevp.net> wrote:
> On Fri, Aug 1, 2014 at 2:26 PM, Phillip Hallam-Baker
> <phill at hallambaker.com> wrote:
>> On Fri, Aug 1, 2014 at 2:42 PM, Trevor Perrin <trevp at trevp.net> wrote:
>>> a 512-bit twisted Edwards curve like Microsoft's will have keys of
>>> 510 bits, not 512, so you must mean a 514-bit prime?
>>
>> The attacks are also a lot more expensive than one AES operation. So
>> we don't need to be precise to the bit.
>
> You were making a precise rigidity argument.  Since that didn't point
> at your favorite prime, now anything close is acceptable?
>
> That means other NUMS primes at 510-514 bits should be on the table,
> so we're in BADA55 territory - what you're pretending is a rigid
> "exclusion criteria" is actually somewhat arbitrary.

I am saying that the work factor rigidity argument constrains to a
range. But if you want strict rigidity then you match the prime size
to the data bus width which is an integral multiple of 64.

I don't think the work factor rigidity argument rules out Curve 25519
or E510. But it is an exclusion criteria for E480 and E448.


>> Tell people to pick one or the other. They can have bleeding edge
>> performance with a curve that is chosen for speed or they can choose a
>> curve with no security compromises.
>>
>> It is as simple as that: Performance or No-Security-Compromise.
>
> That's awful, I want performance and high-security.  So do many
> people.  The crypto that gets used is crypto that meets *both*
> criteria.

Curve 25519 then.


> There's a reason no-one likes 16K RSA, despite "matching" a 256-bit
> work factor.  Don't be 16K RSA!

I seem to remember that you need rather more bits to get to WF256. And
there are backwards compatibility reasons that make using RSA16K
prohibitive. Most implementations have limits on the cert sizes they
will accept for understandable DoS reasons