Re: [Cfrg] ECC reboot

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

On Thu, Oct 23, 2014 at 10:27 AM, Watson Ladd <[e-mail]> wrote:
>
> > In principle, yes, but...
> >
> >> What about if we picked two: one fast secure curve at 128 and one at
> some
> >> higher "paranoid" grade (be it 384, 448, 480, 512, 521, 607...)? Which
> would
> >> you perhaps consider using when? Would you have one root at each level,
> or a
> >> shared root at the paranoid level?
> >
> >
> > I'm inclined to agree with my colleague PHB, who wrote recently:
> > "The Web PKI will almost certainly be based exclusively on the ~512
> > level curve. The roots certainly will."
>
> Previously, when given a choice of curves, the one with size 384 or
> thereabouts was picked. Now you are saying you want the biggest
> possible curve, regardless of the performance impact. I've heard
> complaints that P384 is already painfully slow to verify on mobile.
> It's a lot more sensible to pick Goldilocks: just as fast as what you
> have now, but a few hundred bits bigger.
>

That really depends on your mobile. Whatever numbers are picked there will
always be a significant number of devices being made that are not suited to
doing repeated public key operations. There are more 8 bit devices being
made today than at any time in the past.

But equally important, nobody is looking at ECC as a fast alternative to
RSA2048 in consumer oriented devices any more. Commodity processors are
cheap enough and low power enough to do RSA2048 without breaking sweat.



> If you really needed 512, you would have already done it. So the fact
> that you haven't tells me that you don't actually need a 512 or 521
> length root key and are perfectly fine with anything above 384 in
> length. The performance of verification is an issue for some clients
> already: we don't need to make it worse.


We don't really 'need' ECC at all. Unless something happens to RSA2048 that
is unexpected, TLS is almost certainly fine for quite a few years yet.

Given the mess the NSA has created here, we have to put clear water between
our new curves and the old. It is not enough for me to be satisfied that
the system is secure. Its the general Internet population that has to be
confident that they are safe from having their crypto cracked.


How long do you think it would take to make an HSM that supports our
> choice? Is this a matter of grab an ARM chip, add some custom
> firmware, bypass caps, and epoxy (say ~ 6 months), or is it a more
> involved process?
>

Vastly more involved and producing the hardware and software for the HSM is
at most 25% of the effort required.

The requirement is for a certified HSM, not just something that we are
confident is secure. This is an area where we are likely to require
assistance from NIST because they have the only widely used certification
program.


As a practical matter it is much easier for the NIST people to add a new
512 bit curve to their stable than to add in an additional 384 curve whose
advantage over the previous curves is being demonstrably free of perfidy by
NIST.