[rlpb]

Governments can still gather the metadata of encrypted emails. Both PGP and S/MIME do not encrypt the subject line, sender or recipient addresses.

To use encrypted email and hide the subject line, you need to not use it (just say "Encrypted email") or something. This cannot be made automatic without impacting UX.

The To: header fundamentally cannot be removed. The sender can be inferred from the account within the email provider supplying the Government's feed.

I like the idea for MUAs to automatically encrypt after a mutual automatic key exchange though. I think PGP would be more suitable for this (no CAs required). Is there a standard email header that advertises "you can reply back to me with a PGP encrypted email encrypted to key ID X and I'll be able to read it automatically"? If not, somebody should propose one. Public keyservers exist so I see no reason a simple header like this wouldn't suffice. The rest is MUA implementation.

[tripzilch]

> Governments can still gather the metadata of encrypted emails.

True, but don't throw out the baby with the bathwater right away. I know metadata is at least as sensitive as the actual content, but you need to pick your battles. If we get people to widely use GPG to encrypt the content of their emails, that is already a huge win. Why? Because they're now using a public/private key infrastructure. And as you are probably well aware, as soon as everyone involved has secure private keys, implementing all sorts of nifty crypto strategies to hide pretty much whatever you want, is just a matter of adding protocols. And that can be done pretty transparently, if only the intended users would already be using keypairs for identity management. So, IMO, even if just encrypting the content is not quite complete privacy, it's a great step on the way to getting there.

The other way around, hiding the metadata first, or perhaps both at the same time, seem a lot harder to accomplish widely.

So even if you're technically right, getting the public in the habit of using GPG, is not a waste of time, it's just that for some crazy reason common usage of strong crypto is so far behind the times they are going to need several steps to catch up with technology.

> Is there a standard email header that advertises "you can reply back to me with a PGP encrypted email encrypted to key ID X and I'll be able to read it automatically"? If not, somebody should propose one. Public keyservers exist so I see no reason a simple header like this wouldn't suffice.

that's a great idea. anyone know if something like this does not already exist?

(and I'm not entirely sure if those key-ID's are sufficiently unique and/or secure, but you can put more then just the ID in such a header to fix that)

[DanBC]

> I know metadata is at least as sensitive as the actual content, but you need to pick your battles. If we get people to widely use GPG to encrypt the content of their emails, that is already a huge win. Why? Because they're now using a public/private key infrastructure. And as you are probably well aware, as soon as everyone involved has secure private keys, implementing all sorts of nifty crypto strategies to hide pretty much whatever you want, is just a matter of adding protocols. And that can be done pretty transparently, if only the intended users would already be using keypairs for identity management. So, IMO, even if just encrypting the content is not quite complete privacy, it's a great step on the way to getting there.

True, but key-pairs pretty much cryptographically ties a real person to an online identity, and so that makes meta-data more valuable, and makes "give us your keys or go to jail laws" more scary.

[rlpb]

A PGP key is generally tied to an email address. So autogenerating PGP keys per-email-address surely doesn't tie anything to a real identity any more than an email address already does?

[tripzilch]

but you can make as many keypairs as you want or need. just like the circles in G+, except with privacy :)

[e3pi]

> I know metadata is at least as sensitive as the actual content, but you need to pick your battles.

So, picking the metadata battle:

Its straightforward from the command line to email crypto-content to your desired addressee while emailing(spamming?) to a few more auto-generated others. These newly(if functional) spammed others would value your contact, as it provides them with a participating valid email account, so `spamee' can now also `shotgun' emails to more addressees further obfuscating his intended addressee(s). If this became popular, universal, The graph of all our email metadata (nodes?) becomes chaotic.

The timestamp metadata? Send to subset random sampled addressees over set random offset ranges.

The SUBJECT: header could be automated to filter through all this new junkmail.

What else, hmmmmnnn...

[rlpb]

> If we get people to widely use GPG to encrypt the content of their emails, that is already a huge win.

Sure. Completely agree.

> (and I'm not entirely sure if those key-ID's are sufficiently unique and/or secure, but you can put more then just the ID in such a header to fix that)

Note that a key ID is just the last characters of the fingerprint. If you want a more secure key ID, just use a longer piece of the fingerprint (which is a valid longer form of key ID that gpg will Just Work with).

[tripzilch]

> Note that a key ID is just the last characters of the fingerprint. If you want a more secure key ID, just use a longer piece of the fingerprint (which is a valid longer form of key ID that gpg will Just Work with).

cool, I was hoping it would work something like that :)

[croikle]

> and I'm not entirely sure if those key-ID's are sufficiently unique and/or secure

They aren't: http://www.asheesh.org/note/debian/short-key-ids-are-bad-new...

[rlpb]

Short key IDs aren't. Just use longer ones. No format or protocol change is required.

[krenoten]

Cypherpunks have already created a solution, http://mixmaster.sourceforge.net/ and similar remailers, but similar technology needs to be incorporated into easIEST to use tools.