New OpenPGP Specification

[roughconsensusandrunningcode]

This PR adds a partial support for the new OpenPGP Specification ("Crypto-Refresh" draft, currently in RFC Editor publication queue). Ported from bc-java when possible.

• New signing algos Ed25519, Ed448
• Classes for 25519/448 pub/sec keys encoded as an array of octets rather than MPIs (ported from bc-java)
• Parsing and generation of v6 keypairs (unlocked secret keys only)
• Parsing, generation and verification of v6 signatures
• Parsing and verification (not generation) of v5 keys and signatures (retired draft rfc4880-bis)
• Padding packet (ported from bc-java)
• Packet criticality (ported from bc-java)
• Emit "Version" Armor Header only on explicit request [c-r 6.2.2.1]
• Emit "Hash" Armor Header only on explicit request [c-r 6.2.2.3]
• Tests:
  • keyring parsing and generation
  • inline and detached signature verification
  • encode-decode and sign-verify roundtrips
  • Test vectors from crypto-refresh draft for v6 and from "OpenPGP interoperability test suite" for v5 and multiple v4+v6 signatures.

TODO:

• Encryption functionalities (AEAD modes, v2 SEIPD, v6 PKESK/SKESK, Argon2 S2K, pubkey encryption X25519/X448)
• Keyring generation still requires an UserId, while in c-r [10.1.1] UserId is explicitly optional. Key Preferences should be stored in direct key signatures (type ID 0x1F) rather than in UID self-signatures [c-r 5.2.3.10]. Requires a partial refactoring of PgpKeyRingGenerator and PgpSecretKey classes.

[cipherboy]

Wow @roughconsensusandrunningcode this looks fairly comprehensive on first glance!

Two initial questions for you:

1. Not being that familiar with the broader ecosystem of PGP (I admit, I'm more of a PGP apologist myself), this part struck me as odd:

   Parsing and verification (not generation) of v5 keys and signatures (retired draft rfc4880-bis)

   Does this have widespread enough adoption to warrant inclusion here? Or is it trivial enough to add off of v6 updates that it makes sense to include anyways?

2. You mention a couple of TODOs; are you interested in feedback before those are resolved or want to follow up in later PRs to address those?

[roughconsensusandrunningcode]

Hello, sorry for the late answer

Two initial questions for you:

1. Not being that familiar with the broader ecosystem of PGP (I admit, I'm more of a PGP apologist myself), this part struck me as odd:

   Parsing and verification (not generation) of v5 keys and signatures (retired draft rfc4880-bis)

Does this have widespread enough adoption to warrant inclusion here? Or is it trivial enough to add off of v6 updates that it makes sense to include anyways?

v5 pubkeys packet format is identical to v6 (the only difference is the first octet in fingerprint computation). v5 seckeys (not yet supported by this PR) are very similar but not identical to v6. v5 signatures are identical to v4 in the packet format but include additional metadata in hash computation. Given the small effort involved, I think that a minimal "consume-only" support would make sense, even though the small adoption. According to the "OpenPGP interoperability test suite" v5 has limited support in GnuPG >= 2.4, OpenPGP.js and GopenPGP, and there is a small number of v5 pubkeys in keyservers. A full support (generating keypairs and signatures) is less trivial, and probably not worth it, but I'm open to suggestions in this regard.

2. You mention a couple of TODOs; are you interested in feedback before those are resolved or want to follow up in later PRs to address those?

I'm already working on KeyRingGenerator and PgpSecretKey classes. The encryption part is definitely not trivial, so I'm interested in feedback and reviews of the work done so far, before starting working on it.