| 2022-06-03 20:23:40 |
Bill Yikes |
description |
Neomutt gives no possible way to send a PGP-encrypted msg and then save an unencrypted local copy. This forces users to choose from the following workflows:
1) Encrypt the msg only to the recipients & store a copy of it, which the sender can never again see the payload they sent. In this case the body of the msg is just a useless & space-wasting blob. The sender can have a record that they sent a msg (the metadata) but no way to recall what they sent. In fact the payload serves as a risk with zero benefit, because in the event that the recipients key is compromized the sender’s copy can then be read by an adversary.
2) The sender adds an “encrypt-to” config option to gpg.conf that causes all msgs sent to be encrypted to themself. This enables the sender to keep an accessible record of what they sent out. One side-effect is that they may choose to keep email records longer than they keep their private key, and so when they lose or delete their private key or password, they can no longer access records of what they sent. That’s not serious, but consider this scenario: Alice anonymously sends a highly sensitive PGP-encrypted msg to wikileaks & forgets that she has everything set to encrypt to self. Wikileaks (or someone forcing wikileaks) can run pgpdump on the encrypted payload and see Alice’s keyID. Doxxed!
Both options 1 & 2 need improvement.
Approach 1 can be improved by giving users the option to store metadata only. Mutt should save only the headers (perhaps including the original payload size), but delete the payload itself both for security and for wiser use of storage space.
Approach 2 should perhaps be possible for users who want that option (everyone has their own threat model), but there needs to a be a 3rd option: give users the possibility to store a plaintext copy so they are not always at risk of accidentally doxxing themselves. |
Neomutt gives no possible way to send a PGP-encrypted msg and then save an unencrypted local copy. This forces users to choose from the following workflows:
1) Encrypt the msg only to the recipients & store a copy of it, which the sender can never again see the payload they sent. In this case the body of the msg is just a useless & space-wasting blob. The sender can have a record that they sent a msg (the metadata) but no way to recall what they sent. In fact the payload serves as a risk with zero benefit, because in the event that the recipients key is compromized the sender’s copy can then be read by an adversary.
2) The sender adds an “encrypt-to” config option to gpg.conf that causes all msgs sent to be encrypted to themself. This enables the sender to keep an accessible record of what they sent out. One side-effect is that they may choose to keep email records longer than they keep their private key, and so when they lose or delete their private key or password, they can no longer access records of what they sent. That’s not serious, but consider this scenario: Alice anonymously sends a highly sensitive PGP-encrypted msg to wikileaks & forgets that she has everything set to encrypt to self. Wikileaks (or someone forcing wikileaks) can run pgpdump on the encrypted payload and see Alice’s keyID. Doxxed!
Both options 1 & 2 need improvement.
Approach 1 can be improved by giving users the option to store metadata only. Mutt should save only the headers (perhaps including the original payload size), but delete the payload itself both for security and for wiser use of storage space.
Approach 2 should perhaps be possible for users who want that option (everyone has their own threat model), but there needs to a be a 3rd option: give users the possibility to store a plaintext copy so they are not always at risk of accidentally doxxing themselves.
(edit)
The fcc_clear option is that 3rd option. So a lot of this is moot now. But note two problems still remain:
* wasted space if a user chooses approach one
* the fcc_clear behavior leaves no trace that the msg was sent encrypted which is a bit annoying. It’s useful to know when looking at old sent msgs whether or not a msg was encrypted. Ideally mutt should add a header that lists encrypted recipients. E.g.:
X-Mutt-PGP-Encrypted-To: 0xabc123 0xdef456 |
|
