Subject: [Openpgp-dt] notes from 20210903

From: Stephen Farrell <[email-masked]>
Date: Fri, 3 Sep 2021 16:45:02 +0100

OpenPGP DT meeting 20210903

Present (so far:-):
     - stephen
     - paul
     - daniel H
     - justus
     - jeffrey

No quorum, but we'll chat about 448 to see if we can get closer an 
agreed approach amongst those on this call anyway.

https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/61 is the 
closest MR

Daniel H sent mail to DT list with 6(+1 from Justus) options:

     - Different possible consistency goals exist and can be weighted 
differently:
        - 448 vs. 25519
- 448 vs. other PGP curve representations
- 448 vs. (somewhat) deployed code

- #1 possible agreement to be checked: x25519 private value is 
"reversed" (for historic reasons), we're incling towards not reversing 
the private value for x448 (because we won't be fully consistent between 
both anyway) and that may better map to the somewhat deployed code

- #2 leading zeros: generally, we'd prefer to not strip leading zeros 
from the fixed length values related to 448

- #3 (from Daniel's mail) option 3 kinda breaks compatibility with rfc6637

If one agreed with #2 that'd eliminate options 1 and 2 from Daniel's mail
If one agreed with #1 that'd eliminate options 1 and 6
If one follows #3 then that's eliminate option 3

That leaves options 4 & 5 from Daniel's mail and option (now called 7) 
from Justus' follow up.

The rest of the discussion is kind of a thought experiment to see what'd 
get us down to one option:

- Option 5 is more or less what's coded and maybe (?) a bit deployed, 
options 4 and 7 are not. But we're (on this call) not clear how much the 
developers of that would like to keep it or are amenable to change.
- New alg ids (as in option 4) can cause work elsewhere that's not 
really valuable and is somewhat ugly

That bring us (on this call) down to two options: 5 and 7:

## Option 5: Simple Octet Strings

Simple Octet Strings (SOS) are a proposal by Gniibe to simplify the
handling of leading zeros going forward.

SOS(data) is defined as:
- If data[0] == 0, then: (two bytes containing length(data) * 8) || data
- Otherwise: MPI(data)

- EdDSA key: OID, SOS(public key); SOS(private key seed)
- EdDSA signature: SOS(r), SOS(s)
- ECDH key: OID, SOS(public key), KDF; SOS(private key)
- ECDH message: SOS(public ephemeral key), one-octet length || symmetric key

I believe this is what GnuPG 2.3-beta implemented; correct me if I'm wrong.

## Option 7:

- EdDSA key: OID, MPI(0x4F || public key); MPI(0x4F || private key)
- EdDSA signature: MPI(r), MPI(s) // wart...
- ECDH key: OID, MPI(0x4F || public key), KDF; MPI(0x4F || private key)
- ECDH message: MPI(0x4F || public ephemeral key), one-octet length || 
symmetric key

I.e. for every cryptographic artifact (point and scalar, but cannot fix
signature w/o a new EdDSA algorithm identifier), take the octet string
as-is, prefix 0x4F (ASCII 'O' as in octet-string), then MPI encode.

On the call:
     - Q: can you not live with any of these? A: nobody can't live with 'em
     - Q: any preferences betwen 5 & 7: no very strong prefs but some

---

From: Justus Winter <[email-masked]>
Date: Wed, 08 Sep 2021 12:49:43 +0200

> If one follows #3 then that's eliminate option 3

#3 also eliminates option 5, because SOS is not MPI.

> I believe this is what GnuPG 2.3-beta implemented; correct me if I'm wrong.

I can confirm that GnuPG 2.3 does that (modulo the SOS-encoding of
private keys, which I didn't confirm experimentally).

Justus