Re: Securing ARC4


David Wagner wrote:
Bill Cox wrote:
Randomization is simple, given an array R of 256 truely random bytes:

for i = 0 to 255
swap(S[i], S[R[i]]

Where does the key come in? Is this applied before the normal RC4
key schedule? after? something else?

On second thought, never mind, don't bother answering those questions.
It doesn't matter: I won't have time to perform a careful analysis of
this RC4 variation in any event. At a high level, you are changing the
RC4 algorithm. Any such changes have to be evaluated very carefully,
because they can introduce insecurity. Your changes could easily
introduce security problems.

I know you said that you've completely randomized S, so you don't see
how a security problem could arise, but think about this. The array R
is public knowledge. Say you generate one S-table with key K and array
R and use that to encrypt the first message; then you generate another
S-table with key K and array R' and use that to encrypt the second
message. You've essentially got a related-key condition. This might
help an attacker to recover K. How do you know that cannot happen?
Even worse, depending upon the surrounding protocol, it may be possible
for the attacker to choose or control R in some way. If that is possible,
it may open up another avenue for attacks. That's why these changes to
the internal details of algorithms have to be carefully analyzed.

Crypto primitives are hard to evaluate. It takes a lot of work and
expertise to get a sense about whether the crypto primitive is likely to
be secure or not. Tweaking the innards of a primitive is not something
to be done lightly. I encourage you to resist the urge to tweak the
algorithms (no matter how fun it may be).

I agree. I haven't taken time to import SHA-1 into tinycrypt yet, but
I will. Even if I fix the randomization problem other's pointed out,
when /dev/urandom runs is forced to switch to SRNG mode, the cypher
could suffer. Is there any reasonable alternative to SHA-1 that is
simpler? Since I'll only use it to hash the key and nonce, speed
counts than complexity. -- Thanks.

.

Relevant Pages

  • Re: Securing ARC4
    ... Is this applied before the normal RC4 ... Say you generate one S-table with key K and array ... for the attacker to choose or control R in some way. ... Crypto primitives are hard to evaluate. ...
    (sci.crypt)
  • Re: Some thoughts about ways to use RC4
    ... While this is easy to implement for encryption, ... >more difficult for the attacker: ... any alteration at all is useful. ... distinguishing attack against RC4, but it just ...
    (sci.crypt)
  • Re: Generate a one-time pad from say a 256bit key?
    ... in breaking the cypher. ... that RC4 is the only secure stream cypher. ... In situation where the attacker doesn't even know what cipher is being ...
    (sci.crypt)
  • Re: 8 Bit Random Numbers
    ... RAM, I would echo nospam's suggestion to use RC4 (aka ArcFour, ... A description of ARCFOUR (Alleged RC4), written by Neil Bawd in 1997 ... Every time the array is used it changes - by swapping two bytes. ...
    (sci.electronics.basics)
  • Re: A variation of RC4
    ... >]vein as swapping of regions of elements of the array that is ... >]done in Schneier's Solitaire, which results in correspondingly ... to me in the context of RC4. ... reducing the speed impact. ...
    (sci.crypt)