gpg --export produces invalid EdDSA output - regression

[Marek Marczykowski-Górecki]

On Thu, Sep 14, 2023 at 02:11:52PM +0200, Werner Koch wrote:
> Hi!

Hi!

Thanks for the answer!

> The issue you mention has been discussed in length and Gniibe actually
> took over my place in the "crypto-refresh" design team to help clarify
> the interpretation of the MPI (which they unfortunatley ignored).  MPIs
> in OpenPGP are signed and thus may need a zero prefix byte because
> negative numbers are nowhere used.  

Hmm, but the RFC seems to specify it as unsigned, not signed:
https://datatracker.ietf.org/doc/html/rfc4880#section-3.2

   Multiprecision integers (also called MPIs) are unsigned integers used
   to hold large integers such as the ones used in cryptographic
   calculations.

   ...

   Additional rules:

   The size of an MPI is ((MPI.length + 7) / 8) + 2 octets.

   The length field of an MPI describes the length starting from its
   most significant non-zero bit.  Thus, the MPI [00 02 01] is not
   formed correctly.  It should be [00 01 01].

> The solution is to specify a new
> type (SOS) at least in certain parts of the protocol.  This must of
> course be done in a backward compatible way given that ed25519 is in use
> since 2014.

Given the above, I'm not sure if that's really necessary. But even if it
is, it isn't "backward compatible" change, since standard
respecting-compliant implementation is expected to treat leading zeroes
as malformed.

> GnuPG 2.2 is older and and does not yet use the SOS which is the reason
> for the different encodings you see.  In short, there is no bug but
> implementations need to follow this advice
> 
> 1. OpenPGP implementations should implement:
> 
>     Recovery of leading zero octets for Ed25519 key handling (secret
>     part) and Ed25519 signature
> 
> 2. OpenPGP implementations are expected to accept:
> 
>     Malformed MPI (with leading zero octet(s)), which is valid in SOS
>     For secret part of Ed25519/Curve25519/X448/Ed448 key and for
>     signature value S.

My reading of the above is rather "an OpenPGP implementation that wants
to be compatible with GnuPG should also accept MPI that is not compliant
with the OpenPGP specification"... Have I missed some part of the spec?
Is this new "SOS" type described in some specification?

> (see https://dev.gnupg.org/T4954)

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20230914/34c0e67f/attachment.sig>