NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/sci/crypt/2801

Internet Message Format | 1992-07-31 | 1.8 KB

Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!ns-mx!pyrite.cs.uiowa.edu
From: [e-mail] (Douglas W. Jones,201H MLH,3193350740,3193382879)
Newsgroups: sci.crypt
Subject: Re: Padded Data
Message-ID: <[e-mail]>
Date: 31 Jul 92 20:02:38 GMT
References: <[e-mail]>
Sender: [e-mail]
Lines: 29

From article <[e-mail]>,
by [e-mail] (Greg Earl Webb):
>
> I've seen some interesting posts here recently, but I have yet to
> see the topic of padding data with garbage.

In my splay-tree based data compression code (C source available on
request), , the compressor adds a random prefix to the data when asked
to encrypt as well as compress.

In this case, encryption is done by adjusting the initial state of the
adaptive compression and expansion data structures by smashing the text
of the key through them.  I threw in the random padding because so many
documents tend to start with predictable stuff such as "From:" and I
figured that even a slight random addition to the source text would
significantly complicate the effort needed to make a known plaintext
attack.

In fact, had I thrown in a random byte or two every few tens of
characters, I'd have done even better because that would significantly
complicate controlled plaintext attacks, to which I know my splay-tree
based code is vulnerable (immediately after compressing the sequence
aaaaaaaa on an 8 bit alphabet, the code a is known, independant of the
starting state of the model).  An occasional random number thrown into
the stream of compressed data will prevent a longer sequence from
putting the entire compression data structure into a known state.

                Doug Jones
                [e-mail]