Re: [Cfrg] Point format endian

["Derek Atkins" <[e-mail]>]

Paul,

On Tue, January 27, 2015 11:07 am, Paul Hoffman wrote:
> We do not need "consensus" in this RG, just assurance that what we
> recommend does not have security holes. No one has suggested any security
> holes based on the endianness. The argument that "using different math
> would add code" is true, but pretty much irrelevant relative the to the
> size of the code needed to add a new curve. There is no interoperability
> issue: if someone messes up the math in either endian direction, they will
> know the first time they test their code, and there is approximately
> 2^-128 chance that if they got it wrong and only tested one vector, that
> they will accidentally get a good result.
>
> The longer we argue about our preferences (instead of actual security
> issues), the worse off the IETF is.

It is important for interoperability.  If I tell you that my ECC Public
Key is 0102030405060708090a but you interpret that as 0a090807060504030201
-- we will get different results even if both of us implement the math
correctly.  So I would argue that transmission encoding of keys and
results *is* a matter of security.

Then of course there's the matter of using the shared secret in another
algorithm, like AES.  Again, byte-order differences would result in
different AES keys.  Yet another matter of security.

Yes, it just mean we just need to "choose one".  But for the last 20+
years we've already chosen:  network-byte-order.

> --Paul Hoffman

-derek

-- 
       Derek Atkins                 617-623-3745
       [e-mail]             www.ihtfp.com
       Computer and Internet Security Consultant