Re: [Cfrg] Not the same thread -> was Re: Rerun: Elliptic Curves - preferred curves around 256bit work factor (ends on March 3rd)

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

On Thu, Feb 26, 2015 at 10:56 AM, Derek Atkins <[e-mail]> wrote:

> Mike Hamburg <[e-mail]> writes:
>
> > Thanks, Paul.
> >
> > On 3.6GHz Haswell with OpenSSL 1.0.1f:
> > RSA-2048: sign 1028us, verify 31us
> > Ed448: sign 51us, verify 163us, dh 148us
> > Ed480: sign 55us, verify 183us, dh 170us
> > E-521: sign 79us, verify 256us, dh 241us
>
> I asked this in the previous thread but it was lost, so I'll ask this
> again in this thread: Why are you looking at RSA 2048 for this
> comparison?  That's only a 2^112 work factor (C.f. Section 1 of
> RFC4492).
>
> If you want a 2^256 work factor you need to go up to RSA 15360.  If you
> only want to get to 2^128 then you need to look at RSA 3072.
>
> Let's at least compare apples to apples.


The reason is that as far as customers are concerned, they are switching
from RSA2048 to something else. We have already established that the CPU
demands of RSA2048 are not prohibitive for any class of device currently
using TLS.

If I am looking at buying a new van, the question I am going to ask is not
which one has most capacity, fuel economy, etc. but whether it is the same,
better or worse than what I already have and whether the current situation
is acceptable or not. If I am moving from a van to a truck I am going to
ask what the impact on fuel consumption is even though I know the truck
holds more because I know if my current fuel costs are acceptable or not.


We already have an EC curve that is optimized for new applications in
constrained devices etc. So knowing how we are doing relative to the
baseline of RSA2048 is informative.

If we were looking at additional load on the server then we would have to
be very concerned because that is a bottleneck.


> On 1GHz Cortex A8 with OpenSSL 1.0.1f:
> > RSA-2048: sign 39.8ms, verify 1.2ms
> > Ed448: sign 0.7ms, verify 1.9ms, dh 1.9ms
> >
> > On both CPUs, the elliptic curves are slower than RSA for verification,
> but
> > much faster for signing.  The Haswell core is about 5-8x faster for RSA
> verify,
> > and 20x slower for signing.
>
> But at quite different security levels, so it's not telling us anything
> useful.  I think Ed448 is more like an RSA-4096 level (or possibly even
> larger than that).


The reason we are moving away from RSA is that 1) Index calculus continues
to improve and 2) RSA hits steeply diminishing returns, its more like
16Kbit keys to get an interesting improvement in performance.

RSA2048 is the baseline for performance. It is not the baseline for
security. The objective here is to improve security without adverse impact
on performance.

The reason I was asking the question is that if we can do P521 at lower
cost than RSA2048 then the fact that P448 takes only 62% of the time that
P521 does isn't very interesting. If P521 was going to be a lot slower on
the server then my customers would be really concerned about performance
and demand P448 and we would have an objective criteria on which we can
justify an answer.

As it is, I don't see performance as being an objective discriminator
because there is only a negative impact on clients and the CPU overhead on
the client side is a negligible fraction of the PKI overhead. I would bet
that we improve performance client side for TLS on a Raspberry Pi 2 under
real world test conditions using P521 over RSA2048 simply because all the
cert chains etc are much smaller. Yes verifying signatures takes 8 times as
long. But we are talking about an operation that takes a 1.2 ms on an
iPhone CPU today.


If we go for P521 then nobody can possible criticize us for having chosen
something less secure than we did.

If went for P521 and P448 I guarantee that my world will only use P521 and
P255.