Re: [Cfrg] Point format endian (was: Adoption of draft-ladd-spake2 as a RG document)

[Dan Brown <[e-mail]>]

Endianess also matters for the ECDH shared secret and signature point to integer, or point to byte string, conversion, not just wire format, right? 

The internal op formats seem more important than wire format it since cannot be fixed by an external wrapper that translates formats, and it deals with secrets, so needs side channel security, etc.

For interoperability, an implementation of generic short Weierstrass  ECDH would need to know what shared secret endianness is needed, if it were to try to operate with a new format Curve25519 ECDH public key that has been translated by some kind of wrapper. Maybe we don't need or want this kind of backwards interop?

Network order maybe makes sense for plaintext numerics, to allow more rapid response than even throughput, but for crypto bignums, I don't see this as applicable: usually the whole big num is essential. My vague understanding is that most crypto standards only followed network order‎ for wire format in order to fit in (tradition) , and then just used the same order for internal conversions, to avoid having two different formats.

 

Best regards, 

-- Dan
  Original Message  
From: Salz, Rich
Sent: Sunday, January 25, 2015 2:48 PM
To: Mike Hamburg; Dan Harkins; [e-mail]
Subject: Re: [Cfrg] Point format endian (was: Adoption of draft-ladd-spake2 as a RG document)


> Does anyone know of existing code which processes cryptography over
> multiple fields using a generic bignums package (hopefully with fixed-size
> bignums for timing resistance), and would be complicated by inconsistent
> endian practices in a new curve? If so, it might be worth considering a
> consistent endian.

OpenSSL. I'm on the dev team. But we want the interop and efficiency of the X25519 defined wire rep.

I apologize if I offended anyone (esp Dan)by my note. I don't find tradition a compelling argument. Especially since for X25519, you just do a buffer-copy from the network buffer into the crypto buffer. Much less work.

_______________________________________________
Cfrg mailing list
[e-mail]
http://www.irtf.org/mailman/listinfo/cfrg