alot: can't read sent emails, after encryption

Daniel Kahn Gillmor dkg at fifthhorseman.net
Mon Nov 18 07:52:34 PST 2013


On 11/18/2013 05:17 AM, Ruben Pollan wrote:
> If I have t[w]o identities, with two different gpg keys (key1 and key2), and I set 
> 'encrypt-to key1' when I send emails with my identity of key2 it will also 
> encrypt it with my key1 and will reveal to its receivers that I own key1. Isn't 
> it?

It won't formally *prove* that you own key1 (no one will be able to say
for sure that the public key encrypted session key packet actually is
decryptable by key1, it just has the 64-bit keyid embedded in the PKESK,
and even if it did, it could arguably have been added as a Bcc: to
another independent person), but it will certainly imply to anyone who
gets more than a single message from you that there is this other key
involved somehow.

If you have multiple identities, there are other approaches you could
take without changing alot itself, for example:

You could have two separate ~/.gnupg directories, and you could launch
alot differently, with "GNUPGHOME=~/.gnupg-key1 alot" or
"GNUPGHOME=~/.gnupg-key2 alot" to make these responses.

If you really care deeply about keeping the identities distinct, you
might even want to split your notmuch dataset into two places as well,
so that you don't accidentally reply from one identity to another
identity's message:

 NOTMUCH_CONFIG=~/.notmuch-config-key1 GNUPGHOME=~/.gnupg-key1 alot

and so forth.

or you could use two distinct user accounts or virtual machines so that
the data as even fewer possibilities of being mixed (e.g. ensuring that
the outbound SMTP path, and/or the message-IDs generated when sending
each message don't share any features that might leak their common
provenance).

None of this is particularly convenient; maintaining separate identities
that are difficult for an adversary to re-correlate is a serious challenge.

That said, i can imagine that alot (and other notmuch frontends) could
be improved to support this use case directly without forcing users to
go through the extra hoops i've envisioned above.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20131118/8ff02e4d/attachment.pgp>


More information about the notmuch mailing list