Hi,
On 10/13/23 03:21, Neal H. Walfield wrote:
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?
It's not actually their email, it's a randomly generated ID, we're just using the "email" terminology because that's what GPG used.
Note: OpenPGP doesn't require a self-signed user ID, and Sequoia (unlike gpg) supports using certificates without any user IDs.
I neglected to mention this in my initial email (but later clarified on IRC), we still need to be GPG-compatible until we've ported the SecureDrop Workstation to Sequoia as well (https://github.com/freedomofpress/securedrop-workstation/issues/812).
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:
Source keys don't ever expire, but best practice is to delete the source and their keypair once the journalist is done communicating with them, so in theory instances should eventually get rid of all the remaining GPG-backed sources. But the code won't be around forever, probably a few years, our long-term plan is to have SecureDrop adopt an end-to-end encrypted protocol that most likely isn't going to be OpenPGP-based (see https://securedrop.org/news/future-directions-for-securedrop/).
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.
TIL about this. We're storing the key pair in our database so you'd need a SQL injection attack to modify the key first, and then we're not vulnerable to the specific attacks described in the paper since we don't generate signatures (just encryption/decryption) and Sequoia isn't vulnerable to the second decryption attack.
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.
Thanks for the issues and review :-) I'll add that one of the secondary reasons for writing the limited Python bindings ourselves was so we could begin the process of shipping written-here Rust code and all the tooling, etc. to go along with that.
Here's what a password protected key looks like:
<snip>
In practice, I don't think it matters, as you are using a high entropy password (diceware).
Ack.
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?
Sure! I started with https://docs.sequoia-pgp.org/sequoia_guide/chapter_02/index.html and basically copied that into our code, iteratively adjusting it as needed by using the API reference docs and occasionally peeking at the underlying code when I needed to figure out a type's name. I don't recall looking at the code of other programs that use Sequoia.
As a person who is reasonably familiar with GPG, I mostly struggled with understanding lower-level OpenPGP concepts. For example, I had no idea what a PKESK is, so it took me a while to figure out why the code failed to decrypt messages encrypted for multiple recipients (https://github.com/freedomofpress/securedrop/pull/6891) - the example code in the guide (reasonably) just assumed it was the first/only recipient.
So while not specific to Sequoia, I'd suggest it would be nice if there was some guide to OpenPGP concepts that is less intimidating than the RFC. Hope that helps, I don't have any actual critiques for Sequoia itself!
-- Kunal