[Cryptography] IETF discussion on new ECC curves.

[Phillip Hallam-Baker]

On Mon, Jul 28, 2014 at 9:05 PM, William Allen Simpson
<william.allen.simpson at gmail.com> wrote:
> On 7/27/14 1:57 PM, Watson Ladd wrote:
>>
>> Picking from 6 curves means that 1/6 curves has to be weak to force the
>> choice.
>> Picking a BADA55 curve means 1/2^32 curves has to be weak. The rigidity
>> issue
>> is much less bad than you make it out to be.
>>
>> By contrast, rigidly picking curves ignoring performance means that
>> people will use
>> the small curve instead of the big curve, when they would prefer the
>> medium curve.
>> These curves are all about speed.
>
>
> Never-the-less, all protocols should be designed so that one
> party (usually the responder/server) lists all supported
> algorithms, and the other party chooses from that list.  This
> avoids reliance on particular curves, and allows the parties to
> choose appropriate strengths.
>
> Who are we to decide that the application needs the "utmost"
> security instead of speed?
>
> Moreover, there are too few curves.  We should also encourage as
> many good curves to be published and analyzed as possible.
> Certainly there are even better to come!

No, we are a standards organization.

One curve with a work factor 2^128 for minimum security apps plus one
high strength curve with a work factor the square of that.


The approach you suggest was abandoned about ten years ago when we
discovered that the security of an application was determined by the
security of its weakest cipher. Adding strong ciphers does not make an
app more secure. Only stopping using a weak cipher makes it more
secure.

We do insist on algorithm agility but no more of the algorithm zoo
these days. So there is a requirement for a backup algorithm that is
believed secure if the base is broken. These are backups for RSA2048.


On Mon, Jul 28, 2014 at 7:48 PM, Bear <bear at sonic.net> wrote:
> On Sat, 2014-07-26 at 14:32 -0400, Phillip Hallam-Baker wrote:
>
>> Curve 25519 is close to 256 and its easy to make the argument. But
>> there isn't a convenient prime near to 2^512. When we come to choosing
>> curve E521 its a gut check sort of thing...

> (- (expt 2 512) (findpr (expt 2 512) 5))
> ;Value: 569
>
> So the first fermat-test prime number below 2^512 is 2^512 - 569? It's
> a nice nothing-up-my-sleeve number, anyhow. What's the problem with it?
> Are there some requirements I don't know?
>
>                         Bear

Yep, that is exactly what Microsoft did. The problem is that it is not
exceptional speed wise. The fast moduli are 2^521 and 2^480.

Curve 25519 (2^255-19) is quite a bit faster than the 2^256 curve. And
its arguably the same strength (what is half a bit?). But even so, its
a subjective argument that X% faster is worth losing a tiny bit of
security and the more bits get dropped, the more subjective it gets.


The other way to make the argument would be to say that for a given
amount of security, what is the fastest curve that delivers it. Which
means that we reject the shorter modulus and go for E521.

Its a good argument but still a harder sell than the NUMS argument of
'pick a strength, pick a modulus and choose the largest prime that is
less than 2^(strength*2).


Its not so much a technical argument as a 'how do we decide what color
to paint the bikeshed'