Re: [Cfrg] big-endian short-Weierstrass please

[Alyssa Rowan <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 29/01/2015 00:37, Phillip Hallam-Baker wrote:

> Right. The objective here is to dump all the existing code in the 
> trash and start again. Because we want the implementations to have 
> constant time implementations and to preclude the possibility of 
> malicious point attacks by choosing curves that allow us to easily 
> compute y from an x, and only sending the x.
> 
> What we want to avoid at all costs is patent encumbrances. Dumping 
> Weierstrass is a pretty good start because that was the favorite 
> curve of the folk who applied for most of the patents.

+1 to all of this.

> The only area where I did have concerns is that to be able to 
> deploy crypto on these platforms I have to be able to buy FIPS 
> certified hardware or equivalent.

It's probably going to have to be "equivalent", unless NIST surprise us
and come to like the curves and algorithms we do.

> Before the new curves can be used in browsers for certs, the 
> browser providers are going to have to be satisfied.

…and we're going to need a signature algorithm. Our draft doesn't have
one of those, and it seems what we're planning to do is do that in a
second phase, as you address.

> … But I don't want to do that in a way that makes it difficult to 
> move to EC certificates in the future.

Agreed.

> I don't accept that big endian is more error prone. The existing 
> code for X.509v3 crypto is all big endian. Changing that will 
> introduce a new code path and opportunity for error.

Two points here.

1. There's a special circle of hell reserved for those who maintain
   X.509v3 code, where they debug ASN.1 parsers for all eternity! <g>

   Seriously though, if I want to dump some TLS code in the bin and
   rewrite it because it's too hairy, X.509 would be the first thing on
   the list.

2. I think that may well be an engineering decision, for the TLS WG or
   PKIX WG. What we've got here is the wire format of the raw function,
   and I continue to think that's the best approach to keep.

   TLS WG already discussed this and used that directly - little-endian
   and everything - for their Curve25519 key-exchange draft. I see no
   reason to second-guess that. They then also specified new curve
   point formats should be opaque octet strings to them, with no
   special treatment. Doesn't sound like they think endian-swapping for
   transport wire formats is worth it from an engineering perspective.

   It'd probably have to be PKIX WG who figure out how to put the wire
   format of whatever signature algorithm we - later - specify into
   whatever format they specify. If they want LE, or BE, or BCD, or
   ASCII base-10, or wrap it in ASN.1 with an OID and a ribbon on top,
   isn't that properly for them to decide? Either way, I don't think
   that's a big deal: if they really want to endian-swap, they can, but
   I'm not sure we should pre-empt them here.

> Now it should be quite easy to add the new curves to the list. I 
> suspect that unless the browser providers are feeling really 
> generous, they will expect us to end of life our existing ECC
> certs to get the new ones added.

I can't speak for them of course, but that's not the impression I get
from either them or CAs? We aren't _replacing_ NIST curves as far as I
know in a near-term timescale, but providing a better alternative for
the future. NIST seem to have much less sway with NGOs than previously.

There will probably be a steady transition to using them, but, say,
those who need FIPS (as above) may never be able to, unless NIST
shadow our recommendations - which would honestly surprise me, but who
knows?

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUyd2OAAoJEOyEjtkWi2t6yHwP/1zy2Bz6IvM9tdl+g3djxhii
yfxFtdSUBBtCTWqFpvr+sZFkDUT/pdTR8QvX1ttdKqleJp7mzJTh8rToc3vgguCy
ibM2tTOuk3tWcPzdzoiEMWdzKG/7Z1ecucMD9F7SeWiMiI8ebLA64i73tgiCAwZP
A7lvpJ74D2v9iAQMhmNObUzeGguqkJR800gYgYi9VHaBkYIYRrtxyuhfwOES6WNW
QVD66C168cyTsnOApqDuhVy7YRhYr11r/0d1pJC+hboP412O7+FYPJAZZDEaCTB4
3FzRgf+1x6PgPRu77BzoYAfrnm8mk42Yyo9BHHpPZtmmmULYakUj8IhVPZyeenYK
M1x7m4gx6WZpeEJrzvac0FlVrOH6Bg3slGgL/aib6edXE6HQ6alK7wEPTl1//VQp
R7bQC9bM16Ztcrc02FF76JNaZ46/ujdCYicJN8/HHGz3/QyCS8K0Fs8N5Jx/j1DX
LXy5fRNZ/GcS7JRwuFnaaYiEb2Ng42ZW36fdLcWti7n8eR/E9gNODDZov/5B0/V9
jjIsar+25s3sikTzEQVYIZS0W/fuJCLSx+ZtblimPtOJ+33WOsWSgjD3eBuxXO1P
DeTYGQLaEaEE5O4IcDao6xLt+CjoU5ZK3yZgNoihvzPReCqrGb2e//UfmSpv+D/5
So+7wv3rGDbnMwXLb+9/
=EfS3
-----END PGP SIGNATURE-----