Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by krbdev.mit.edu (8.9.3) with ESMTP id QAA07496; Tue, 12 Nov 2002 16:06:19 -0500 (EST) Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA03180 for ; Tue, 12 Nov 2002 16:06:19 -0500 (EST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 8318B152128; Tue, 12 Nov 2002 16:06:14 -0500 (EST) To: Ken Hornstein Cc: krb5-bugs@mit.edu Subject: [krbdev.mit.edu #1254]Re: SAM uses RC4 insecurely References: <200211122053.gACKrHUs000010@ginger.cmf.nrl.navy.mil> From: Sam Hartman Date: Tue, 12 Nov 2002 16:06:14 -0500 In-Reply-To: <200211122053.gACKrHUs000010@ginger.cmf.nrl.navy.mil> (Ken Hornstein's message of "Tue, 12 Nov 2002 15:53:15 -0500") Message-Id: Lines: 46 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii RT-Send-Cc: X-RT-Original-Encoding: us-ascii Content-Length: 2183 >>>>> "Ken" == Ken Hornstein writes: Let's see if we can open a few less bugs on this thread. Copying krb5-bugs and not including a bug number in the subject opens a new bug. >> Well, there is a derive-key for rc4, but it only takes keyusage >> as input, not a string. Ken> Hm, I think I'm confused. I see where the keyusage gets fed Ken> into the algorithm in the Brezak draft, but what I don't see Ken> is anything that looks like derive-key for rc4. Maybe we're Ken> not talking about the same thing. I'm pointing out that there is algorithm that uses the long-term key and key usage to come up with an encryption key. It actually uses long-term key, keyusage and data; this is against the intent of the kcrypto draft but is allowed by the text. >> Defining dk interms of dr would work for rc4 if you had a >> reasonable definition of dr, but you currently do not. Ken> Maybe I'm being dense again (and not knowing much about rc4, Ken> other than glancing over the routines that implement it) but Ken> would it be reasonable to pretend for the purposes of rc4 and Ken> dr that the blocksize was equal to the keysize? I think that Ken> would prevent the attack you described. Or just keep state Ken> between calls to the encryption routine. No, because since rc4 is a stream cipher you'll end up using the same pseudo-random stream if I call dr with different constants. I.E. rc4 is a function that takes a key, some initial state, and a length and returns that many bits of pseudorandom stream. I then xor that against the data. The way the dr in the simplified profile is definied, if I treat rc4 as a block cipher then I'll be xoring the same output of rc4 against whatever constant I feed into dr. So the output of two calls to dr with the same key is related in a rather easy to detect manner. Ideally you want dr to be a pseudo-random function. As I mentioned, there is both md4 and the data-based-keying of rc4 without confounder as a potential candidate for dr. You could also use the key that would be produced by the data-based keying as a potential candidate for dr.