cryptoanarchy.wiki

Arise, you have nothing to lose but your barbed wire fences!

1994-12-17 - Re: Time to exhaustively break 40-bit RC4?

Header Data

From: Hal <hfinney@shell.portal.com>
To: kipp@mcom.com
Message Hash: a54bf9841fc25a8f82da01ffaa52294b32a3063bbed0685521c7bea1f8dcf46b
Message ID: <199412172149.NAA15954@jobe.shell.portal.com>
Reply To: <199412122330.PAA29185@netcom20.netcom.com>
UTC Datetime: 1994-12-17 21:50:01 UTC
Raw Date: Sat, 17 Dec 94 13:50:01 PST

Raw message

From: Hal <hfinney@shell.portal.com>
Date: Sat, 17 Dec 94 13:50:01 PST
To: kipp@mcom.com
Subject: Re: Time to exhaustively break 40-bit RC4?
In-Reply-To: <199412122330.PAA29185@netcom20.netcom.com>
Message-ID: <199412172149.NAA15954@jobe.shell.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


I notice in the Netscape SSL spec the 40-bit export-approved RC4
key generation is a little more complicated than I would have thought.
First a 128 bit "master key" is chosen and 88 bits are revealed, leaving
40 bits secret.  Then the RC4 session key is generated as the MD5 hash of
this master key plus about 32 bytes of publically known but random
information.  I'm not clear whether the 128-bit output of the MD5 hash is
then used as the RC4 key, or whether only 40 bits are used (and if so,
whether there are any public bits in the key besides these 40).

If the former, then this extra hash step should really slow down
exhaustive search of the key space.  If the latter, then it is not clear
why the master key is key-size restricted at all since it is not likely
to be used in searching the key space.  Maybe someone from Netscape could
clear up how this is done.

Hal

Thread