# Tag Info

25

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" ...

13

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 ...

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 ...

11

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 ...

9

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 ...

7

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). Not initializing $\mathtt i$ makes no difference in the values of $\mathtt i$ effectively used for the rest of the algorithm, since $0\equiv 256 \pmod{256}$; and hence has no security implication whatsoever. But ...

6

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 known how to exactly compute the period size, which very ...

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

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. ...

6

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 ...

6

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 ...

5

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 ...

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

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 ...

5

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 ...

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

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 ...

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 ...

4

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 ...

3

Question: Are ciphertexts produced by secret (unknown to the public) algorithms more secure than those produced by public algorithms like AES? Answer: No. The reverse! Public algorithms (like AES) have been examined by professional cryptographers all over the world. In contrast, secret algorithms, by definition, have not been subject to that process at all ...

3

I don't know of any practical attacks along these lines that pose a realistic threat in practice, on any current protocol. Let me explain. There are two standard kinds of distinguishing attacks on RC4: The first two bytes. Mantin and Shamir showed that the second byte of output from RC4 is biased. If the password was always encrypted at the very start ...

3

Well, no, there's no defined TLS ciphersuite that does the RC4 algorithm with a discard of the original stream. I'm not a designer of TLS, nor am I a member of the IETF working group that controls it; I suspect that they'd prefer for people to transition to ciphersuites that use AES (or some other newer cipher), and so there's little incentive for them to ...

3

If what the program does is "take your password, use that as-is as the key to a (modified) RC4 encryption algorithm, and use that keystream to decrypt the entire file", well, there is no obvious weakness to take advantage of. Partial information doesn't help you much (for that matter, they could have given you the entire decrypted file, and it wouldn't help ...

3

On the first glance, this base 36 key stream looks at least as secure as RC4 itself - you are simply discarding some of the output, and not introducing any bias. Note that there are some general weaknesses with in the start of the output of RC4, which means that it is normally recommended to discard the first 1000 or so bytes after initialization (I have to ...

3

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 ...

3

An adversary would have to first break the first scheme and then the second, so in concrete terms there is slightly added security.If it takes time $2^{80}$ to break each scheme independently, it now takes time $2^{81}$ to break both encryptions. So there is minimal added security. In computational terms, assuming the key-size are similar, this wouldn't add ...

3

I don't think this is a great idea. I don't know of anyone who has analyzed it carefully, but it is basically relying upon RC4 to be secure against a particular kind of related-key attack (one that probably hasn't been studied much). We know that in general RC4's key schedule algorithm is not very resistant to related-key attacks. For instance, it is a ...

3

You can do RC4 using a 52-entry table, instead of a 256-entry table. All you do is change the modulo-256 arithmetic in RC4 to use modulo-52 arithmetic. There are no special changes needed, and no need to describe a special algorithm. If you want to see a description of how to perform it manually using a deck of cards, you can find that here: ...

3

No. The key is not used to encrypt the message. RC4 is a stream cipher. The key is utilized to generate a one-time pad to encrypt the message. This is what you have actually done: E1 = RC4(M1,K) = M1 XOR PAD(k) E2 = RC4(M2,K) = M2 XOR PAD(k) E1 XOR E2 => M1 XOR M2 Ergo, RC4 keys are safe for single time use. You need to concatenate a nonce to the ...

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