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