From: mskala@langara.csc.UVic.CA
Date: Tue, 21 Oct 1997 06:06:38 +0800
To: cypherpunks@toad.com
Subject: SMTP Encryption Extension
Message-ID: <Pine.A41.3.96.971020142541.11532A-100000@langara.csc.UVic.CA>
MIME-Version: 1.0
Content-Type: text/plain



Lots of people want to encrypt network traffic in large quantities to
deter wiretapping, raise awareness, and so on.  The usual approach seems
to be to encrypt at a very low level, on individual network links.
Unfortunately, those plans aren't moving very fast, partly because they
require the involvement of people in positions of power at both ends of
any given link.  If I'm the sysadmin of a major ISP, I've got more
important things to worry about than trying to coordinate with my
counterpart at the other end of a high-speed link that is ALREADY WORKING
FINE, and trying to change the protocol.

Well, what are we really concerned about?  Not Web traffic - although your
web surfing history is private information, the data itself is by nature
public and encrypting it is kinda pointless.  The same kind of argument
applies to news.  What we're really concerned about w.r.t. wiretapping is
electronic mail.

So why not extend SMTP to do strong encryption?  When your SMTP mailer
connects to another mailer with the encryption extension, they exchange
public keys, use those to exchange a session key, and encrypt their
traffic.  When your smart mailer connects to a stupid mailer, they just
speak normal SMTP.

This is a win even without any special key management: even if I can't
verify that the identity of the remote SMTP server is correct, I'm still
protected from passive attacks if I know that only the remote server
(whoever that is) can read the traffic.  If we're concerned about
government surveillance of the populace, passive wiretaps are by far the
most significant threat.

This has the advantage that it only requires support from the admins of
the computers that send and receive email; your ISP doesn't have to
cooperate.  Also, it doesn't require cooperation between the two ends of a
connection: I can put the crypto extension onto my system without worrying
about whether any other specific person will cooperate.  Finally, it's got
good subversive potential; the benefits of having the extension increase
exponentially as more people have it.

Just imagine if we could get a major Linux distribution to install it by
default.  Wham!  All of a sudden, whenever any two boxes running that
distribution connect to each other, they automatically do it securely.

The ideal way to implement this would be as a patch to sendmail, but for
short term "proof of concept", I'm building a Perl program that will
listen on port 25, accept SMTP connections, and pass the data through to a
copy of sendmail running on some other port.  It also has a client side
which gets installed as a "mailer" under sendmail, replacing sendmail's
built-in IPC mailer.  When two copies of sendmail so equipped connect to
each other, they automatically encrypt.

I've already got code for a program I call "blackpony", that implements
the basic protocol using RSA and Blowfish (extensible to others).  It also
supports ROTn, in order to provide a cryptosystem people can do in their
heads while manually testing the program.  I haven't finished testing the
integration between it and sendmail, and I'd like to document the protocol
more thoroughly, but it does work, and it transparently interoperates with
ordinary sendmail.  I expect to have it in a form I'll be willing to show
people, within the week.  If anyone would like a copy or has any comments
or suggestions, please let me know.  Perl5 is required, as is the Cryptix
security library available at http://www.systemics.com/software/.  At
present the Linux /dev/urandom device (or something like it) is required,
but I intend to make that optional eventually. 

Deploy and enjoy...