[Cryptography] Other obvious issues being ignored?

Jerry Leichter leichter at lrw.com
Wed Oct 21 07:18:33 EDT 2015


>> I disagree that there is no good reason.  If you’re trying to go back
>> through your records to find a particular piece of correspondence,
>> having unencrypted Subject lines can come in awfully handy.
> 
> Irrelevant.  See below.
> 
>> Search is an essential part of today’s workflows, but
> 
> Irrelevant twice more.
> 
> When I am searching email, I very often want to do a full-text
> search.  So I need to decrypt the entire message anyway.  As 
> the intended recipient, I can do that.  Also if I want to
> selectively decrypt some of the headers, I can do that.
Let's distinguish "reason" from "good reason".  The *reason* PGP left the Subject line in plaintext is to support server-side search.  If you want to access your mail on an unmodified server, and are not in a position to store a local copy, search has to be done by the server; bringing messages over one at a time to be searched was, not so long ago, too slow to be useful.  While desktops and laptops today have no problem keeping all your mail locally, we've moved on to phones which also have limited resources.

In the case of the Subject line, the sender can of course put anything he wants.  Knowing it won't be encrypted, he can simply leave it empty.  Similarly, the From line could also be set arbitrarily; as we know, it's completely insecure, a fact which the sender could use to his advantage.

Other header lines are much more problematic.  The Date line you see was added *by the receiving server* when the message arrived.  Nothing to encrypt here.  The To line is part of the envelope information and had to be in the clear as the message was transmitted or it could not have been delivered.  Various routing messages - ReceivedBy and such - were added in transit and so are outside the PGP envelope (and are rarely searched on anyway, though a full-text search will typically see them).

As we've discussed here previously, SMTP mail is inherently not securable.  From the way the recipient is found (through an MX record which can't be bound in any secure way to the sender's intent) to all the metadata tacked on as the message travels, usually by intermediaries outside the control of either the sender or the receiver, the design of the basic transport protocols is inherently insecure.  And if you need to support standard mail servers as well - pretty much required if you want to fit into the existing ecosystem rather than trying to build a whole new one from scratch - well, you're going to have to live with some significant limits.

Are these "reasons" or "good reasons"?  If your goal is secure mail, and damn the existing infrastructure, then these are "reasons" or even "excuses".  If your goal is to do the best you can while leveraging what's already out there, these are "good reasons".
                                                        -- Jerry



More information about the cryptography mailing list