Re: [Curdle] draft-ietf-curdle-pkix and endianess of strings

This discussion probably belongs on the CURDLE WG mail list ...

Note that draft-ietf-curdle-pkix has been published as RFC 8410.

When this object identifier is used:

   id-Ed25519   OBJECT IDENTIFIER ::= { 1 3 101 112 }

the algorithm parameters are absent, so there is no opportunity to define the curve through parameters.

The RFC warns:

   Both [RFC7748] and [RFC8032] define the public key value as being a
   byte string.  It should be noted that the public key is computed
   differently for each of these documents; thus, the same private key
   will not produce the same public key.

The RFC could have also warned about the big-endian vs. little-endian encoding used in different RFCs related to elliptic curve.

Russ

> On Dec 19, 2018, at 4:13 PM, Jeffrey Walton <noloader@gmail.com> wrote:
> 
> On Tue, Dec 18, 2018 at 9:54 PM Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
>> 
>> Jeffrey Walton <noloader@gmail.com> writes:
>> 
>>> You might consider adding a note that the byte array is written to the
>>> octet string with the LSB in the first position, and the MSB in the last
>>> position. As far as I know this draft is the only one that reverses the
>>> byte ordering for presentation. It will avoid confusion for future readers
>>> who expect network byte ordering in ASN.1 presentations.
>> 
>> This was requested when the RFCs were written (alongside using the standard
>> X9.62 form that everything else uses), but nothing got done.  Basically the
>> encoding used for the Bernstein curves is the reverse to the way everything
>> else does it.  So you take the standard form used by all other curves, then
>> encode the values backwards.  In my code I use a shim layer that reverses
>> the bytes, at which point they can be handled by code that expects them in
>> the standard form.
> 
> Yeah, using the little endian presentation brings up some weird use
> cases. Suppose a named curve is not used (i, e., curve25519 parameters
> are specified). The other domain parameters like prime and subgroup
> order are big endian but the keys are little endian.
> 
> I'm fairly certain the best course of action is to make this use case
> work as expected:
> 
> $ dumpasn1 ed25519.bin
>  0  52: SEQUENCE {
>  2   1:   INTEGER 0
>           ...
> 33  32:   OCTET STRING
>       :     6D C5 9D 3F 09 7F B2 3D 44 BA 90 79 12 81 B4 53
>       :     25 8D 69 1A 55 AF 5C E4 F1 EE 71 2F DF 91 AE 98
>       :   }
> 
> And then something like this with Botan (or pick your favorite library):
> 
>   uint8_t sb[32] = {0x6D, 0xC5, ... 0xAE, 0x98};
>   BigInt sk(sb, 32);
> 
> The extra "byte reverse" needed to make things work as expected is
> non-intuitive and not documented. But maybe I am missing something or
> I don't understand the motivation.
> 
> Jeff
> 
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag