[Cryptography] Avoiding PGP

[Jerry Leichter]

> The problem isn't that the programmers aren't able to make the plugins
> behave the way they should; the problem is that a thousand people who
> assume with no evidence or consideration whatsoever that they know
> exactly how the plugins "should" behave....  I'd be perfectly happy if there were never any confusion of encrypted mail with unencrypted mail - in fact I'd prefer to be using entirely different applications ... [with the "secure" application]  simply had no access whatsoever to addresses or contacts or header information pertaining to messages other than the plain-vanilla SMTP
> stuff it knows how to handle.
Hmm.  So now you've contributed *your* idea of how this "should" behave.  :-)

> Nothing that can be configured to run an executable attachment, or which
> loads assets over the network when someone reads messages (like graphics
> in "html mail"), or which by default launches a browser for clickable
> URLs, should also be handling messages, addresses, or keys intended to
> remain private.
And yet most mail today uses some of those features, so by leaving them all out you're limiting the scope of your "secure mailer" to a rather small set of people.  Not that the problem isn't real!

The takeaway from your comment, though:  If there's anything you *must* have before you implement a security-relevant piece of code, it's a careful definition of *what security actually means for that piece of code*.  And it appears, that for "secure email", we really don't.  What we have is essentially "I want it to do everything regular email does - but, you know, securely".  The fact that pretty much all the implementations we have out there are plugins or extensions to existing mail programs makes this "security definition" very hard to improve upon.

It's interesting that secure messaging has developed very differently.  There are formal definitions of what it means for a messaging application to be secure, and as far as I know all the secure messaging apps were written ab initio - no one tried to graft security on top of existing apps or even existing messaging protocols.

Now, there are multiple real-world reasons for this distinction, ranging from what appears to be a more tractable problem (no long-term storage, no need to support things like search) to history (email standards have been there for decades and there's an immense "open" installed based; previous messaging applications, while they followed some standards, were often proprietary and incompatible, so the notion of a new messaging app that couldn't interact with existing ones didn't bother people much).

But ... the evidence of many years of experience is that a usable, useful, secure (with an acceptable definition) encrypted email system that would be widely adopted is highly unlikely to *ever* emerge.

Well, maybe during The Year of Linux on the Desktop.  :-)

                                                        -- Jerry