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 keyk2
is also generated from a pseudorandom bit generator (e.g. RC4) usingk1
as the seed. Applying the Key Scheduling Algorithm, as described in Fig. 1, we construct two S-boxesS1
andS2
using the keysk1
andk2
respectively.
The main thing here is that k2
is "generated from a pseudorandom bit generator (e.g. RC4) using k1
as the seed", and S1
and S2
are constructed "using the keys k1
and k2
respectively".
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:
- S-boxes
S1
andS2
are exactly the same (usingk1
for both). - All 256 values of S-box
S1
constitute the keyk2
forS2
.
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.
Related pseudo-code:
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
k2
? - Does it matter what
k2
is, how it's produced, or if it's the same ask1
? - What is the proper way to produce
k2
that all implementations should follow?
Thank you!
k2
generation that can cause different results in ciphertext depending on interpretation. $\endgroup$