On Mon, 2 May 1994, Harris, Richard L. wrote:
My first question though is if you encrypt with the public key and the mail
system, hopefully, doesn't have the secret key around all of the time, how
do you get the system to do anything with the mail unless the user is
on-line and supplies access to the key?
There's two cases where encryption comes into the picture (there could be
others I haven't identified yet):
(a) Encrypting an incoming plaintext message and writing it to the user's
mailbox.
(b) Sending a plaintext message to a server in an encrypted fashion for it
to be processed and forwarded onwards.
Case (a) requires the server to keep a list of public keys for all users
on the system. Since this isn't highly protected information, it doesn't
matter if it is compromised (except for the usual certificate validation
stuff of course). Case (b) requires the clients to have a copy of the
server's public key, and for the server to somehow have its private key
embedded. There is a chance of compromise if the server system is
insecure, because either a user will need to enter a passphrase every time
a message is processed by the server, or the passphrase is entered once at
startup and the unencrypted private key is kept in the server's memory
space. Not exactly the most secure system, but could be made more secure
with smart cards and the like.
Just to give a little more information on the system I'm thinking of: I
envisage that when a user submits a message, it will be encrypted with
the server's public key and transmitted to the server. The server will
decrypt it, look up the user's public key (if any), encrypt it, and write
it to the user's mailbox. In my DOS LAN based system, the messages will
be transmitted to the server in a publicly accessible directory, hence
the need for encryption of that step. This is the default behaviour. If
the user wishes to add extra encryption layers to protect themselves from
snoops on the server system, they can do so using normal PEM mechanisms.
I'm also thinking of using similar methods to encrypt UUCP mail and news
batches that are transmitted between systems. e.g. the user submits a
message to the server which is destined for a remote system. The server
decrypts it as before, and then re-encrypts it with the remote system's
public key before tossing it into the spool.
This way, the clients do not need to have full knowledge of the routing
algorithms used by the server to add the required enhancements themselves.
To them, they are submitting a plaintext message which just happens to be
automatically processed to add any privacy enhancements that the sysadmin
deems necessary. Further gadgetry such as Steve's automatic user-level
encryption could also be added to the server.
- Forwarding protected mail to a portable or other remote user agent where
either the remote host or the communications channel inbetween is insecure
or untrustworthy (,and may be only intermittently connected).
- Portable or remote hosts with user agents that share or divide mail
folders, such as duplicated inboxes, that need updating and alignment.
These could probably be handled by bolting encryption extensions onto the
POP3 and IMAP protocols, and maybe also SMTP. I don't know of any work in
this area.
- The delay (mucho processing time) needed when changing certificates on
everything stored that's analogous to decrypting/reencrypting disks or
directories when an encryption password is changed.
With a public key based system, 99% of the time it will be the passphrase
that changes which won't affect previously encrypted disks. If the key
pair changes, then only the session key header blocks on each file will
need to be changed to decrypt with the old key pair, and then encrypt with
the new key pair. Not really a PEM problem, although providing this as
an option on stored PEM messages would certainly be useful.
Cheers,
Rhys.