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

[David Benjamin <[e-mail]>]

(Is the concern that RFC 7748 and RFC 8032 differ in endianness or that the
pair of them differ in endianness from X9.42-style EC? I'm assuming it's
the latter, because the former is not the case. RFC 7748 and RFC 8032 both
specify little-endian. They're different for other reasons.)

No objections to clarifying, but RFC 8032 (correctly) specifies Ed25519 and
X25519 algorithms as functions on byte strings and RFC 8410 (correctly)
defers to that. So probably a better question is whether RFC 8032 is clear
enough on the internal serialization.

I think the best architecture here is for byte string serialization to be
handled by your Ed25519 and X25519 implementations internally, so the ASN.1
layer doesn't need to care. (Endianness is far from the biggest distinction
between X9.42-style EC and X25519/Ed25519. They use different curve
equation shapes altogether.)

As an analogy, if you look at SHA-256's internals, a SHA-256 hash isn't 32
bytes, but eight 32-bit integers. But this is not a useful public
interface, so SHA-256 comes with a particular byte encoding of those eight
integers. It could have been big-endian, little-endian, or middle-endian
and nothing outside of low-level SHA-256 implementations would have known.

It is unfortunate that ECDSA got this wrong and saddled us with a mess of
different serializations, wasting time and complexity. RFCs 8032 and 8410
happily did not repeat this mistake, and we should keep this up.

To that end, the quoted text talks about using curve parameters explicitly
rather than a non-named curve. RFC 8410 doesn't specify such a thing. I
would have made a lot of noise if it had. :-) Which encoding is this
referring to?

David

On Wed, Dec 19, 2018 at 4:03 PM Russ Housley <[e-mail]> wrote:

> 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 <[e-mail]> wrote:
> >
> > On Tue, Dec 18, 2018 at 9:54 PM Peter Gutmann <[e-mail]>
> wrote:
> >>
> >> Jeffrey Walton <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/saag
>
> _______________________________________________
> Curdle mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/curdle
>
>