🚀 go-pugleaf

I got a number of replies to my query, thanks everyone.. however

----
From cme@ellisun.sw.stratus.com Tue Nov 10 20:50 HST 1992
Subject: Re:  is this bad?

You haven't described it well enough.

For example, where does the  DES iteration get its key?


I'd suggest you write a simple program to give your algorithm and
post it that way.
That's a lot clearer -- less likely to be ambiguous.
----

when few replies mentioned I should just use the CBC mode of DES
it became apparent to myself that I hadn't stated my goals well
enought either...


goal:  an encryption scheme that gives me the strength of DES
along with the ability to send single characters one at a time.
Also it would be nice if the scheme lended itself well to
sending 7-bit characters in only 7 bits.

my scheme:
both ends agree upon a private key K 
one side sends the other side an initial 8 bytes of random data
to be used as the initial 'previous plaintext'.

to send bytes of the plaintext the sender encrypts
the previous 8 bytes with key K and uses the resulting 8 bytes 
1 at a time to xor with the plaintext. After these 8 bytes
of 'pad' are used up, 8 more bytes are generated from the
previous plaintext.

example:
previous bytes where 'hello th'
which encrypt as  ('hello th')K = 'abcdefgh'
now to send the next arriving byte 'e' i send  'a' xor 'e'
when I get the next byte 'r' I send  'r' xor 'b' and so on.
after sending the next 8 bytes 'ere how ' I encrypt them
('ere how ')K = 'blahblah'  and use those as pad.

at the other end,  the last 8 bytes of plaintext it had received
is also 'hello th'.  The receiver also computes ('hello th')K
and gets the same pad.  It uses the pad to xor the incomming
stream to recover the new plaintext 'ere how '.  It can
then compute ('ere how ')K and use those to decode the next
8 bytes.


This scheme allows one to send signle characters 1 at a time
instead of waiting for 8.  If this is being used in real
time I can send 'e' right away without waiting for
'ere how ' to be available to me.  If DES is used in its
normal mode of operation I would be required to either
wait for 8 bytes of plaintext to be available or to time
out every once in a while,  pad what I do have to fill
out 8 bytes, and send the data.  The first is unacceptable
for real time traffic and the second adds extra characters
to the stream degrading performance and adding complexity.
The extra characters are sent usually at times when nothing
else is going to be sent (if stream isnt sharing space on
a multiplexed link) so that isnt so much a problem.


 
I hope this is a little bit more clear than last time.