2
$\begingroup$

Can anyone point out the core differences between RC variations?

$\endgroup$
  • 4
    $\begingroup$ This is a massively lazy question. What research have you done. All these specs are online. Did you even do an internet search. You want people to describe differences between 4 ciphers, on which there is a lot of material, while you seat behind a screen. $\endgroup$ – kodlu Apr 1 at 23:01
  • $\begingroup$ It's also a very broad question. $\endgroup$ – kodlu Apr 1 at 23:02
  • $\begingroup$ Yes, it is lazy but I did mention the "core" difference. By core difference, I didn't mean how their algorithm/makings are different but which points make them apart. Like, their key size, the reason for the update, fault of previous and features of updates. $\endgroup$ – muhammad Apr 1 at 23:06
  • $\begingroup$ I don't think it's a bad question. It's a bit basic, but it's easy to answer. $\endgroup$ – forest Apr 1 at 23:12
  • $\begingroup$ It is a bad question, on the "search and research" and "be specific" criteria at least, which shows a definite laziness from the OP. But I suppose the reason behind is to get answers from knowledgable people, googling such topics leads to untrustworthy results, like for ex. Wikipedia pages. The way to go is to search first, then ask specific questions on the results if they are unsure, for ex. "what are the weaknesses of X in such case?" or "is 128-bit key enough for such application?". $\endgroup$ – RedGlyph Sep 9 at 10:54
12
$\begingroup$

RC2

RC2 is a 64-bit source-heavy unbalanced Feistel cipher with an 8 to 1024-bit key size, in steps of 8. The default key size is 64 bits. It was designed in 1987. It has a heterogenous round structure with a total of 18 rounds (16 "MIXING" rounds and 2 "MASHING" rounds). It is a complex cipher using secret indices to select key material. It performs bitwise rotations, AND, NOT, and XOR, as well as modular addition. It is vulnerable to a related-key attack given 234 known plaintexts. It is defined in RFC 2268, though it was originally leaked to a mailing list through reverse engineering software that used it in 1996.

There is never a reason to use RC2. It is an extremely old cipher designed to be a drop-in replacement for DES created long before we had a good understanding of block cipher design. It is relatively poorly-analyzed and could easily have severe security vulnerabilities that have not been discovered.

RC4

RC4 is a stream cipher with a 40 to 2048-bit key written in 1987 with a maximum theoretical strength of log2(256!) ≈ 1684 bits. It generates a keystream from a state array composed of a 256-byte permutation by swapping values based on secret indices. The first portion of the RC4 keystream shows a significant bias, though the bias shrinks as more keystream is generated. For that reason, many implementations drop the first few hundred (or even thousand) bytes. Other biases and problems, such as vulnerabilities in how it uses a nonce, exist that can make it difficult to use securely. Of the ciphers you mentioned, RC4 is the only stream cipher. It was leaked to a mailing list (before RC2 was) in 1994.

If you ever find yourself needing to use RC4, make sure you combine the key and nonce by putting them through a cryptographic hash function first, rather than concatenating them as traditionally done. Ensure you drop the initial keystream (at least 768 bytes, but ideally up to 3072), and do not use it in applications where the same plaintext may be encrypted an unlimited number of times with different keys.

RC5

RC5 is a block cipher using a 1–255 round (12 originally suggested) Feistel-like network with 32, 64, or 128-bit blocks published in 1994. The key size is 0 to 2040 bits. One thing that makes RC5 unique is its use of data-dependent rotations, a feature that theoretically improves security but which, in practice, often makes the cipher harder to analyze and can leave weaknesses that are only found later. Additional operations involved are modular addition and bitwise XOR. 12-round RC5 with 64-bit blocks is vulnerable to a differential attack using 244 chosen plaintexts. Increasing the rounds to 18 or 20 should protect against this. RC5 was published in a research paper from MIT and is described in RFC 2040.

There is no reason to use RC5. RC6 is an improved version which is also better researched.

RC6

RC6 is a 20-round Feistel block cipher based off of RC5, with tweaks done to make it acceptable for the AES competition (including using a fixed block size of 128 bits and supporting 128, 192, and 256-bit keys). RC6 ultimately lost to Rijndael, but did make it to the top 5 (along with Twofish, Serpent, Rijndael, and MARS). RC6 uses the same basic operations as RC5, but also includes multiplication to improve diffusion characteristics of the rotation operation. It is described in the paper announcing it.

Given that it survived the first round in the AES competition, it is thought to be quite secure. No major issues have been found in it. If you find yourself wondering if you should choose RC6 though, the answer is probably no. Stick with the winner of the competition, Rijndael (which we now just call "AES").


All of these were created or co-created by Ron Rivest, one of the creators of RSA and the creator of MD2, MD4, MD5, and co-creator of MD6. RC is said to stand for "Ron's Code" or "Rivest cipher". Interestingly, RC1 was never published, and RC3 was broken at RSA Security during development.

In summary:

  • RC2 is an ancient block cipher that should not be used for anything.

  • RC4 is an ancient stream cipher that should not be used for anything, yet still is.

  • RC5 is a slightly newer block cipher and is secure with sufficient rounds.

  • RC6 is an improvement upon RC5, increasing its security. It lost the AES competition.

RC4 and RC6 are by far the most well-researched. The former is because of its ubiquitous use despite its weaknesses, and the latter because it was part of a competition that involved extensive analysis. However, you still shouldn't use any of these ciphers as there are far better alternatives.

$\endgroup$
  • 3
    $\begingroup$ RC4 is badly broken and has been since 48 hours after it was published. Just say no to RC4, kids! $\endgroup$ – Squeamish Ossifrage Apr 2 at 1:08
  • $\begingroup$ @SqueamishOssifrage Yup. I have no idea why it ever got so much traction. There are so many ways using it can go fatally wrong, and so few places where it can be used safely. Even in those places, there are still better alternatives! Using it is like using MD4: Rarely safe, usually fatal, and a huge crypto faux pas. $\endgroup$ – forest Apr 2 at 1:14
  • $\begingroup$ We should mention that one of the reasons why RC4 was broken, was the wrong implementation of it in the WEP protocol, however RC4 is used in google HTTPS protocol nowadays without any problem . $\endgroup$ – Arsalan Vahi Apr 4 at 6:06
  • 1
    $\begingroup$ @ArsalanVahi Actually one of the issues with WEP comes from the weakness of RC4 itself, specifically related key attacks that would not have been an issue were another stream cipher used. And Google no longer uses RC4 in TLS because biases early in the keystream can make it possible to recover secret values from HTTP headers. $\endgroup$ – forest Apr 4 at 6:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.