Re: [Cfrg] Requirements for curve candidate evaluation update

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

On Wed, Aug 13, 2014 at 10:27 PM, Salz, Rich <[e-mail]> wrote:
>> Long term signature keys have to be generated and stored in HSMs
>
> So EDH keys do not, and therefore do not need HSM requirements, right?

I don't see a large field of established use that would make
availability of HSMs a gating factor for EDH. But obviously someone
could come up with one.

What I am trying to do here is to pare down the set of requirements
WITHOUT throwing out any that could be show stoppers or gating
deployment.

The use of ECC to date in open standards based systems is so
insignificant that we really should not think twice about blowing it
all up and starting from scratch. But if we do that then someone has
to tell the HSM vendors where we are going and some of them have to
sign on.


Not wanting to make a big fuss on the HSM requirement but it is
definitely a potential gating factor. Using the same curve model for
encryption and signature does not interest me in the slightest. I
cannot see that as being a necessary requirement, it is just someone
wanting things to be tidy.

The only good reason to go to ECC right now is to get a bigger safety
margin on your crypto. And it really makes no sense to want to do that
and be shooting yourself in both feet by using signature keys for
encryption or vice versa.

The keys are plenty small enough to have separate encryption and
signature keys. It would be no bad thing if we made it algorithmically
impossible to attempt that type of abuse.

I do want to junk the NIST curves though but not for the reason folk
think. The big problem with ECC is the sheer length of time we have
been waiting. Deployment is going to continue to be slow unless we get
some sort of starting gun. One possibility is that the starting gun is
breaking RSA1024 but having a new set of NSA-free curves agreed by
IETF is good as well.