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