From: Hal <hfinney@shell.portal.com>
To: cypherpunks@toad.com
Message Hash: 2c89332814649dd911ce0cd90119260c18870db57962a932dffd6e90cefd6c7a
Message ID: <199409151701.KAA08820@jobe.shell.portal.com>
Reply To: <9409151452.AA03618@webster.imsi.com>
UTC Datetime: 1994-09-15 17:02:15 UTC
Raw Date: Thu, 15 Sep 94 10:02:15 PDT
From: Hal <hfinney@shell.portal.com>
Date: Thu, 15 Sep 94 10:02:15 PDT
To: cypherpunks@toad.com
Subject: Re: thoughts on RC4
In-Reply-To: <9409151452.AA03618@webster.imsi.com>
Message-ID: <199409151701.KAA08820@jobe.shell.portal.com>
MIME-Version: 1.0
Content-Type: text/plain
I realized a few minutes later that I was mistaken to write:
>OTOH maybe that is not
>necessary because probably the whole array does not have to be set up
>in order to tell whether a given key will work. 1/3 of the entries in
>the table are fixed once they have been swapped once, so if you checked
>after doing the first 20 entries, say, about 7 should have their final
>values, and we can perhaps reject a key already in a known plaintext
>situation just from that. So actually the large table size may not
>help against exhaustive key search. (The mod I suggested to the key
>setup would defend against this possibility, which raises the question
>of whether this design aspect was chosen to allow for export approval.)
Just knowing several of the first few entries in the table doesn't allow
you to quickly reject keys because the algorithm selects entries from
throughout the table to xor with the data stream. So this does not
imply that keys can be rejected quickly, nor does it suggest that the
particular setup algorithm used is particularly weak or was chosen
for export approval. Sorry about the error.
Hal
Return to September 1994
Return to ““Perry E. Metzger” <perry@imsi.com>”