[SLL] E-mail encryption

[Mark Foster]

Dave Pfaltzgraff wrote:
> This one is off the wall, but how is encrypted e-mail handled?
>   
There are two main types: transport and payload encryption.
Transport encryption commonly called STARTTLS... this is used between 
SMTP (MTA) servers.
Transport encryption can also be used between clients and IMAPS/POP3S 
servers, usually direct SSL/TLS.

Then there's payload encryption, which is either PGP (aka openpgp, gpg 
and gnupg) or S/MIME.
There are others but they have fallen out of use AFAIK. Even a zip file 
attachment could be encrypted.
But the normal case is the headers are plain text and the message body 
is encrypted.

All of the above except for the zip method can be described asymmetric 
encryption so use public/private key pairs. That means keys are signed 
and (un)trusted. Sometimes these signed keys are called certificates.
It means messages can be verified for authenticity too - aka digital 
signatures.
PGP/GPG is more of the community standard and S/MIME used more in 
enterprise who have the $. S/MIME certitificates branch back to a (one 
or more) public certificate authorities (CAs) where as PGP keys are 
multiply-signed thus building a "web of trust."

> I am familiar enough with it to know about the public/private keys and
> sometimes note the public keys at the bottom of some of the messages on
> this list.
>
> Is the encryption somehow handled by the e-mail client? Or, is it that the
> message is encrypted and then sent as an attachement which must be
> detached and then decrypted?
>   
Except for STARTTLS that is correct, the client (outlook, thunderbird or 
what-have-you) is responsible for doing the encryption/decryption etc. I 
know thunderbird relies on enigma which has hooks into gnupg.

As a means of security STARTTLS is problematic as it is unenforcable in 
the wild, er on the Net.
I think all of the schemes pretty much suck, as there is lack of 
widespread adoption among users and support for revocation schemes is 
spotty. Also the fact that the headers aren't encrypted leaves open the 
possibility of certain attack vectors.

-- 
Some days it's just not worth chewing through the restraints...
Mark D. Foster, CISSP <mark at foster.cc>  http://mark.foster.cc/