Re: [Cfrg] Requirements for curve candidate evaluation update

[Benjamin Black <[e-mail]>]

"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."

ECDHE is the default kx for Google, Microsoft, Facebook, Twitter, and many
other large service providers. Perhaps you mean ECDSA.

"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."

Which encryption do you mean here?


b



On Wed, Aug 13, 2014 at 7:39 PM, Phillip Hallam-Baker <[e-mail]
> wrote:

> 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.
>