Basics of Cryptology - Part 5 (Modern Cryptography - Stream Ciphers - RC4)

#cryptology, #cryptography, #cryptanalysis, #lecture, #course, #tutorial
In this video, we show the basics of cryptology (cryptology = cryptography and cryptanalysis).
This particular video shows in detail how the modern stream cipher RC4 works.
First, we discuss in detail the internal workings of RC4 and give a brief overview of its invention.
Then, we show a visualization of RC4 in JCrypTool (10:04). Finally, we use CT2 (from 13:04) to encrypt and decrypt text using RC4. Here, we also show what happens, if you change a byte in the plaintext, ciphertext, or in the key.
To see all videos in the "Basics of Cryptology" series, use this playlist: • Learn the Basics of Cr...
If you are interested in details about CrypTool 2, you may have a look at this video here, which gives a short introduction: • Short Introduction to ...
You may download the latest version of JCrypTool here: www.cryptool.o...
Finally, you may download the latest version of CrypTool 2 here: www.cryptool.o...

[@bernhardesslinger2666]

A very good explanation on how RC4 works. Thanks.

[@EladBeber]

Thanks for great video !!!

[@أسامةشبع]

Thank you so much

[@tomgi859]

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?

[@CryptographyForEverybody]

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.

[@tomgi859]

@@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!

[@CryptographyForEverybody]

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.

[@tomgi859]

@@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!

[@CryptographyForEverybody]

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

[@creonte38]

Thanks for this amazing vídeo. I hope you stay safe!

[@CryptographyForEverybody]

Thank you! I hope you too.

[@joseAn-b2q]

hello, I don't know what I have to confront the XOR to the encrypted frame so that it returns the keystream

[@CryptographyForEverybody]

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