taylor@hpdstma.hp.com (Dave Taylor) (07/07/88)
Paul Vixie and I last night had a chance to chat about security
and electronic mail, and along the way I decided that it would be
perhaps useful for the current discussion in this group for me to
expound on my motivations for adding the "[encode]/[clear]" feature
to the Elm Mail System.
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*.
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:
I once talked to Dennis Ritchie about whether the simpler
implementation was a `plot by the NSA' as widely believed and
he laughed...)
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...
The best algorithm I came up with for this purpose, actually,
was a shifting rotation scheme; instead of the +13 rotation
cipher (aka rot13) the cipher stepped from +1 to +25 then
down to +1, then down to -25 then back. (a very simple
mathematical progression, obviously). The criteria for
this were simple; fast, simple, and portable.
I *do* think that it would be nice to leave the option of
alternating paragraphs of hidden text and clear text too.
Anyway, back into my corner now... ;-)
-- Dave Taylor
ps: You will note I do not use "encryption" in this article. When
last in France working I was told by them, quite reasonably,
that encryption had "crypt" as a basis, and in French that
isn't such a lovely thought, so 'encypherment' is the more
widely accepted international word to use in this context.lyndon@ncc.Nexus.CA (Lyndon Nerenberg) (07/07/88)
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
zeeff@b-tech.UUCP (Jon Zeeff) (07/07/88)
> >>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*. Actually, I'd like to prevent unauthorized browsing *anywhere*. I do use systems where I don't like the idea of someone with root looking through my mailbox. Don't do encryption at the transport layer. What would you use - a fixed encryption key? > >[ Given that the decryption routines would be available to the > system administrators, this still won't guarantee complete > security. > They would end up being available to everyone and so won't guarantee any security. Leave it out of the transport layer so that the system administrators don't have the key. -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu
peter@ficc.UUCP (Peter da Silva) (07/08/88)
Why not just provide a standard hook for filtering messages before
transmission, and again before displaying? Then you can hook crypt,
or any other program, right in.
--
-- `-_-' Peter (have you hugged your wolf today) da Silva.
-- U Ferranti International Controls Corporation.
-- Phone: 713-274-5180. CI$: 70216,1076. ICBM: 29 37 N / 95 36 W.
-- UUCP: {uunet,academ!uhnix1,bellcore!tness1}!sugar!ficc!peter.jules@zen.co.uk (Julian Perry) (07/18/88)
In article <2085@hplabsz.HPL.HP.COM> taylor@hpdstma.hp.com (Dave Taylor) writes: >..... >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: >I once talked to Dennis Ritchie about whether the simpler >implementation was a `plot by the NSA' as widely believed and >he laughed...) About the crypt-breakers workbench ...... I played with this little tool for a few days and had some fun with it. It seems to work fairly well but it relies on some knowledge of what is in the text being decrypted at least that's as far as I got with it. The user supplies a list of words and it tries to find them and you slowly build up the complete text. This method of decryption can easily be foiled by compressing (using compress, pack, compact or any other similar routine) the text before encrypting it. I'm sure this does not make it impossible to decrypt but it makes it one hell of a lot harder and as far as I know well beyond the bounds of the casual hacker - even if s/he does have the crypt-breakers workbench. Why not send encrypted mail as: compress - crypt - uuencode >Dave Taylor Jules -- IN-REAL-LIFE: Julian Perry E-MAIL: jules@zen.co.uk || ...!uunet!mcvax!ukc!zen.co.uk!jules PHONE: +44 532 489048 ext 217 ADDRESS: Zengrange Limited, Greenfield Road, Leeds, England, LS9 8DB