Path: cactus.org!milano!cs.utexas.edu!news-server.csri.toronto.edu!bonnie.
+     concordia.ca!IRO.UMontreal.CA!matrox!altitude!elevia!alain
From: alain@elevia.UUCP (W.A.Simon)
Newsgroups: sci.crypt

Subject: Re: Braid attack (erratum)
Message-ID: <1991Jun27.194618.6274@elevia.UUCP>
Date: 27 Jun 91 19:46:18 GMT
References: <1991Jun26.171120.3653@elevia.UUCP> <1991Jun26.222753.1543@agate.
+           berkeley.edu> <1991Jun27.151828.4266@elevia.UUCP>
Organization: The W.A.Simon Wild Life Fund
Lines: 32

In <1991Jun27.151828.4266@elevia.UUCP> alain@elevia.UUCP (W.A.Simon) writes:
>In <1991Jun26.222753.1543@agate.berkeley.edu> shirriff@sprite.berkeley.edu (Ken  Shirriff) writes:
>> In article <1991Jun26.171120.3653@elevia.UUCP> alain@elevia.UUCP (W.A.Simon)  writes:
>	Garbage:	1111111111111111
>	PT:		1001100101001110
>	KEY:		1101001001010011
>	Result:		1111011101011011...etc...

It should have been:

	Known PT:	1111111111111111
	Random:		1001100101001110
	KEY:		0110001001010011 (1 = PT, 0 = Random)
	Braid:		111001 ... etc...

	When you have a 0, you are certain it is from the random key,
	but 1's may be from either stream.  But as I pointed out earlier
	sending such a message is an invitation to disaster, unless
	you use extra transformations, such XOR, before braiding.  If
	you use a higher order mode (4 streams, or more), such KPT is
	absolutely no help.

	Braided Streams is interesting only in as much as it takes care
	of two problems at one shot: encryption and key management.  Also,
	contrary to straight XOR, each iteration through the system adds
	more security.  Finally, a number of streams can be braided
	together (multiplexed) in order to augment security even more.


-- 
William "Alain" Simon
                                                   UUCP: alain@elevia.UUCP