An octet sequence as an MPI

[Niibe Yutaka]

NIIBE Yutaka wrote:
> IIUC, this issue originates in RFC 6637, and we can find same problem in
> the draft of rfc4880bis.  I will ask and discuss in OpenPGP WG, if
> needed, but for now, I'd like to improve the implementation at first.
[...]
> It is described as "MPI", but I think that it is better to be described
> as "size + octets".
>
> MPI has semantics than mere octet string; It is (may be) interpreted as
> a big-endian number, and its representation can be changed where minimum
> size representation is assumed (removing zero octets at the beginning).
>
> For #1 and #3, putting the point representation in an MPI is
> questionable, as the point is not a big-endian number.  Because of its
> prefix (the first octet, 0x04 or 0x40), it is safe against removing-zero
> handling.  But, by defining as "size + octets", it allows any point
> representation.
>
> For #2, the description is not accuate for EdDSA, since it's not "a
> scalar of the public EC point".  It is just a fixed-size octets.  When
> it is handled as an MPI, it is unsafe against removing-zero handling.
> So, our implementation of libgcrypt has special care for that, namely,
> detecting removed zeros to recover them.  By defining as "size +
> octets", it allows curve implementation to interpret octets.
>
> For #4, current implementation assumes an MPI, but it is more natural
> for other curves to define it as "size + octets".  For Curve25519, we do
> use this field as an MPI (as a big-endian number), just like other NIST
> curves.  For X448, it is more friendly to the X448 API to use this field
> as a native fixed-size little endian octets.  By defining as "size +
> octets", it allows curve implementation to interpret octets.
> (We can define X25519, using X25519 native format.)

To be friendly to existing data of Ed25519, I think that it's
good to define native string format as:

    a two-octet scalar for (8*size of octet string)
    octet string

It could be interpreted as an MPI, but generally it's ill-formed MPI,
because the first bits can be zeros.

I realized that GnuPG implementation handles those things as an MPI of
OpenPGP format.  We need to change to support native bytes.
--