Hiho, you could just give a stream of zeros (00 00 00…) to the cipher component to obtain the key stream. It internally then XORes the keystream with zeroes and you get the pure keystream. To create a stream of zeroes use a text input component and a string decoder. Set the decoder to hex values and connect it to the cipher component (e.g. to rc4). I hope that answers your question. A 2nd way would be to xor the plaintext with your ciphertext which gives you the keystream 🙂. Greetings, Nils
Great video, thanks a lot! There's something I didn't understand- why do we need the KSA algorithm? Can't we just feed the PRGA with the key directly to create a keystream as long as the plaintext?
Hello Tomgi859, Thank you for your nice words! Now the answer(s) to your question. 1) The easy answer :-) : We need it since Rivest designed it that way, otherweise it is not RC4 ;-) 2) Now, I try to answer WHY Rivest added the KSA :-) I think that he did so, to take care that the initial state is shuffled well before we obtain the first byte(s) for encryption. If we would just put the key into the PRGA, there would be a high chance that several bytes would be predictable (meaning the same with different keys). Lets assume we have a short key. In that case, another short key would (maybe) produce a lot of similiar bytes. That would be a very week PRGA. Therefore, the key is used to shuffle our state array before obtaining the first "random" values. In fact, that was even not enough :-). One of RC4's weaknesses is that the first bytes are predictable. Therefore, in 2001 RSA security suggested to discard the first 256 bytes RC4 produces for encryption. Later, a researcher found an attack that could go beyond the 256 bytes (see en.wikipedia.org/wiki/RC4#Klein's_attack) and suggested to discard the first 12 rounds of RC4... today, RC4 is completely broken and should not be used for any security purposes.
@@CryptographyForEverybody Thank you a lot for your detailed answer and quick response! It's very appreciated! Since I'm currently learning this subject, I think I can now ask a more precise question- RC4(like other stream ciphers) needs a unique IV for each message, so using the same key for encrypting multiple messages, won't enable a chosen-plaintext attack. So where does this part goes in the rc4 cipher? Does it assume that that the user gave it a tweaked key(key + IV)? Thanks in advance!
Hiho, the IV is not intended for defending against chosen-plaintext attacks. It is intended for having a different keystreams every time data is encrypted using the stream cipher, thus, no two plaintexts are encrypted using the same keystream. Lets assume we use the key K and encrypt P1 and P2. The stream cipher generates our keystream Ks. We will get C1 = P1 XOR Ks and C2 = P2 XOR Ks... when you now perform C1 XOR C2 = (P1 XOR Ks) XOR (P2 XOR Ks) you obtain = P1 XOR P2... if you can now guess one of the two plaintexts, you get the other one, e.g. P1 XOR P2 XOR P1 = P2. Also, if you then have one plaintext, you can get the keystream, e.g. (Ks XOR P1) XOR P1 = Ks and obtain the keystream Ks. Then, you may decrypt all following messages using the same key (and using the same keystream) as well. For practical attacks: Since network protocols usally have many similiar packets, for example have similiar headers, guessing a plaintext is not too difficult.
@@CryptographyForEverybody Hello, thank you very much for you detailed explanation! Also sorry for delying in replying. But what I asked was- in which part does the rc4 creates the iv? Thanks you in advance!
Hiho, RC4 does not specify any IV. No stream cipher (as far as I know) explicitly specifies an IV. The cryptographic protocols, which use the stream cipher, specify the IV. For example, with the old WEP (en.wikipedia.org/wiki/Wired_Equivalent_Privacy) protocol, which uses RC4, the IV is part of the key. The IV is changed for every encryption performed with the cipher, resulting in another output keystream every time. See the figure named "Basic WEP encryption: RC4 keystream XORed with plaintext" of that Wikipedia article. Hope that helps :-) Greetings, Nils
A very good explanation on how RC4 works. Thanks.
Thanks for this amazing vídeo. I hope you stay safe!
Thank you! I hope you too.
Thanks for great video !!!
Thank you so much
hello, I don't know what I have to confront the XOR to the encrypted frame so that it returns the keystream
Hiho, you could just give a stream of zeros (00 00 00…) to the cipher component to obtain the key stream. It internally then XORes the keystream with zeroes and you get the pure keystream. To create a stream of zeroes use a text input component and a string decoder. Set the decoder to hex values and connect it to the cipher component (e.g. to rc4). I hope that answers your question. A 2nd way would be to xor the plaintext with your ciphertext which gives you the keystream 🙂. Greetings, Nils
Great video, thanks a lot! There's something I didn't understand- why do we need the KSA algorithm? Can't we just feed the PRGA with the key directly to create a keystream as long as the plaintext?
Hello Tomgi859,
Thank you for your nice words! Now the answer(s) to your question.
1) The easy answer :-) : We need it since Rivest designed it that way, otherweise it is not RC4 ;-)
2) Now, I try to answer WHY Rivest added the KSA :-)
I think that he did so, to take care that the initial state is shuffled well before we obtain the first byte(s) for encryption. If we would just put the key into the PRGA, there would be a high chance that several bytes would be predictable (meaning the same with different keys). Lets assume we have a short key. In that case, another short key would (maybe) produce a lot of similiar bytes. That would be a very week PRGA. Therefore, the key is used to shuffle our state array before obtaining the first "random" values.
In fact, that was even not enough :-). One of RC4's weaknesses is that the first bytes are predictable. Therefore, in 2001 RSA security suggested to discard the first 256 bytes RC4 produces for encryption. Later, a researcher found an attack that could go beyond the 256 bytes (see en.wikipedia.org/wiki/RC4#Klein's_attack) and suggested to discard the first 12 rounds of RC4... today, RC4 is completely broken and should not be used for any security purposes.
@@CryptographyForEverybody Thank you a lot for your detailed answer and quick response! It's very appreciated!
Since I'm currently learning this subject, I think I can now ask a more precise question- RC4(like other stream ciphers) needs a unique IV for each message, so using the same key for encrypting multiple messages, won't enable a chosen-plaintext attack. So where does this part goes in the rc4 cipher? Does it assume that that the user gave it a tweaked key(key + IV)?
Thanks in advance!
Hiho,
the IV is not intended for defending against chosen-plaintext attacks. It is intended for having a different keystreams every time data is encrypted using the stream cipher, thus, no two plaintexts are encrypted using the same keystream.
Lets assume we use the key K and encrypt P1 and P2. The stream cipher generates our keystream Ks.
We will get C1 = P1 XOR Ks and C2 = P2 XOR Ks... when you now perform C1 XOR C2 = (P1 XOR Ks) XOR (P2 XOR Ks) you obtain = P1 XOR P2... if you can now guess one of the two plaintexts, you get the other one, e.g. P1 XOR P2 XOR P1 = P2. Also, if you then have one plaintext, you can get the keystream, e.g. (Ks XOR P1) XOR P1 = Ks and obtain the keystream Ks. Then, you may decrypt all following messages using the same key (and using the same keystream) as well.
For practical attacks: Since network protocols usally have many similiar packets, for example have similiar headers, guessing a plaintext is not too difficult.
@@CryptographyForEverybody Hello, thank you very much for you detailed explanation! Also sorry for delying in replying.
But what I asked was- in which part does the rc4 creates the iv?
Thanks you in advance!
Hiho,
RC4 does not specify any IV. No stream cipher (as far as I know) explicitly specifies an IV. The cryptographic protocols, which use the stream cipher, specify the IV.
For example, with the old WEP (en.wikipedia.org/wiki/Wired_Equivalent_Privacy) protocol, which uses RC4, the IV is part of the key. The IV is changed for every encryption performed with the cipher, resulting in another output keystream every time. See the figure named "Basic WEP encryption: RC4 keystream XORed with plaintext" of that Wikipedia article. Hope that helps :-)
Greetings,
Nils