Re: [Cfrg] Requirements for curve candidate evaluation update

On Thu, Aug 14, 2014 at 5:26 AM, Phillip Hallam-Baker
<phill@hallambaker.com> wrote:
> On Thu, Aug 14, 2014 at 1:49 AM, Alyssa Rowan <akr@akr.io> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> On 14/08/2014 03:42, Phillip Hallam-Baker wrote:
>>
>>> To be clear, I am arguing that we put HSM support way ahead of a
>>> single model. HSM support is essential, a single model is
>>> someone's idea of tidiness.
>>
>> That is a null property. Anything we can specify can be implemented in
>> software or hardware. As I said before, there will _eventually_ be new
>> HSMs, and new HSM firmware. People have already begun work on that.
>
> What the constraint means is that if we come down to two curves and
> little to choose between them and there is a significant difference in
> the HSM situation then the curve that allows re-use of existing HSMs
> wins, if neither does that then the curve that has support from HSM
> manufacturers wins.
>
> So folk peddling a curve would do well to line up HSM vendor support.

Let's back up a bit: every curve can be expressed in Weierstrass form
over the same field, so will work with todays ECDSA implementations.
Good? No.

1: Some implementations may have dedicated hardware to do reduction on
the NIST primes
2: Some implementations may assume prime order for correctness
3: Some implementations may not permit the use of arbitrary parameters

So to the extent that we are changing curves, it's not clear that
there is any way, even if we use prime order Weierstrass over the same
primes, to get complete support on HSMs. It's also not clear that
different curves materially differ in this respect.

>
>
> It isn't quite true to say that you can do everything in hardware or
> software. There are very specific constraints here to do with side
> channels and IPR that could have a huge bearing on what curve families
> are viable and which are not.

All the proposals look about the same: if you were to quiz me on which
was which, just showing me the primes and the coefficients, I would
have to do some arithmetic to see if they were complete or not, and so
if they were the NUMS curves or not.

Sincerely,
Watson Ladd

>
>
>> The commercial world of this are however glacially slow-moving, partly
>> due to onerous and ineffective governmental certification requirements
>> (one of the things that has been - rightly - criticised). Several do
>> not support ECDSA (or ECDHE, where applicable) properly or at all, and
>> this is why RSA is still far more common in the wild and ECDSA is
>> quite honestly barely used by anyone publicly (there are _very few_
>> ECDSA PKIX roots...) - those that are using it are running it in
>> software and are therefore not relevant to your 'essential' requirement.
>
> There are very few serious CAs. So its not surprising there are few
> ECC roots. We have ECC roots, so do the other leading CAs. But the
> reason for the lag has been IPR FUD.
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin