Message-ID: <528A37C2.60207@fifthhorseman.net>
Date: Mon, 18 Nov 2013 07:52:34 -0800
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Icedove/24.0
MIME-Version: 1.0
To: notmuch@notmuchmail.org
Subject: Re: alot: can't read sent emails, after encryption
References: <20131112142742.8912.57064@localhost.localdomain>
	<87eh6gxeex.fsf@servo.finestructure.net>	<20131117185754.31928.60825@brick>
	<87pppy95lu.fsf@servo.finestructure.net>	<20131118131741.4561.45898@hermes>
In-Reply-To: <20131118131741.4561.45898@hermes>
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature";
	boundary="W2A8dGq2oHINrNBDcE3ptPH32q2wlE0Ld"
Precedence: list
Reply-To: notmuch <notmuch@notmuchmail.org>

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--W2A8dGq2oHINrNBDcE3ptPH32q2wlE0Ld
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=20
> 'encrypt-to key1' when I send emails with my identity of key2 it will a=
lso=20
> encrypt it with my key1 and will reveal to its receivers that I own key=
1. Isn't=20
> 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=3D~/.gnupg-key1 alot" or
"GNUPGHOME=3D~/.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=3D~/.notmuch-config-key1 GNUPGHOME=3D~/.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 challeng=
e.

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


--W2A8dGq2oHINrNBDcE3ptPH32q2wlE0Ld
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQJ8BAEBCgBmBQJSijfCXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB
NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcqqQQAIE0f8BQTOKmShpKnjFjL9CO
npCDNUvkFmSEv6kL0o62b9e/ZebXGZ1883/+HnWobKsugnRPC512f49Pfndmj1zQ
vB/p8bmNV8ToMEBqgOT1dbUWBizEBtADxyzHWCHjGePKqbRdlZUXoMmP7ab9Kqol
KeM1frhukUV4SEemwY16iXEUQXS4jaRYw9skS0blMIYffvoW5qAsAT6uB4HteHCx
wShZZNXKfwHRcz7h1//3Th+j3HtosTFGOEck7BoWqKSZp9l1z6kXRxyFe6rVUnrR
QtzZYDdjwrRe/DJdkQ45GeP0LlJBzn5jKYWoGJ2KjSSkS2VUTtsIWw1jBaqvUAJX
62TN08HvMjLlh4NXkWjux0513ShKjDchD58Le5WS9eIGfk+e4SrRjrg5T8uDN3lB
iMXM/jQjpoGMa6y49ls1JZjQB1usqbMpJSYLIDTklXsh4BC3paJO1b5fTSXCqvPQ
vyEOMPVLsbVJDGku36NBEgM0LyxIoyh7xI2pv+c9pAZS1Y52k03pYkylbbJoLRc5
4EVU8M2UUFNfnvOgGJyLa/ByF9fo6V0ET0UYtHObfIC5zvw+tCMF+6D8em4XBZw9
LNxudt+2gOLFxbSOmZ/JDIOewuBNZBccspzPnRKnTF7ym/Wf6xICyCUpD1MWfRxM
A3veU0E3+3W1XDRuUzRx
=AP9u
-----END PGP SIGNATURE-----

--W2A8dGq2oHINrNBDcE3ptPH32q2wlE0Ld--