Justus Winter wrote:
I wrote a test to see how various OpenPGP implementations react to MPIs
that are not in canonical form (i.e. malformed MPIs) for S, or
0x40-padded R, and only GnuPG and PGPy accept zero-padded S:
https://tests.sequoia-pgp.org/#EdDSA_signature_encodings
Thanks a lot for your information. It's very helpful.
Therefore, I'm afraid that changing what implementations emit now will
introduce incompatibilities with existing implementations.
I see. So... I'm going to take conservative approach for SOS when
changing GnuPG; Introduce SOS for new curve only, at first. After new
curve will become common (together with SOS handling hopefully) among
implementations, then, apply SOS to Ed25519 if possible/useful.
FWIW: I changed libgcrypt master for similar leading-zeros problem. For
GnuPG, there are many places (than I initially expected); It's not only
in gpg frontend but also in data format in the protocl between
gpg-agent, and in gpg-agent.
When I locate all places, I change those places to support
non-zero-removed full-size octet string (keeping leading zeros intact),
and then, I'll generate an example OpenPGP EdDSA key with self-signature
(key with leading zeros _and_ signature with leading zeros).
I'd say, "save our leading zeros". :-)
--
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp