Slashdot Mirror
Elegant Email Encryption for Everyone?
"The problem is that in order to use public key encyrption, both parties (sender and receiver) must be using something like PGP. Most of the people I correspond with consider encryption either too complicated or too bothersom to use... with its key generation, signing, encrypting, decrypting, exchanging keys and such. There are always non-public-key systems, but that usually requires both parties to use the exact same software at each end. And then there is the issue of everyone using different operating systems (Windows, Solaris, Linux, etc.). And then there is cost involved for any commerical packages. Of course, there is always HushMail and its ilk, but I don't want to be tied to a web-based system.
For people like me and you, encryption is easy. But that's not the case for everyone else in the world. Why is it still difficult? And what is the best solution to date?"
Compress it. Simple ZIP compression will defeat packet-sniffers looking for keywords or credit card numbers. And the braindead password protection in PK(and Win?)Zip will stop people going the extra step of simply opening attachments. Unzip software is pretty ubiquitous nowadays.
PGPDesktop and PGPFreeware for Windows do indeed hook into, at least, Outlook and Eudora. They make encryption and decription transparent - you have to click the little "Encrypt" thinggie on the toolbar and you're done. Unless it can't find the right keys, and then it'll ask you to choose them.
--
In the land of the blind, the one-eyed man is kinky.
Currently, a PGP plugin interface is being added to Mozilla. It should show up in the next release or the one after that. It will allow PGP to be used almost transparently.
Hopefully, this will bring PGP a little closer to the mainstream.
End-to-end encryption requires the cooperation of both parties. If they think it's important, they'll figure out a way to make it work. If they don't think it's important, you can't cram it down their throat.
:-)
However, you aren't completely powerless. My system runs qmail patched to support STARTTLS - any outbound mail that connects to another site that supports STARTTLS will be encrypted. I'm twisting the arm of my ISP to do the same thing for my inbound mail. (My inbound and outbound mail follow separate paths.)
I believe that the latest versions of most MTAs support STARTTLS now - either directly or via patches. Personally, I consider this upgrade equivalent to a "serious security bug fix," but your package maintainers may disagree.
This is NOT a complete solution - mail is still unencrypted on the disk, and according to a recent, and totally unfathomable, court ruling once mail is backed up to tape by your ISP it loses all ECPA protection. But it *will* stop packet sniffers, traffic analysis (at the user level), and with a bit more work also allows you to provide host-based authentication in addition to encryption.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
The advantage of putting encryption into your MTA is that the envelope is encrypted, not just the body. Plus, client software doesn't have to be modified.
If you are really paranoid, then you of course would want a combination of encrypted SMTP with a PGP encrypted message body, 'cause that provides end-to-end encryption combined with an encrypted envelope while the email is in transit.
I have written a truly remarkable program which this sig is too small to contain.
Quite apart from the question of whether the government's reading your email, the point remains: some messages are private-- just as when you write someone a message using the post, you put it in an envelope so that it can't be read in transit.
Don't confuse privacy with secrecy. A CS 101 textbook on object-oriented design I once read made the distinction memorably: "What you do in the bathroom isn't secret, but it's private."
my plan
GROGGS: alive and well and living in
What about sending encrypted mail as html, surounded by a neologist tag:
t ed_text>
<encrypted>
<a href=public.webased.decoder.org/cgi/decode?encryp
click here to decode</a>
</encrypted>
Encrypted-tag aware mail readers would know to ignore the <a>-tag and to directly decode the target address.
Up side: this reaches html-enabled maillers and all updated maillers. Down side: it leaves rmail and old pine users either executing outragious copy-yank operations or running for updates.
Another up side not to be left aside: it would becode the first actualy useful piece of html-based mail.
-
This post was compiled with `% gec -O`. email me if you need the sources
One problem is that, currently, PGP keys require a password in order to use them for signing or encrypting email. People don't consider having to type in a password "easy to use." However, if you create a MUA that remembers the password, you've reduced the security, because now whoever can get at the machine can get at the key. This is the same old tradeoff between security and ease-of-use.
Also, if I understand it correctly, you can really only send an encrypted message to one person at a time, because you're encrypting it with their public key (so that their private key decrypts it). So PGP is not really a solution for, say, mailing lists.
So, even though Mutt has great GNUPG support, and so is relatively easy to use for someone like me, I can't really make use of it too terribly often, except for signing my mail.
What would help a great deal is if the mail could be encrypted between the mail servers, thus limiting snooping to localhost exploits. I know that there are protocols available, but with so many people out there running old, insecure, years old versions of Sendmail, I am rather pessimistic about the rate at which we could get people to switch over (much like IPv6, which will help network security in general with its support for IPSEC). Does anyone know of an MTA-to-MTA encryption protocol which satisfies any (or all!) of these:
1. Mail server agnostic
2. Falls back to cleartext if encryption isn't supported at the other end
2a. Gives a warning on this fallback.
3. Uses existing algorithms, rather than trying to invent a new one, and can intelligently support more than one at once (sort of like SSH with IDEA and Blowfish).
Sotto la panca, la capra crepa
WMBC freeform/independent online radio.
Yeah it sucks. More people should use software like mutt. It makes dealing with pgp-signed/encrypted messages so easy. (I hear gnus is really good too, but mutt was much easier for me to learn)
I think the best thing to do is just sign (not encrypt) all your email to your non-crypto using friends. That way they can still read your email, but they'll have to use a pgp aware mua to verify your sig. Hopefully, your friend will eventually be encouraged to use decent software to get this function. Then you're 99% of the way there and you can start exchanging encrypted emails.
Point being: Sign everything!
Ideal what we probably need, is a really good, full-featured, e-mail client with the capabilities of Communicator or Outlook Express, and PGP built-in.
As long as people have to run PGP as a separate program, and then try to hook it in with their favorite mail-reader, it will never catch on.