Path: cactus.org!milano!cs.utexas.edu!usc!apple!well!nagle
From: nagle@well.sf.ca.us (John Nagle)
Newsgroups: sci.crypt

Subject: Re: Braided streams (The Leichter Side)
Message-ID: <25633@well.sf.ca.us>
Date: 24 Jun 91 01:45:54 GMT
References: <1991Jun23.042445.9676@elevia.UUCP>
Lines: 33


    Now, wait.  The "key" to this system is really what's referred to
as the original "seed".  The receiver and sender share it, and if you
can figure out what it is, you can decrypt all that follows.  The object
of an attacker is to discover the seed.  

    If you transmit any volume of data much longer than the seed, in
theory exhaustive search will work.  Presumably the seed is too long for
exhaustive search.  So we must find some more efficient way to discover
the seed.

    Given a known plaintext at the beginning of the message (some message
header, perhaps), only the first few bits of the seed actually affect
the encryption of the first few bits of the message(s) being sent.
So it may be possible to work on the first few bits of the seed
exhaustively.  Having found the first few bytes of the seed (by exhaustive
search, if necessary, but there are probably better ways) the process
can be continued forward through the seed.  Once the entire seed has been
found, you decrypt as if you were the regular receiver, of course.

    Actually, the "braiding" of multiple messages may make the job
easier.  A known plaintext on any subchannel (or even one in a language
with some redundancy) provides a point of attack.

    Sending a few thousand random bits of filler before any real data
goes through would strengthen the system, but that was not part of
the original proposal.

    I'm not really familiar with this field; those who are may be able
to devise better attacks.  But this doesn't look like a strong system
at first glance.

						John Nagle