Re: Stream Cipher Like SEAL Wanted ....

From: Mrsjunecarey (mrsjunecarey_at_aol.com)
Date: 06/12/03


Date: 12 Jun 2003 12:49:47 GMT


>In article <20030611133542.03096.00000517@mb-m14.aol.com>,
>Mrsjunecarey <mrsjunecarey@aol.com> wrote:
>>It's actually the RSA Security Inc. website that makes this statement about
>the
>>cycle length of (A)RC4 being overwhelmingly likely to be greater than
>10e100.
>>
>>As the Leopard web-page states, a large cycle length is guaranteed with
>>Leopard.
>
>I think it was back around Leopard6 that I
>demonstrated that the cycle length *could not
>possibly* be as long as RC4's, and that it was
>likely to be shorter. I'm not going to bother
>checking LeopardN for positive integer N, but I
>don't think "guaranteed" means what you seem to
>think it means.

Greg,

Leopard6 was very very bad.
In fact all my Leoaprd PRNGs were bad upto L11 (the point at which I fixed the
broken RC4 KSA and fixed the weak internal cycles which Bob Jenkins
discovered).

And as I said in the original respone to ink-the-lurker, a "large" cycle length
is guaranteed due to the mathematically perfect permutation algorithm, which
has a cycle length of about 176 million.

And as I've already said before, the cycle length of L11/12/13 is much larger
than 176 million.

>
>>The proof is one of the many testing programs I use on Leopard _always_
>>overflows the 32-bit counter. I'm pretty sure it overflows a 64-bit counter
>>aswell - but I'd have to double-check that.
>
>... and this statement just proves that "large" in
>a cryptographic context doesn't mean what you
>think it means, and that you certainly have no
>idea what "proof" means.

Large for me means millions.

Large for you obviously means 10e100.

I don't know how big the L11/12/13 cycle length is, but its bigger than a
32-bit counter, and as I've already mentioned I seem to remember its bigger
than a 64-bit counter.

>
>>>4. Leopard does not suffer from the ARC4 second byte bias.
>>>
>>>Why?
>>
>>The basic reason for this is due to the fact that the Leopard state-indices
>are
>>created from the key and are adversary-unknown.
>>
>>The (A)RC4 state-indices are initialised to zero.
>
>Yes, and this initialization is done specifically
>to prevent RC4 from falling into a short cycle.
>You can no longer prove that LeopardN does not do
>so.

Yes I can prove it.

Greg, before you start mouthing off to me, why don't you at least read my
source code and check the algorithm.

>
>Speaking of biases, I believe that Leopard6, or
>whichever one I looked at around 6 months ago,
>still exhibits the same bias towards repeated
>outputs that RC4 has (that is, it's slightly more
>likely to output the same byte twice in a row than
>random bytes would have). Can you prove that it
>doesn't any more? Have you even addressed that
>problem? That is enough (IMHO) to dis-recommend
>both RC4 and LeopardN.

Yes I've addressed this problem.
See my statement above about reading the source code and check the algorithm
before you start mouthing off BS on sci.crypt.

>
>Greg.
>--
>Greg Rose INTERNET: ggr@qualcomm.com
>Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199
>Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/
>Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C