Determine migration plan for gpg -> Sequoia

[legoktm]

In gpg, public and private keys are stored in a single keyring. Sources' private keys are locked with a passphrase that is derived from the codename, so we only can unlock it when the source logs in.

With Sequoia, we are going to store the keys in the database table as armored OpenPGP keys. Ideally we will be able to migrate as much as possible at once during upgrade so we don't have to keep the legacy gpg code around for too long.

[legoktm]

@legoktm said:

Some bad news on the migration front. We can't export secret keys out of GPG without knowing the passphrase. This is because GPG stores them using a different internal format (https://unix.stackexchange.com/questions/698117/export-gpg-private-key-without-knowning-the-passphrase) so it has to decrypt them before it can export them in OpenPGP format.

This means we can't do a full offline migration, it can only be done when sources log in and we have their passphrase. So we have two options, 1) do the migration whenever a source logs in, or 2) just have "old gpg sources" and "new sequoia sources" that just vary on which code path is hit.

My current thinking is that we migrate the public key offline, and then when the source logs in we migrate the secret key (option 1). This minimizes the use of gpg overall, since post-login we shift everything over to sequoia. Also if a journalist replies before the source logs in, it still uses sequoia since we've migrated the public key.

[legoktm]

@zenmonkeykstop said:

The downside of both options is that we can't really define a cutoff for removal of the old gpg code - it will be hard to verify that all valid/active sources have been migrated. I wonder if it's possible to import the encrypted key without decrypting it, maybe skipping python_gnupg and parsing the keyring directly with https://docs.sequoia-pgp.org/sequoia_openpgp/cert/prelude/struct.CertParser.html or similar.

(Stuff like #6488 to clean up dbs and keyrings would probably help reduce the pain a little.)

[legoktm]

The private key format is documented at https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob_plain;f=agent/keyformat.txt

I looked around a bit and didn't find any independent parsers for it (aside from gpg itself). There's an open ticket for sequoia that's kind of related: https://gitlab.com/sequoia-pgp/sequoia/-/issues/119

I'm going to ask on the sequoia mailing list about what our options are and if they have any other suggestions for migration.

[legoktm]

I discussed this with Neal today in #sequoia on OFTC. Their work to interact with gpg will be https://gitlab.com/sequoia-pgp/gpg-store.

I brought up the idea of using the chameleon for exporting private keys, Neal pointed out that since it still uses gpg-agent under the hood, we could just use gpg directly for the export part and move on. I'm pretty OK with this since 1) it's no worse than what we already do and 2) we can do it now, not blocked on any upstream development. The main thing I want to see is how to get rid of pretty_bad_privacy, maybe by copying whatever parts we need.

Also, there is support in Sequoia already for reading s-expressions (https://docs.rs/sequoia-ipc/latest/src/sequoia_ipc/sexp.rs.html#148-208), I'm going to investigate that further tomorrow.

[legoktm]

We basically have a plan now, the implementation work is tracked in https://github.com/freedomofpress/securedrop/issues/6800 and https://github.com/freedomofpress/securedrop/issues/6802