Hi Kunal,
Thanks for reaching out!
On Wed, 11 Oct 2023 19:19:06 +0200, Kunal Mehta via Devel wrote:
SecureDrop is migrating from GPG to Sequoia in our upcoming 2.7.0 release.
That's exciting news for us!
When a source logs in, they are given a diceware passphrase ("codename" in SD documentation). The server generates a PGP keypair protected by that passphrase.
The generate_source_key_pair function takes an email address:
https://github.com/freedomofpress/securedrop/blob/develop/redwood/src/lib.rs...
Is it really a good idea to identify sources by their email address? Note: OpenPGP doesn't require a self-signed user ID, and Sequoia (unlike gpg) supports using certificates without any user IDs.
When sources log in, we use their passphrase to export their secret key out of GPG and into our database as well.
Do keys for sources expire eventually? If not, does that mean you're planning on keeping this migration code around forever? If so, we should probably prioritize this issue:
https://gitlab.com/sequoia-pgp/sequoia/-/issues/928
How are you authenticating the public key material? Are you assuming that the password is the trust root, and using that to authenticate the user's public key? If so, you might be vulnerable to the KO attacks:
KO attacks are possible when the secret key material is not stored on a trusted medium.
To bring Sequoia into our Python application, we've written a small Rust crate ("redwood") that implements the encryption, decryption and key generation functions and can be exported to Python using the PyO3 bridge: https://github.com/freedomofpress/securedrop/tree/develop/redwood.
I took a look at redwood and filed a few minor issues. I think this is a really great example of a point solution done well. We've been reluctant to write generic wrappers for different languages as there is so much API surface to cover, and have instead advocated for exactly this approach. Its good to see that it works.
We'd appreciate if anyone could take a look at our Sequoia-interfacing code, with a focus on the following areas:
- Are we creating PGP key pairs correctly?
generate_source_key_pair looks fine. As mentioned above, I wonder if using a user id is really sensible.
https://github.com/freedomofpress/securedrop/blob/develop/redwood/src/lib.rs...
Where are the keys for journalists generated?
- Is this (armored text) a safe format to store keys in?
Good question!
Here's what a password protected key looks like:
$ sq key generate --with-password --output - --rev-cert /dev/null | sq packet dump No user ID given, using direct key signature Enter password to protect the key: Repeat the password once more: Error: File FileOrStdout(Some("/dev/null")) exists, use "sq --force ..." to overwrite Secret-Key Packet, new CTB, 134 bytes Version: 4 Creation time: 2023-10-13 09:19:43 UTC Pk algo: EdDSA Pk size: 256 bits Fingerprint: 3813AF675F10B96FE7E8045B736052477A1D3BE2 KeyID: 736052477A1D3BE2
Secret Key:
Encrypted S2K: Iterated Hash: SHA256 Salt: 4E9DC4C911A889C7 Hash bytes: 65011712 Sym. algo: AES-256
The password is stretched using OpenPGP's "iterated and salted s2k" KDF. You can read about it here:
https://datatracker.ietf.org/doc/html/rfc4880#section-3.7.1.3
It's not a great KDF anymore. The crypto refresh introduces an Argon2 variant, which has better security properties:
https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-11.html#na...
In practice, I don't think it matters, as you are using a high entropy password (diceware).
- Are we generally using the correct Sequoia APIs / are we using those
APIs correctly?
My impression after carefully reviewing the redwood code is, yes. The minor issues that I found, I reported.
It would be helpful for us if you could share how you approached using Sequoia's API, and any issues you had along the way. Did you mostly look at the documentation? the examples? Did you look at the implementation? other programs (sq?) that use sequoia-openpgp? What types of difficulties did you have? What could have made working with sequoia easier? Any other suggestions?
As a general note, it has been fantastic to use Sequoia. So thank you to everyone who has worked on it!
:D Thanks for the feedback! One of our major goals was to make the API usable and pleasant to work with, and it sounds like we achieved that!
:) Neal