4 ms·

The problem I've had is not so much explaining what PGP is, or why to use it. It's the software. Sending an encrypted or signed message to someone who doesn't

by Groxx 14y ago

The problem I've had is not so much explaining what PGP is, or why to use it. It's the software. Sending an encrypted or signed message to someone who doesn't have your keys throws all kinds of scary messages in most email clients. Maybe not a problem for us™, but a huge problem for most people who find they can't send messages to their friends without remembering to do step X for people A, B, and D, but not C or Q. And even if you explained this to them, will they remember a month down the line when their friend calls them because they think their computer got hacked? (true story. nobody reads error messages, and encryption-related ones are among the most cryptic and scary looking.) Then try convince them to keep using encryption / signatures for you, when it breaks for other people and makes sending an email more complicated, and they have to keep track of who C and Q are. Then try to convince them that, even though they have nothing to hide, encryption is still useful. Then do this all over again when they get a new computer and forget to install PGP and have already lost their entire keychain. -- The crypto is here, and yes, it has never been more accessible. The software using it is still garbage.

ComputerGuru 14y ago
It's sad because the technology to implement PGP invisibly when possible fully exists. We were planning on drafting a proposal for behind-the-scenes PGP for email but were shocked to discover it's been fully architectured, designed, and fleshed-out (RFC 2538, RFC 4398), just never implemented. EDIT: Can't reply, but anyway, DNSSEC isn't really needed. That's just icing on the cake. What matters is a DNS record that specifies either the keyserver or the actual public keys themselves. A DNS TXT record or a custom PGP record will do just fine.
- AnthonyMouse 14y ago
  Interesting...but seems to require DNSSEC, which is presumably why it hasn't been implemented (because DNSSEC hasn't been widely implemented).
- Groxx 14y ago
  for future reference, the 'reply' link is hidden for a while in deeper threads, basically to prevent people from fighting too much, too quickly :) if you click the 'link' link, you can still reply.
AnthonyMouse 14y ago
>Sending an encrypted or signed message to someone who doesn't have your keys throws all kinds of scary messages in most email clients. Seriously. The way PGP should work is: Whenever you send an email, it puts a header in the outgoing message with your public key. The header is not normally shown to the user and is ignored as unknown by non-compliant email clients. Then, whenever you send a message to anyone you've ever received an email from, you already have their public key, so your email client automatically encrypts the message before sending it, and their client decrypts any message it receives encrypted. This is obviously ignoring a whole bunch of problems. What happens if your public key changes? What happens if the attacker sends an email from your address to the user? (Presumably in both cases the recipient will get a message complaining that the key has changed, and DKIM and the fact that your email server authenticates you will help with the second.) But here's the thing: Those problems don't happen normally. The average user doesn't encounter them in the first six months of using the software. They just install a client that supports the protocol and automatically get encryption for messages exchanged with anyone else using a supported client, without having to do anything special. I think this is one of those "the perfect is the enemy of the good" scenarios. The people who want encrypted email want it to be secure against the NSA coordinating with AT&T and your email provider. Which would be great, if it didn't make the UX so terrible that no one uses it and causes everyone to default to no encryption. Do the above and you still have good security if you verify public key fingerprints manually, but it makes the process of encrypting your email as simple as installing the software, and if you don't verify keys then you're still safer against a large variety of attacks than the primary alternative of not using any encryption at all.
- dllthomas 14y ago
  I somewhat agree with the "perfect is the enemy of the good" issue here, and would love to see encryption more broadly employed for person-to-person communications, and think your plan is pretty reasonable. That said, I'm still somewhat worried about MITM in the scenarios you describe above - should probably expose "you haven't verified this sender, it could be spoofed" somewhere, but somewhere icon/color-y rather than scary-error-message-y. Details, though...
- kbenson 14y ago

by Groxx 14y ago

ComputerGuru 14y ago

It's sad because the technology to implement PGP invisibly when possible fully exists. We were planning on drafting a proposal for behind-the-scenes PGP for email but were shocked to discover it's been fully architectured, designed, and fleshed-out (RFC 2538, RFC 4398), just never implemented. EDIT: Can't reply, but anyway, DNSSEC isn't really needed. That's just icing on the cake. What matters is a DNS record that specifies either the keyserver or the actual public keys themselves. A DNS TXT record or a custom PGP record will do just fine.

AnthonyMouse 14y ago
Interesting...but seems to require DNSSEC, which is presumably why it hasn't been implemented (because DNSSEC hasn't been widely implemented).
Groxx 14y ago
for future reference, the 'reply' link is hidden for a while in deeper threads, basically to prevent people from fighting too much, too quickly :) if you click the 'link' link, you can still reply.

AnthonyMouse 14y ago

>Sending an encrypted or signed message to someone who doesn't have your keys throws all kinds of scary messages in most email clients. Seriously. The way PGP should work is: Whenever you send an email, it puts a header in the outgoing message with your public key. The header is not normally shown to the user and is ignored as unknown by non-compliant email clients. Then, whenever you send a message to anyone you've ever received an email from, you already have their public key, so your email client automatically encrypts the message before sending it, and their client decrypts any message it receives encrypted. This is obviously ignoring a whole bunch of problems. What happens if your public key changes? What happens if the attacker sends an email from your address to the user? (Presumably in both cases the recipient will get a message complaining that the key has changed, and DKIM and the fact that your email server authenticates you will help with the second.) But here's the thing: Those problems don't happen normally. The average user doesn't encounter them in the first six months of using the software. They just install a client that supports the protocol and automatically get encryption for messages exchanged with anyone else using a supported client, without having to do anything special. I think this is one of those "the perfect is the enemy of the good" scenarios. The people who want encrypted email want it to be secure against the NSA coordinating with AT&T and your email provider. Which would be great, if it didn't make the UX so terrible that no one uses it and causes everyone to default to no encryption. Do the above and you still have good security if you verify public key fingerprints manually, but it makes the process of encrypting your email as simple as installing the software, and if you don't verify keys then you're still safer against a large variety of attacks than the primary alternative of not using any encryption at all.

dllthomas 14y ago
I somewhat agree with the "perfect is the enemy of the good" issue here, and would love to see encryption more broadly employed for person-to-person communications, and think your plan is pretty reasonable. That said, I'm still somewhat worried about MITM in the scenarios you describe above - should probably expose "you haven't verified this sender, it could be spoofed" somewhere, but somewhere icon/color-y rather than scary-error-message-y. Details, though...
kbenson 14y ago