5 ms·

I agree with this but why not take it a step further? We're hackers, working on tools/applications that facilitate the transfer of information - why don't we im

by _s 13y ago

I agree with this but why not take it a step further? We're hackers, working on tools/applications that facilitate the transfer of information - why don't we implement encryption from the get-go? There wouldn't be a need to 'popularize' something exists by default. GnuPG/PGP are fairly trivial to implement; here's some apps that are ripe for production: - Messaging application that exchanges public keys on first contact, and henceforth every back and forth message is encrypted/decrypted without the user ever knowing - An email client that works on the same basis as the messaging application; the user doesn't need to know - they just wanted their messages sent securely. ^^ Thats probably 90% of the uses cases for the average joe covered.

rlpb 13y ago
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.
- krenoten 13y ago
  Cypherpunks have already created a solution, http://mixmaster.sourceforge.net/ http://mixmaster.sourceforge.net/ and similar remailers, but similar technology needs to be incorporated into easIEST to use tools.
- tripzilch 13y ago
  > 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 13y ago
    > 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.

by _s 13y ago

rlpb 13y ago

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.

krenoten 13y ago
Cypherpunks have already created a solution, http://mixmaster.sourceforge.net/ http://mixmaster.sourceforge.net/ and similar remailers, but similar technology needs to be incorporated into easIEST to use tools.
tripzilch 13y ago
> 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 13y ago
  > 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.