Re: [Cfrg] Another perspective on the Curve256/255 problem

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Jul 31, 2014 at 1:43 PM, Salz, Rich <[e-mail]> wrote:
>> [I am using WF128 to remind ourselves that this is a 2^128 Work Factor which
>> is what really matters here.]
>
> I like this notation.
>
>> So PKIX, S/MIME and OpenPGP should just use WF256. Which means that a
>> TLS stack is going to need the ability to do WF256.
>
> Can you explain this?  I don't see the "which means" justification, which means I'm missing something.

The browser providers want to limit the number of roots in their trust
stores for good reason. My customers want high security so I
definitely need a WF256 curve. But I am not going to get a WF128
factor root as well unless I give up something else and I don't want
to do that.

So the bottom line is that a TLS stack that wants to support the
WebPKI is going to need a WF256 signature scheme. But it is not clear
that a WF128 scheme is needed.


Its funny the way that when I want to add a feature to a protocol
people push back and when its algorithms I'm the one asking if they
are really necessary.



>> DJB: Speed! Speed! Speed!
>
> That's not how I would characterize it.  One of Dan's slides said something about removing the friction between security and performance. I wish I wrote it down, it was a brilliant insight.  The first time I've seen a real systems approach to crypto (which probably says more about my ignorance of the field than anything else).  For example, Curve25519 requires the top bit to be set, so that implementers don't expose timing attacks by skipping down until they find the first bit set.

Is there a reason that would only work for that particular curve and
not the NUMS? I wasn't seeing that as a discriminating argument. Its a
good one though.