Re: [Cfrg] Elliptic Curves - poll on security levels (ends on February 17th)

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

On Tue, Feb 10, 2015 at 1:46 PM, Mike Hamburg <[e-mail]> wrote:
>
> And by clear advantage I mean, can be explained over the phone in as short
> as time as possible. This has to be a complete no-brainer upgrade.
>
> For the upgrade to be a no-brainer, the performance will need to be good.
>

It is going to be a lot better than RSA2048 but with the public/private
advantage reversed.

Since we are usually worried about performance on servers rather than
clients, this will probably remove the need for special hardware.



>  It is important that we have a back up algorithm that can be more or
> less relied on to provide a ten year cushion in the case that Curve 25519
> is broken. But we don't need that cushion to be particularly efficient.
>
> Ah, good point!  And at the standard rate of 25 bits/year, 384 bits would
> only provide a 5-year cushion.
>

The only way we are going to need an algorithm with more bits is if someone
goes and does something very very clever. I am not at all worried about the
prospect of CPU performance eroding the key size. What would be a concern
is a quantum computer or something like index calculus for elliptic curves.


   Cache.  Nobody's going to hit DRAM in their ECC inner loop.
>

Whatever happens at the memory bus will propagate through the rest.