Re: Why Micosoft products using RC4 failed

From: Schmenge (Schmenge@bigroom.com)
Date: 04/11/03 

From: Schmenge <Schmenge@bigroom.com>
Date: Fri, 11 Apr 2003 03:32:43 -0700

On Fri, 11 Apr 2003 07:45:39 +0000 (UTC), daw@mozart.cs.berkeley.edu
(David Wagner) wrote:

>Schmenge wrote:
>>True that unanalyzed is risky, but I'm not quite sure I'm using it in
>>an unanalyzed fashion.
>
>If you did any analysis of your proposal, I missed it....

Right. OK. Thanks for pointing that out.

But as opposed to speaking about a strange cipher that no one has
heard about, I'm talking about RC4.

I think the analysis, some of which you yourself have done, shows that
RC4 has issues that open it to attack. And it also shows that there
are (still) simple ways to practically remove these pitfalls.

I'm calling these ways to remove pitfalls "countermeasures". Some
sci.crypt fellows use the term hygiene.

>
>Remember, "anyone can create an algorithm that he himself
>can't break" [Schneier]. The trick is to create a cipher that
>noone else can break. That's hard, and it's not something you
>can do off the cuff.
>
>http://www.counterpane.com/crypto-gram-9810.html#cipherdesign
>

No argument. But that is not what I am suggesting.

>>The attacks seem to coincide with starting RC4 with a weak key, or
>>using the first couple bytes to gain a wedge, but I'm not doing that.
>
>Common pitfall: Argue that a proposal defeats all the pre-existing
>attacks, hence "it must be secure".

That's not what I said. Or at least that is not what I meant.

>
>That's a strategy that's unjustified. There's nothing to ensure that
>an attacker will only follow the standard, pre-existing attacks.
>The attacker might adapt his attack strategy according to what enciphering
>algorithm you use. If your enciphering algorithm is different from what
>anyone ha used before, then there's no reason to think that protection
>against the pre-existing attacks means anything.

Preparing the 128-bit appended HMAC block in a way that cannot be
easily duped, without going OWF is not out of reach, I think.

Would not adding blocks (unknown to attacker) modulo to the original
checksum/padding block (creating a final checksum) prior to XORing
with keystream defeat the XORing a malsum attack? And if so, how many
would be prudent to not get hosed by this simple neat attack?

>>I'm trying to carefully use this PRNG strength to PRF and HMAC. This
>>is not innovation, is it?
>
>Of course it is.

OK.

It is a key and a non-repeating sequence

It is an attempt at making the key non-weak for using with RC4

It is RC4 with dropping 1K bytes

It is an attempt to make a simple HMAC

I should have said I don't see it as cavalier innovation.

I still think I should get the extra credit for using RC4 as a PRF.

Relevant Pages

  • Re: More on RC4/n
    ... > the computer power needed for a successful attack at various bit ... All works i read seem to point to it, higher /n RC4 are harder to ... crack in any of the various ways tried, ... but possibly cross feeding streams should be harder to analyze, imho, ...
    (sci.crypt)
  • Re: Generate a one-time pad from say a 256bit key?
    ... attack the cypher. ... This in itself is a perfectly good reason not use RC4. ... RC4 is not a standard encryption algorithm of any country that I know ...
    (sci.crypt)
  • Re: Tiny, simple solution for microcontroller flash loader?
    ... >permanent key) as I explained in the other posting about RC4. ... way (e.g., "well, gee, that attack sounds really complicated -- surely ... if you have a n-bit LFSR and a n-bit shuffle. ... I generally consider that enough to reject the scheme, ...
    (sci.crypt)
  • [REVS] Practical Exploitation of RC4 Weaknesses in WEP Environments
    ... Forcing, FMS Attack, First Byte attack, RC4 Attacks) and a possible ... This document will give a brief background on 802.11b based WEP weaknesses ...
    (Securiteam)
  • Re: RC4 broken?
    ... and the method fails if two iterations of RC4 are used. ... I suspect that whoever wrote this was talking about Ciphersaber, ... RC4 in a way that made it vulnerable to the attack presented in the paper ... happens to be one of these extremely weak keys. ...
    (sci.crypt)