Path: utzoo!utgpu!water!watmath!clyde!att!alberta!ncc!lyndon
From: lyndon@ncc.Nexus.CA (Lyndon Nerenberg)
Newsgroups: comp.mail.elm
Subject: Re: Mail Encypherment
Summary: Wrong layer, right time
Message-ID: <10319@ncc.Nexus.CA>
Date: 7 Jul 88 00:01:02 GMT
References: <2085@hplabsz.HPL.HP.COM>
Reply-To: lyndon@ncc.nexus.ca (Lyndon Nerenberg)
Organization: Nexus Computing Inc.
Lines: 47

In article <2085@hplabsz.HPL.HP.COM> taylor@hpdstma.hp.com (Dave Taylor) writes:
 
[ I've re-arranged the paragraphs a bit to make this flow a bit
   better. See the original to get the full context. ]

>That is, if someone *really* wants to read your email, either
>along the way or once it's arrived, then they *can* do so.  The
>`cryptbreakers workbench' package is widely available, for
>example, and it is reputed to be able to break the crypt(1)
>function that is shipped with Unix (crypt is a partial implementation
>of the DES encryption algorithm, using a shorted [simpler] 52 bit
>key rather than the original [as designed at IBM] 64 bit key.  BTW:
 
>Anyway, the point is that I think the real goal of any sort of
>encypherment mechanism is to stop the unauthorized, lazy
>browsing of spooled mail flowing from machine to machine.  There
>are people out there who will, when bored, type commands like
>"more /usr/spool/mqueue/df*" in the hopes of finding something
>interesting...

If you make it easily accesable I'm sure someone might be tempted.
Making the various spool directories unreadable by "others" will
provide just as much (if not more) security as a simple encypherment.
The only people left with access after this are the system
administrators themselves. It's highly likely they won't have
any trouble decyphering the messages...
 
>Basically, I don't believe that there are any really robust
>encypherment systems that are quick and painless to use.  That's
>okay, though, because the real reason one wants to encode mail
>is to prevent unauthorized browsing of the contents *in transit*.

... which leads me to suspect that we're dealing with something
that should be dealt with at the transport or network layer, not
in the application itself.

Verision 3.0 of smail will support batched mail. Perhaps we should
look at adding message body enCRYPTion to the BSMTP transport as
part of the batching system and get some hands on data about this?

[ Given that the decryption routines would be available to the
  system administrators, this still won't guarantee complete
  security. It will help those systems where file permissions
  in the spooling area are not (or cannot be) set correctly. ]

-- 
{alberta,pyramid,uunet}!ncc!lyndon  lyndon@Nexus.CA