[Cfrg] big-endian short-Weierstrass please

[Dan Brown <[e-mail]>]

Dear CFRG,

 

IEEE 1363-2000, ANSI X9, NIST 800-56A and SEC1 use 

 

#10) short-Weierstrass representation for EC points, which is nice because
any elliptic curve, including the latest and greatest, can be represented in
this form, and 

#01) big-endian (MSB-first) octet string representation for prime-field
elements, which is admittedly somewhat arbitrary (with no effect on
security) although somewhat consistent with various old-fashioned notations
for numbers

#11) KDFs based on hash functions SHA1 and SHA2 which are kind of big-endian

 

If raw Curve25519 implementations operate on input and outputs of byte
strings, in whatever order and curve shape, then it shouldn't be too hard
for applications using the raw Curve25519 implementation to shift the
input/output coordinates from/to short Weierstrass (yes, one has to choose
the a-value for this), and then unsort/sort the octets into MSB-first order

 

I appreciate that currently, TLS is thinking to use Curve25519 a named
curve, specified by an OID, and then determine all point representations,
including the internal used ones used in the KDF and signatures, based on
the named curve.  That should work too for TLS and any easily updatable
software.  

 

But I wonder if there are any old implementations of the standards I listed
above, that accept generic specified short Weierstrass curves, but lock
together the KDF and raw ECDH operations.  Users stuck with such
implementations couldn't gain _all_ the benefits of Curve25519, side channel
resistance or whatever, but surely there's some residual benefits for them
to use Curve25519 with a generic representation: maybe the rigidity
Curve25519, or interoperability with other users with the newfangled
software, not to mention the blessing of the collective wisdom of CFRG.  

 

If the argument is that no such implementations could exist, or that the
implementations, or even old ECC standards, are so bad that we should try to
discourage interoperability, then please present that case.

 

Best regards,

 


Daniel Brown


Research In Motion Limited