Hot answers tagged

41

Academically speaking, RC4 is terrible; it has easy distinguishers ("easy" means "can really be demonstrated in lab conditions"). It is also hard to use properly. However, SSL/TLS uses RC4 correctly, and in practice the shortcomings of RC4 have no real importance. The power-that-be at Google decided to switch to RC4 by default because of the recent "BEAST" ...


21

It's meaningless nonsense. I would be inclined to avoid spending any money with these people. If you scroll down on this page, you'll find a table labelled key size vs. time to crack, according to which their $2 \times 256$ bit encryption takes $3.31 \times 10^{112}$ years to crack, making it (apparently) superior to ordinary $256$-bit encryption (which can ...


18

A few observations: RC4 suffers from related key attacks. This means your idea of concatenating a 224 bit key and a 32 bit IV is not a good idea. You should rather use $\operatorname{SHA-256}(Key||IV)$ Remember that a (Key, IV) pair must not be reused, ever. A 32 bit IV can work if it's a counter, but IMO such a scheme is unnecessarily fragile. I'd rather ...


14

Wikipedia has a decent writeup on the known attacks on RC4. Most of them are from biases of the output. To give you an idea of the severity of the attacks see the following quotes from the Wikipedia page: The best such attack is due to Itsik Mantin and Adi Shamir who showed that the second output byte of the cipher was biased toward zero with probability ...


12

By George, you're on to something. To answer the question you asked, I don't know of anyone actually attempting to recover a password this way, or it even being discussed. However, it does appear to be feasible, given enough encrypted streams. How many are enough? Well, I've started running a few simulations; preliminary results indicate that with ...


10

No, RC4 is not completely broken. It is possible to use it properly. It's just not very likely that an average developer will do so. RC4 is not a good choice for new systems. It is tricky to use properly. There are some serious pitfalls which, if you're not an expert cryptographer, can bite you in the butt. In fact, if you take a quick look in the ...


10

Yes, that omission weakens the cipher: the output $\mathtt K$ has a short cycle (at most 65280 bytes) for a sizable class of keys (one in 65536). The following details why. Because earlier code leaves $\mathtt i=256$ and the first execution of i := (i + 1) mod 256 makes that equivalent to $\mathtt i=0$, not initializing $\mathtt i$ makes no difference in ...


9

I do think that in the fullness of time the choice to forcibly migrate people to RC4 will be considered a folly. We recently had a PCI auditor command that we use RC4 to avoid the BEAST attack. We had no option but to comply or face losing our PCI certification. Across the industry, people are fleeing from AES-CBC in response to this attack. Yet in my ...


9

By definition of Salsa20 used as a stream cipher, it uses a 64-bit block counter and 64-bytes blocks, limiting its capacity to $2^{73}$ bits. After that, the counter would rollover, and thus the output. In a sense, this is the period. RC4 has no such explicit limit on the size of its output. We do not know how to exactly compute the period size, which very ...


8

The internal state of RC4 consists of a shuffled 256-element array and two pointers into that array. Thus, there are a total of $$256! \times 256^2 \approx 2^{1700.00}$$ possible states. Since the state update function of RC4 is reversible, it acts as a permutation on this set of possible states, so that every starting state will eventually recur after ...


8

Algorithms which swap bytes in an array are notoriously hard to analyze; the two main examples are RC4 (encryption) and MD2 (hashing). Being "hard to analyze" does not mean that they are strong; only that we do not have a generic framework such as differential cryptanalysis to apply to them. Both RC4 and MD2 are, academically speaking, "broken" (there are ...


8

If a large file enciphered using RC4 is partially corrupted, the uncorrupted portions remains fully decipherable, including what's after a corrupted portion if the corruption modifies this data's value, but not its length (a length corruption could occur e.g. for serial communication, but is unlikely on a hard disk). This is a property of all stream ciphers. ...


7

The minimum of 40 bits is conventional; below 40 bits of key material, RC4 (or practically any cipher without some built-in key stretching) is just too unsafe. At some point in history, in many countries, ciphers with a key above 40 bits where illegal in some usage (in USA: export; in France: use, sale, export); thus cipher designers wanting to prescribe ...


7

As far as RC4 is concerned, actually, it's not true that standard cryptanalysis methods are useless; linear cryptanalysis has been used to attack RC4. Jovan Golic' used linear cryptanalysis to show there's a bias in the lsbits that can be used to distinguish the output after (IIRC) $2^{44}$ bytes or so. However, typically other methods are used against RC4....


7

Yes, you can have a key of any length of that range (as long as it is an integral number of bytes), but really, why? There is absolutely no reason to. If the key is uniformly distributed, anything over 256 bits is total overkill and completely pointless. If the key is not uniformly distributed (maybe it's a passphrase or something), you should not be ...


7

There are several ways to answer your question: You cannot "replace" RC4 in SSL. SSL is a standard protocol in which any algorithm may be used only if both client and server support it and agree to use it. Thus, in practice, you do not get to replace algorithms as you wish, unless you control both client and server code; and even then, it would not longer ...


6

By discarding values 252 to 255, you effectively avoid introducing any new bias; the generic method is expressed in many places, e.g. this article (page 3). To generate random values between $0$ and $d-1$ (inclusive) from a PRNG which produces bit, you do the following: Choose an integer $r$ such that $2^r \geq d$. Obtain a $r$-bit word $x$ from the PRNG. ...


6

What type of attack are you trying to prevent? If it's a brute-force attack, AES-128 is more than sufficient. In the best case scenario, combining RC4 and AES gains you negligible additional security due to a meet-in-the-middle attack. Are you trying to hedge against a "break" of either RC4 or AES? If so, in the real world, this is extremely unlikely to ...


6

With RC4, the answer is "yes, you can efficiently run the cipher backwards, reconstructing previous states". For stream ciphers, whether you can reconstruct previous states in not typically considered, however for cryptographically secure random number generators (which are a similar primitive), it does come up; the term I've heard is "Backtracking ...


6

One problem with RC4 is that, while it does take a variable length input (up to 256 bytes), it's known not to be great at mixing those bytes together. Specifically, we see correlations between the RC4 key and the RC4 output stream. My first recommendation to you would be to use something other than RC4. About the only advantage RC4 has over most other ...


6

I think the 10100 is a typo and should be $10^{100}$ as shown here The period would be something along the lines of how long until the byte stream repeats. For example if the byte stream were "ABCDABCDABCD" and so on, then the period would be 4. For security you want a large period so that you can encrypt large amounts of data.


6

Wanted to expand on my comment as an answer. The KSA in RC4 permutes the bytes [0,1,...,255] using a key, say $k_u$. For any permutation of these bytes, there exists a key that will get you that permutation. The idea you outline is basically to start by permuting the bytes [0,1,...,255] according to some fixed initial permutation, then permuting the bytes ...


5

I am familiar with the RC4 related key attacks; I can say that if you publish the nonce, and use any of the first 256 bytes of the RC4 keystream, that you are vulnerable to those attacks. These attacks exploit a correlation between specific bytes of the RC4 key, and the initial output values; with your approach, the attackers can guess what (say) byte 2 of ...


5

Yes, an adversary can definitely decrypt a DES message, given sufficient funding. Fifteen years ago, in 1998, the EFF built a DES cracker (nicknamed Deep Crack) that can recover a DES key in a day. Today, anyone with the money can purchase a commercially available DES cracker named COPACOBANA. For RC2, I'm not aware of any practical attacks. (You still ...


5

In a purist cryptographic sense, there are many vulnerabilities in this cipher suite that can be (theoretically and practically) exploited. There are much stronger versions of SSL/TLS, and much stronger cipher suites that could be used. In a practical sense, it's not the end of the world - there are far worse cipher suites (e.g. those using intentionally ...


5

Nobody can tell you not to "have fun with it" but I would strongly recommend you to first study attacks on other ciphers. Spritz (Rivest & Schuldt) fortunately mentions a lot of research on its predecessor, RC4. This makes it a rather good starting point in my opinion. It is necessary to understand the linguistics and mathematical constructs that are ...


5

Does the value of the key array(T) have to be in this range [0-255] if yes could you please specify why? Yes. RC4 operates on bytes. There are 256 possible values for an 8 bit (1 byte) number, that range from 0 to 255. RC4 treats the key as an array of bytes, so every entry in the key array is by definition in the range 0 to 255. Why did they use s[t] ...


5

RC4 has several known weaknesses, including: Rather strong biases in the initial parts of its keystream Weaker biases in the rest of the keystream. Now, RC4 does take a variable length key, potentially up to 2048 bits (256 bytes). So, if you wanted, you could take a 2048 bit RSA modulus, and use that as the RC4 key. However, doing so would not affect ...


4

RC4 is a stream cipher and can be easy to misuse. E.g. Microsoft had problems with it to protect password and office documents. However its use is, afaik, correct inside the SSL/TLS specification. Like often in cryptography things are easier to misuse than to use ;-)


4

I believe you are mistaken; RC4 takes a variable length key (between 1 byte and 256 bytes), and uses that to generate an initial internal state, and from that, generates a continuous length of keystream. There are no assumption that 24 bits are fixed and 40 bits are random. What you might be talking about is that there might be some protocol or file ...



Only top voted, non community-wiki answers of a minimum length are eligible