RC4A is a slight modification of the simple RC4 stream cipher designed to strengthen it against a number of attacks. Here's that paper.
However in the paper, the second key
k2 is only mentioned twice and provides only a loose description of what it should be:
We take one randomly chosen key
k1. Another key
k2is also generated from a pseudorandom bit generator (e.g. RC4) using
k1as the seed. Applying the Key Scheduling Algorithm, as described in Fig. 1, we construct two S-boxes
S2using the keys
The main thing here is that
k2 is "generated from a pseudorandom bit generator (e.g. RC4) using
k1 as the seed", and
S2 are constructed "using the keys
In source code implementations of RC4A I have come across two different ways of handling
S2, none of which use a PRBG to produce
k2. This results in different output for the same input:
S2are exactly the same (using
- All 256 values of S-box
S1constitute the key
In a cryptography course, it is suggested to use a "nonce" for
k2, which has the same length of
k1 but doesn't explain how it is calculated from
k1 as a seed (which is understood to be how
k2 is produced).
Finally, another article appears to show that
k2 is produced by feeding a number of bytes from
S1 into the original RC4 PRGA, producing a keystream:
To be more specific, in KSA of RC4, the array S1 is initialized, using the secret key K. WK, 16 bytes of keystream, are generated from the array S1 in PRGA of RC4. Then, the array S2 is initialized in KSA of RC4, using WK.
I am assuming
K refers to
k1 and WK refers to
k2 in the original article.
RC4_KSA(K, S1) For i = 0 … l – 1 WK[i] = RC4_PRGA(S1) RC4_KSA(WK, S2)
One problem with this approach is that when calculating
k2, the RC4 PRGA would swap values in
S1, altering it.
S1 is used in the RC4A PRGA and would produce a different keystream than if it had not been altered. This can be avoided by using a second copy of
S1 for RC4 PRGA, leaving the original unaltered.
So there is ambiguity in how the second key for
S2 is produced, with implementations differing in output keystream for same input.
A few questions:
- Do the two differing implementations in practice undermine RC4A's
security claims by not using a PRBG/PRGA to produce
- Does it matter what
k2is, how it's produced, or if it's the same as
- What is the proper way to produce
k2that all implementations should follow?
k2generation that can cause different results in ciphertext depending on interpretation. $\endgroup$