Tag Info

Hot answers tagged

32

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


16

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


12

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


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

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

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

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

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

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


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


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

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


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


4

I don't think it's a bad idea - neither does Bruce Schneier. In his book Applied Cryptography, there is a section called "Cascading Multiple Block Algorithms". He basically states that provided that two distinct algorithms and two independent keys are used, then the result should be at least as difficult to break as the strongest algorithm. If Alice and ...


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

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


4

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


4

Afaik, the general export restrictions on keylengths of common ciphers were lifted during the Clinton administration. Here's the relevant wiki article.


4

Poncho does a good job of explaining why you could use a KDF before RC4. But you are talking about a password and a PBKDF. A PBKDF does more than just provide a good way to extract entropy from the given input (the password): It uses a salt, which can be used to protect against rainbow tables (which could be created for known plaintext). This salt could ...


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

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

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



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