...and if you are going to ignore what tptacek says and try it anyway, I think it can be done a little better than the submitted product (although I only skimmed their site so I might be misunderstanding a bit).

I worked at a company that had a go at end to end email encryption around 2001. The basic idea of the submitted system looks quite similar to what we did--piggyback on top of existing email clients and their messages.

However, we did not want to require modifying the MUAs or installing plug-ins or extensions or whatever a given MUA supported for that kind of stuff. We needed to support pretty much ever MUA on Windows, and writing plug-ins for each would have been impractical (and I don't think they all supported that).

So instead of hooking in directly in the MUA, our first approach would have the user configure their MUA to use a proxy, and our software installed a local email proxy. It's been a long time so I may be mixing up some projects, but I think we later did a version where we played around with intercepting things by hooking Winsock, and another version where we used the Service Provider Interface to get in there [1].

Anyway, the first time you used the proxy it would generate a key pair for you, and then on your outgoing mail would put your public key in a header. If incoming mail had someone else's public key in the header it would import that into your keyring.

You could set it to sign your outgoing mail. I don't remember what options we have for protecting your private key. My guess is that they were weak, because as is usual when the marketing folks have too much influence, convenience trumps security.

Incoming signed mail would have the signature checked by the proxy, and it would annotate the message somehow so that the result would be visible in your email client. I don't remember if we added something to the subject, or added a status header, or added something to the body.

Encryption was similar. If the proxy saw that you were sending to some for whom it had a public key, you could set it to encrypt using that public key. (By which I mean encrypt with a symmetric cipher, and use RSA to encrypt the key...I believe we were simply using GPG).

As with signing, convenience won if it came into conflict with security, I believe (and over my objection, if I recall correctly).

From a user point of view this actually worked pretty well. As I said, we rejected the plug-in approach because it was impractical to write and maintain plug-ins for each client. However, it was practical for all the major ones (and many less major ones) to poke around in the registry or find their config file, and figure out how to programmatically edit those to change proxy settings, thus allowing our installer to find and configure all your email clients. So from the user point of view, you just installed our program, and started using email normally. After a mail and answer between two people who both used it, subsequent messages between them would be encrypted and signed.

Of course there was still the issue that this just told you that the subsequent messages were to someone who had access to the keys of the person you initially exchanged messages with at that address--it doesn't verity that they are really who you think they are. I don't remember if we had a way to go outside the system to verify someone's public key and tell the system you have done so.

As I write this, I'm now starting to think it wasn't just a simple proxy that just passed requests through, occasionally diddling the headers and the body. I think it was actually an IMAP server that stored messages itself. I think that was so it could keep copies of the encrypted incoming messages itself, and then the email clients could be configured not to store local copies of mail. That way the mail would only be decrypted when you are actually reading it in the email client.

Anyway, I think that this could have been made quite reasonable at the time (around 2001). Email has gotten quite a bit more complicated since then. Most people then only used their email from a single computer. Now they use it from 2 or 3 devices, or more, often each running a different operating system. There's no good place controlled by the user that you can put the proxy that is accessible to all of their clients, and so you really need to provide this as a service that includes a server to handle the email...but then how do you let people keep using their existing email address? I supposed you could do an ugly hack like configuring their email clients to all forward incoming mail to the service's server, which decrypts it and sends it back...yuck.

At this point it seems clear that you should just use some dedicated secure messaging app for your secrets, and keep email like it is now, as tptacek said.

In short, I think this is an idea whose time has come...and gone.

[1] I may be mixing up different projects because we had this completely insane contract at the time with one of the biggest distributors of Windows utility software in Japan to provide him with something like 12 new products a year, and new versions of 6 prior products a year, which led to a couple years where everything is largely a blur of projects that mix together in my mind.