Re: Stream Cipher Like SEAL Wanted ....

From: Mrsjunecarey (
Date: 06/12/03

Date: 12 Jun 2003 12:49:47 GMT

>In article <>,
>Mrsjunecarey <> wrote:
>>It's actually the RSA Security Inc. website that makes this statement about
>>cycle length of (A)RC4 being overwhelmingly likely to be greater than
>>As the Leopard web-page states, a large cycle length is guaranteed with
>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.


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

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.
>>The basic reason for this is due to the fact that the Leopard state-indices
>>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

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 Rose INTERNET:
>Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199
>Level 3, 230 Victoria Road,
>Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C