Hello,
Daniel Kahn Gillmor <dkg(_at_)fifthhorseman(_dot_)net> wrote:
IIUC, SOS is basically intended as a genericization of MPI; it
represents its length in a two-vector scalar as (8*octet-count) instead
of as (bit-count). It "fits" where MPI fits, but doesn't require
leading-zero removal, or require interpretation as an integer at all.
Sorry, I was not able to describe SOS accurately, in detail.
In the implementation of SOS in GnuPG 2.3-beta, it is mixture of two;
One case is with bit-count and another case is with 8*octet-count.
Former is used when there is no problem of leading-zero removal. Latter
is used to ensure no removal of leading zeros.
a) Introduce SOS and apply it to existing ECC pubkeys.
My (not-so-strong) proposal is to introduce SOS data type, and apply it
for ECC (pubkey or ephemeral key, signature, and secret), so that we can
explicitly require no removal of leading zeros to allow fixed-size data.
Implementations will have to handle new representation with leading
zeros (when interpreted as an MPI). Actually, many already do when
reading data.
I think that we cannot remove the existing mess from implementations,
when we need to support existing data.
What I pursued was to clarify the mess with possible improvement by the
specification.
The benefit of this approach is:
Minimum impact to the specification and implementations.
Compatibility, possibly encouraging better interoperability for
existing corner-cases (of Ed25519 and ECDH with Curve25519).
Flexibility, for new curves, no extra definition will be needed.
But, I know that describing existing data of Ed25519 as weird MPI
representation acculately ... would be difficult in a specification.
So, I don't insist much for applying SOS idea in the specification. For
some implementers, it would work as a technical guidance for
interoperability to interpret existing OpenPGP data with Ed25519.
Well, nevertheless, I believe that it's good to introduce a new distinct
data type (if not SOS) for opaque octet string, if possible. It will be
useful to be friendly to not-yet-standardized things.
--
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp