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 Fri, Feb 27, 2015 at 12:14 PM, Derek Atkins <[e-mail]> wrote:

> Phillip Hallam-Baker <[e-mail]> writes:
>
> > 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.
>
> Maybe that's the case for your customers, but certainly not mine.
>
> You're ignoring the classes of devices not using TLS because the CPU
> demands of RSA2048 *ARE* prohibitive.  That's where I live these days.
> (Honestly, even the cost of ECC is sometimes prohibitive in the space I
> live these days).
>

No, I am suggesting that the class of device that require more security
than Curve25519 and find P448 performance acceptable that will not find the
additional 60% extra time to do P521 is either the null set or not worth
bothering with.

The choice between P448 and P521 is not going to be a make or break issue
for whether your lightbulb is going to be viable. It isn't even going to
force a choice of chip.



> You're welcome to compare apples to kumquats if you desire, but my
> customers need an apples-to-apples comparison.  Is it really too much to
> ask for timings of RSA 3072, 4096, 7680, 8192, and 15360??  ;)


Yes, because the reason we are going to ECC in the first place is they
don't work.

RSA2048 has a WF of approx 112 bits. RSA4096 is only a WF of 128 bits. To
get to 256 bit security you need those 15360 bits.

If RSA15360 performance was acceptable then P521 would definitely be
acceptable.


Remember the days of the BBN Safekeeper which took 9 hours to generate
RSA4096 keypairs? THAT is quite definitely a make/break issue. If an
operation is taking hours or even minutes then 60% is arguably significant.
But I just don't think you are going to be doing P448 or P521 all that many
times.


> 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.
>
> Really?  And which one would that be?  We seem to have only shown
> consensus for 25519 so far.


That *IS* your constrained curve, sorry.

If you are more constrained than that and can't live with Curve25519 then
Goldilocks isn't going to be relevant to you anyway.