Can anyone point out the core differences between these ciphers?
-
6$\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$– kodluApr 1, 2019 at 23:01
-
$\begingroup$ It's also a very broad question. $\endgroup$– kodluApr 1, 2019 at 23:02
-
1$\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$– arifApr 1, 2019 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, 2019 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$– RedGlyphSep 9, 2019 at 10:54
1 Answer
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. The key schedule is reminiscent of MD2's internal operations. 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 sponsored by Lotus for their Lotus Notes software and designed by RSA Security, Inc. with input from the NSA. It was meant to be an export-ready drop-in replacement for DES but was created long before we had a good understanding of block cipher design. It is relatively devoid of analysis and could easily suffer from severe security vulnerabilities that have not been discovered. It's an interesting cipher for sure, but not a useful one.
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 a secret state-dependent index and an incrementing index. 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 serious problems such as vulnerabilities in how it uses a nonce exist that can make it difficult to use securely (in particular, the nonce is concatenated with the key, which is an issue as the cipher is vulnerable to related key attacks that enable key recovery). Of the ciphers you mentioned, RC4 is the only stream cipher. Its design was leaked to a mailing list 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. Otherwise, small biases may allow recovery of the plaintext without needing the key.
RC5
RC5 is a block cipher using a 1 to 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 resistance to cryptanalysis 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. The cipher's key schedule uses magic constants derived from the fractional part of $\phi$ (the golden ratio) and $e$ (the base of the natural logarithm, aka Euler's number). 12-round RC5 with 64-bit blocks is vulnerable to a differential attack using 244 chosen plaintexts. Using 18 to 20 rounds should protect against this. RC5 was published in a research paper from MIT and its specification is described in RFC 2040.
There is no reason to use RC5. RC6 is an improved version which is also better researched. If you do need to use it, use 18 or 20 rounds. Do not use 12 as was initially suggested by the authors.
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). It can be viewed as two interweaving parallel instances of a modified version of RC5. 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 that announced 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 (now referred to as 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.
-
3$\begingroup$ RC4 is badly broken and has been since 48 hours after it was published. Just say no to RC4, kids! $\endgroup$ Apr 2, 2019 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, 2019 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$ Apr 4, 2019 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, 2019 at 6:08
-
$\begingroup$ I'm not sure it's a 'reason', but MS used (further?) weakened RC2-40 to encrypt the certs in PFX, and when standardized as PKCS12 everybody else did the same. To read nearly all P12/PFX until recently, and to generate ones 'surely' readable by other systems, you needed RC2. RC2-40 is broken whether or not full RC2 is, but certs don't need to be secret and it's unclear why MS started the tradition of 'encrypting' them. In the last few years some (many?) systems have upgraded P12 privatekey encryption which does matter, and usually they also do the certs. $\endgroup$ Jun 23, 2022 at 0:42