Re: [openpgp] Algorithm-specific data: problems with Simple Octet Strings, and possible alternatives

[Ángel <[e-mail]>]

Some thoughts, trying to write down the problem definition (of which I
may be missing something) and throwing out a few ideas, not necessarily
useful.



> ```text/x-diff
>     00000010  07
> -   00000011     02 03                                           ecdsa_public_len
> +   00000011     02 08                                           ecdsa_public_len
>     00000013           04 29 75 bb 53  55 49 31 80 ab 03 54 15   ecdsa_public
> ```

Tthe source of this difference is
 04h = 0000 0100b.

Thus, SOS would counts those 5 leading zero bits but MPI doesn't.


Currently a consumer could round the bit length to the next multiple of
8 and use that for jumping n octets, *except* if the encoded number
would begin with the high bit set.
E.g. number 128 is [00 08 00 80] not [00 08 80] (which would a negative
number, could that appear anywhere?)

Spurious leading zeroes (e.g. [00 09 00 00 00 01 FF]) are not allowed
now.

However, in SOS-land, an algorithm may want to use a block of octets
"00 00 00 01 FF". That could be prepended with a length of 40 (SOS
proposal) 09 (MPI bit counting)...

If we restrict ourselves to the modern ECC pubkeys (retconning this to
RSA would be very cool, but probably impossible) it currently uses,
for NIST curves:

 04 || x || y 

which is an UncompressedPointRepresentation (rfc8422#section-5.4.1):
an uncompressed(4) PointConversionForm followed by X & Y opaques.

and for Ed25519/Curve25519 it uses 
 40 || x


I'm thinking that perhaps the SOS could be defined as having *three*
prefix bytes. The upper 13 bits defining the length of the black box,
followed by a 3 bit parameter checksum and an algo parameter not
included in the SOS count. NIST Curves would be defined as X || Y and
receive a PointConversionForm of 4 as parameter.

Similarly for X25519.

That would allow defining the current pseudo-MPIs in a cleaner way
based on an algorithm-specific opaque string as SOS tried to.

Future algorithms could set a parameter such as 0x80 or 0xFF to produce
a nicer count, but considering the first byte as a separate (and
somewhat magic) value outside of the opaque string do allow a better
definition than the current MPI which are really something else, while
making existing implementations fit instead of requiring special casing
("Practically easiest" option).

However, that doesn't work for the signature, where there *is* zero-
removal/zero-recovery.


Best