NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/sci/crypt/4561

Text File | 1992-11-10 | 1.9 KB | 47 lines

Newsgroups: sci.crypt
Path: sparky!uunet!munnari.oz.au!news.hawaii.edu!wiliki.eng.hawaii.edu!newsham
From: [e-mail] (Timothy Newsham)
Subject: is this bad?
Message-ID: <[e-mail]>
Sender: [e-mail] (News Service)
Nntp-Posting-Host: wiliki.eng.hawaii.edu
Organization: University of Engineering, College of Engineering
Date: Tue, 10 Nov 1992 23:13:38 GMT
Lines: 35


I would like to have a scheme for encrypting a serial stream
of data.  I have thought of one method that might work (and
it also has some other nice qualities that make it apealing to
me).  So I put it before you to tell me why I cant possibly
use it without being cracked by every 10 year old kid who
has a calculator....

At some point in the middle of the stream there is a collection
of previous 8 bytes.   This data is encrypted with DES to form
another 8 byte block.  This block is used 1 byte at a time to
xor with the next bytes in the stream.  When this 8 byte block
is used up the previous 8 bytes of plaintext are crypted and
used to xor the next 8 bytes.  To decrypt you similarly encrypt
a block with the last 8 bytes of plaintext and use it to xor
the next incomming 8 bytes recovering the plaintext.

Advantages:  Can send 1 byte at a time , no need to collect
blocks of 8 bytes.  Next 'key' depends on previous data and
is not just the same for each block of data.  If the stream
is restricted to 7 bits of data you can simply leave off the
upper bit and everything still works (as long as the other
end also realizes that the high bit isnt used).


Disadvantages:  must have synchronization.  Any errors in
the stream will render the rest of the stream unreadable.

So, are there any negative security implications I am overlooking?
Are there any better schemes I could use that have less dis-
advantages?


thank you for any comments,  email prefered.