OpenPGP API

[veqtrus]

I would like to contribute by writing an OpenPGP packet parser. I would like to ask for your preferences regarding how the API should be structured.

Also do you have strong opinions regarding the code style? I'm mostly asking about the brace indentation...

[randombit]

This would be great. For API structure it is hard to say - how much of the OpenPGP spec are you planning to implement?

Broad things

• Put everything PGP specific into a new module (src/lib/pgp)
• Try to keep the public headers to a minimum, ideally one or two.
• If you are adding support for keys, make a distinction between public and private keys (eg PgpPublicKey and PgpPrivateKey are distinct types, and PgpPrivateKey does not inherit from PgpPublicKey - this is different from how the library does it with with X.509 keys but that was a mistake I wouldn't want repeated)
  • Also on the topic of keys, I think there should just be a single type for public and private keys, rather than having algorithm-specific RsaPgpPublicKey EcdsaPgpPublicKey etc types. Then you can query eg PgpPublicKey::algorithm() which returns an enum of which key type is actually used.
• I believe we support everything required to implement PGP (as is done already in https://github.com/rnpgp/rnp) and particularly one thing to note is that CRC24 in the library is the PGP CRC.
• Remember tests. General goal is >90% line coverage as a baseline.

In terms of indentation, don't worry about it - I'm planning on introducing clang-format to autoformat everything and we can can just format everything in one go.

master has recently branched for Botan 3.0 which is moving to requiring C++17 so feel free to use that unless you have a need/interest in backporting it in which case you'll need to stick with C++11. [3.0 release is ETA early next summer, 2.x branch is now basically in support mode but backports are ok]

[veqtrus]

I would start with just reading and writing the main packet types so that encryption/decryption and signing/verification can work. So at least initially I wouldn't support the legacy serialisation options. Once we get that we can think about stuff like revocation and certification. I would somewhat base my work on supporting https://github.com/boring-pgp/spec, although I would start with the older modes of encryption rather than AEAD.

[jonathanverner]

I wonder, would this allow one to use, e.g. p11 modules, to do the actual crypto operations for pgp? E.g. having the keys stored on a smart card. Or in some cloud HSM...

[veqtrus]

I wonder, would this allow one to use, e.g. p11 modules, to do the actual crypto operations for pgp? E.g. having the keys stored on a smart card. Or in some cloud HSM...

In the initial implementation I'm working on probably not. But it could be extended in the future.

[frankipl]

Hi I'm nnewbie with crypto libraries, I need to encrypt passwords using OpenPGP with Keys like in openpgpjs https://github.com/openpgpjs/openpgpjs#encrypt-and-decrypt-string-data-with-pgp-keys Will this be possible with Botan ? Best Regards Marek

[CheyenneForbes]

Hi all, any updates regarding this?

[veqtrus]

I abandoned my work because I realized that for my use-cases PGP would be a bad choice.

The complexity of a PGP implementation is comparable to TLS, but the complexity of the user interface is much higher because certificate handling needs to be exposed. PGP doesn't deal with public/private keys directly, rather certificates which can contain multiple subkeys, some of which may be expired or revoked. It's also hard to restrict yourself to a subset, as unlike in TLS there is no negotiation.

Out of curiosity, what would be your use-case @CheyenneForbes?

[CheyenneForbes]

@veqtrus My project includes a feature that requires end to end encryption in addition to the other features of PGP. I've been using botan for my projects and respect it. Do you happen to still have the code you've worked on so far? I'd work on the PR, etc.