GnuPG interface security
(These are misellaneous security notes, collected during and around the threat modeling sessions with Eleanor Saitta.)
When sending mail to a group of recipients, it is important to only assume the lowest common denominator of security and make that clear and visible to the user. We want them to think "why isn't this encrypted?" so they can take steps to fix that (contact the user without a key for example, or trigger key discovery of some sort).
Replying to a message, or forwarding, should maintain security if at all possible. We can't prevent the user from downgrading the security but there should be clear, understandable warnings.
The current lock is good, but it might be good to also have a lock for the header section, and some sort of indication on the send button or elsewhere, telling us how secure the transport is.
For certain workflows, it would be useful to have a "lock security" button, which enforces stronger security for message headers, bodies or transports. In this mode addresses which don't fulfill the security requirements would not be available as recipients and other behaviors which might degrade security would be prevented. This enables the user to think like so: "I am about to say something sensitive, but to avoid accidentaly fat-fingering it and leaking information, I am going to put Mailpile in secure composition mode before I even start writing."
The main risks to downloading keys, is it exposes to 3rd parties who you are communicating with and provides remote third parties with information about which groups of users are conversing, leaking data about the social graph.
- Should probably be done by default unless a message signals somehow that it is meant to be anonymous.
- If we have a p2p channel, requesting keys over that could make sense for a TOFU model.
- When downloading keys, it would be best to do so via. Tor, and take care to randomize delays between downloads and ask Tor to create a new "identity" for each download.
- It can be very important to download keys to "fill in the blanks", if a group message is sent encrypted to multiple people, and one is missing keys in order to reply - replying unencrypted should probably be prevented (see above), and so obtaining keys is necessary. In this case it is important to download keys by Key ID, checking the encrypted data being replied to, not use the e-mail addresses as they might not match.
Things to tell the user:
- You have not seen this key before, and have not verified it.
- You have seen this key before, but have not verified it.
- You have seen this key before, and have verified it.
- This key is different from what that person presented last time.
- Is new key signed by old key? (OK, shutup)
- The old key was about to expire
- The old key was revoked
- This might be weird.
There are 3 places where PGP data is exposed in our data structures: the message summary, message text part, and message metadata
There is a crypto overview for messages that pertain to the WHOLE message, this overview will ALWAYS have information about encryption and signature states and contains mixed-* states as well as the normal states
messages: { MID: { crypto: { encryption: { context: "", # a number for comparing text_part crypto state 29 have_keys: [], # start of a key? B8127F5124462421 missing_keys: [], # start of a key? 8E86CED32B2BBB65 protocol: "", # one of: openpgp status: "" # one of: none, decrypted, missingkey, error, mixed-* }, signature: { context: "", # a number for comparing text_part crypto state 30 email: "", # an address: [email protected] keyinfo: "", # a fingerprint or key ID 23GF7C78D83C580EF939 name: "", # name of contact: Josephine Smythe protocol: "", # one of: openpgp status: "", # one of: none, invalid, expired, revoked, unknown, verified, unverified, mixed-* timestamp: "" # a UNIX timestamp 1389280400 } } } }
Each part of text data MIGHT have information about the encryption, signature, both or neither. This ONLY contains normal PGP states and never mixed-* values.
messages: { MID: { text_parts: [ { crypto: { encryption: { context: 29, status: "none" }, signature: { context: 30, email: "[email protected]", keyinfo: "23GF7C78D83C580EF939642F230904D9190FG52B", name: "Josephine Smythe", protocol: "openpgp", status: "mixed-unverified", timestamp: 1389280400 } } },{ crypto: { encryption: { context: 38, status: "none" }, signature: { context: 39, protocol: "openpgp", status: "none", timestamp: 1389280400 } } } ] } }
Each message item in search results and threads also ALWAYS exposes crypo overview about both the encryption and signature of a given message. This returns the various mixed- states as well the normal states
metadata: { MID: { crypto: { encryption: "", # one of: none, decrypted, missingkey, error, mixed-* signature: "" # one of: none, invalid, expired, revoked, unknown, verified, unverified, mixed-* } } }
- none: no signature
- invalid: the signature was invalid (bad)
- expired: the signature was made with an expired key
- revoked: the signature was made with a revoked key
- unknown: the signature was made with an unknown key, so we can't verify it
- verified: the signature was good, and came from a verified key
- unverified: the signature was good, and came from a key that isn't verified
- error: there was some weird error.
Possible situations:
- Not encrypted or signed
- Encrypted, but couldn't decrypt. No signature.
- Encrypted, but couldn't decrypt. Invalid signature.
- Encrypted, but couldn't decrypt. Unknown signing key.
- Encrypted, but couldn't decrypt. Good signature.
- Encrypted, decryption successful. No Signature.
- Encrypted, decryption successful. Invalid signature.
- Encrypted, decryption successful. Unknown signing key.
- Encrypted, decryption successful. Good signature.
- Not encrypted. No signature.
- Not encrypted. Invalid signature.
- Not encrypted. Unknown signing key.
- Not encrypted. Good signature.
Ella recommends against using it, because the WoT generates a persistent and public social graph that can be mined by adversaries.
And a historic record.
And it does not work.
Should be automatic, using best practices, 4K RSA, expiration? 2-3 years?
Questions to a minimum: Do you have a key? Upload to keyserver?
On expiration, Mailpile could automatically generate new keys and sign with old keys and upload. Depending on pres.
Life-stylers vs. normal humans, punt to the command-line for people who do not like the Mailpile GPG model. Or if possible make it a "build your own plugin" problem.