A Preposterous Preponderance of Prominent PGP Ponderings

[big_bad_al]

Let me start this out by killing any speculation this post might raise: no, this has nothing to do with work. I am not doing anything related to GMail right now, nor do I know anyone working on GMail. Anything I write here should in no way be affiliated with Google.

Having said that, here are my thoughts: after talking to sneaselcouth about it recently, I've

Comments

[inferno0069]

One issue would be that you're now planning to store the private key on Gmail's server, and send the password over the 'net to Gmail. This first requires people to trust Google quite a bit, and then a secure connection (probably easy/already there). Then, unfortunately, users will clamor for the password to be cached. Gmail could probably succeed at caching it for the lesser of the session or N minutes, but if others picked this up they'd be less secure. I am all for its support, but I'd expect tension as more people adopt its use

[big_bad_al]

I've always been a little hazy about ASCII-armored keys. Is that just the output of 'gpg --armor --export *myKeyID*'? Now that I have yours, what do I do with it

[inferno0069]

I think you can just import it with 'cat keyfile | gpg --import', and probably then refresh it from the keyservers. Alternately, it can probably be found on the servers mac mentioned with cerickso@cs.hmc.edu. (I probably have an st.hmc.edu identity I should remove now.)

[macdaddyfrosh]

This would, of course, be wonderful, but a good global PKI is going to be really, really hard.

On the other hand, more of what you're talking about has been done than you think: there are already large repositories of keys (they're called, obviously enough, "keyservers", and pgp.mit.edu is probably the best-known), and the PGP command-line clients will interface seamlessly. (My Mutt config is smart enough to recognize that a message has been signed by a key it doesn't have, go retrieve that key, then re-try verifying the message, for example)

I think this will catch on as a side-effect of cryptography in instant messages: people will discover that using OTR plugins is easy, and then they'll wonder "why can't I do that in e-mail?"

Assuming you've got a keyserver configured (see the GPG howto...), signing a key goes like this:

% gpg --recv-keys # (I _think_ it's recv-keys)
% gpg --fingerprint
(make sure it matches...)
% gpg --sign-key
% gpg --send-key
Occasionally, remember to do % gpg --refresh-keys to see if anybody else has

[macdaddyfrosh]

Blast, LJ damaged some of my formatting. All of those commands take another parameter, which identifies which key(s) you are operating on. It wants some unique identifier, as defined above.

[big_bad_al]

I'm familiar with keyservers for storing public keys, but I'm talking about keeping the private key of every webmail user on the server that hosts the webmail. I'm not sure how different that would be, but I imagine something will need to be tweaked a bit.

Your comment raises a few questions for me: why do you think email cryptography will catch on after IM cryptography? I've always thought it would be the other way around. There are easily understandable reasons for getting email cryptography. Why would most people want to encrypt their IMs? Also, why do you think that getting a good global PKI would be so hard? I don't think it would be any harder than getting a hydrogen economy, which has already started to happen (albeit very slowly). Once we get a critical mass of people using it, I expect others will want to join in.