From: “Ian Farquhar” <ianf@wiley.sydney.sgi.com>
To: Bill Sommerfeld <cypherpunks@toad.com
Message Hash: 612be3b487680b0ce271c1e3a31f8a5b7dc99bb45747d1e467ba6012a87fbb15
Message ID: <9409191534.ZM8952@wiley.sydney.sgi.com>
Reply To: <199409151705.NAA00703@orchard.medford.ma.us>
UTC Datetime: 1994-09-19 05:37:55 UTC
Raw Date: Sun, 18 Sep 94 22:37:55 PDT
From: "Ian Farquhar" <ianf@wiley.sydney.sgi.com>
Date: Sun, 18 Sep 94 22:37:55 PDT
To: Bill Sommerfeld <cypherpunks@toad.com
Subject: Re: thoughts on RC4
In-Reply-To: <199409151705.NAA00703@orchard.medford.ma.us>
Message-ID: <9409191534.ZM8952@wiley.sydney.sgi.com>
MIME-Version: 1.0
Content-Type: text/plain
On Sep 15, 1:05pm, Bill Sommerfeld wrote:
> Actually, I'm not sure that it's that impractical, but I don't know a
> heck of a lot about VLSI or hardware design. A fully pipelined chip
> would require significantly more more chip area than the DES cracker,
> but you probably don't need that.
One of the issues I looked at over the weekend was the parallelization of
the key scheduler, which is definitely a non-trivial problem. One thought
that did occur to me was that there might be a massively parallel
solution to this which has a practical implementation up to 48 bits,
but not over this. I'll post more about this when I get some time, but
I've got to disagree with Bill here that a simple RC4 implementation (without
a parallel key schedule setup) would take more die area than a DES cracker.
Ultimately, it is a VERY simple cipher, and the VLSI implementation would
reflect this.
Even so, the release of the algorithm confirms the RSADSI position that
an exhaustive keysearch would be a slow operation, given the setup
time required for the key schedule setup.
BTW, just an idle question: why is RC4 a stream cipher, as opposed to an
8-bit block cipher? Based on the implementation, it would seem to be the
later to me.
Ian.
Return to September 1994
Return to ““Perry E. Metzger” <perry@imsi.com>”