Both of these statements can't possibly be true:

* PGP is only trustworthy if both parties treat key management with the utmost severity.

* Transparent key management systems that rely entirely on heuristics and click-through warnings are trustworthy.

Really they can both be true. They're just true for different constituencies. The vast majority of users are not targeted by active attacks, nor should they have reason to be. They may be hacked or subpoenaed after the fact.

I thought that "active" attacks is exactly what we were trying to guard against?

Presumably the hope for transparent key management would be something like the CA system used in TLS, with certain reforms (certificate transparency? Namecoin?) which make it visible when a CA has been hacked or has collaborated with a global adversary.

So there's just a dozen or so central authorities who need to handle keys with the utmost severity.

I'm baffled by that attitude (and CT, as well). So, you found out after the fact that the global adversary injected themselves in the middle of your conversation with a source. What do you do now? Move to an apartment in Russia?

Also the things that break transparently-keyed systems do so repeatedly. That's what transparent keying means: it's mediated by machines, and factored the slow, clumsy, human interactions out. CT? Audit logs? It's like Lucy and Charlie Brown with the football, except Lucy is hooked up to a for() loop.

  So, you found out after the fact that the 
  global adversary injected themselves in 
  the middle of your conversation with a 
  source. What do you do now?

If you could reliably detect a CA issuing MITM certs to the global adversary, and if some unstoppable mechanism would respond to such detections by promptly dropping the CA's cert from clients' trust roots, and if being dropped from the trust roots put the CA out of business, then it would be extremely difficult to induce a CA to issue MITM certs.

What is CT in this context?

I believe it's Certificate Transparency, a Google project for globally monitoring SSL certificates.

http://www.certificate-transparency.org/

Can you (or anyone else) point me and others to a good text on properly handling keys? Thanks!

I would freaking love it if some good designer with technical knowledge, or help from technical colleagues, would create simple flowcharts of "How to use Encryption".

Each chart would be one page. It would walk a user through one step of using a PGP / GPG. It would include links to in-depth reading.

The final sheet would be walking through common mistakes that users make.

This is one of the things I'd pay for if I had FU money. I'm sort of tempted to kickstart the idea.

It's not doable, because there are major unsolved problems. Protection of a private key, for example.

The only outcome of such a chart would be reams of people utterly vulnerable and thinking that they are not.

If you constrain the environment, e.g. "How to use SSL certificates in Chrome on Mac OS X Lion" then there might be a chance that could fit on one page in an easy to understand format.

> Protection of a private key, for example.

I have a master key that was created offline, and use a subkey on a usb smart token. It works good but it was a bitch to set up. Apparently Qubes OS has a hardware-virtualized PGP container for protecting private keys, but that's not a viable solution right now.

The offline masterkey stored on an encrypted medium is the approach that makes most sense. This[1] guide is pretty decent, and somewhere on the Debian wiki is essentially the same information (but less nicely presented).

The OP's complaints boil down to two IMO: 1) poor UX; 2) trust is difficult to manage.

1) Seems solvable to me again with subkeys for encryption and signing (which I believe are created by default for GPG2.0 anyway).

2) Asking technology to solve the problem which only each individual can answer ("do I trust this person to be evaluate other people's identities as carefully as me?") is not doable.

The example of someone getting a journalist's pubkey and being stung by the (fixed) bug whereby the wrong key may be imported is again letting the user off the hook. If someone is not actually using GnuPG's abilities to examine the WoT and see who has signed the journalist's key etc then it's an example of magical thinking with "encryption" replacing any other nostrum.

I don't believe that problem can be solved with technology.

1. https://alexcabal.com/creating-the-perfect-gpg-keypair/

See the [GNU Privacy Handbook](https://www.gnupg.org/gph/en/manual.html).

That's probably because like most people, you don't really need to have a completely secure communications channel with your wife.

All security decisions boil down to some calculus of risk, impact and cost. The most sensitive conversations that my wife and I typically have remotely aren't ones that justify the cost (both in terms of hassle and $) of carrying a secure device around.

Personally, if I were in a situation where I was remote and my physical safety or livelihood could be compromised from an email, my wife and I would probably suck it up and run around with secured netbooks or something. In my case, I don't see that risk/impact calculation adding up to requiring PGP.

Someone else might need to have a secure communication channel with his wife. I never read the comment as "I can't communicate securely with my wife", more "My wife is not in the set of people with which anyone can communicate securely" (because secure key management is hard).

That's fine. Just don't expect to do it transparently with your iPhone.

See, for example, "De-Anonymizing alt.anonymous.messages" for an example of people doing crypto -including PGP- wrong.