Tag Info

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Any reversible cipher will need at least $\Omega(n)$ time (where $n$ is the size of the plaintext), since we need to touch each bit at least once. A stream cipher (i.e. deterministic pseudo-random bit generator) does some fixed amount of work for each bit (or larger unit) of output (with maybe some initial preparation overhead), which is $O(n)$. A block ...

Stream ciphers are essentially just random number generators, so for each input bit they generate a random bit (based on a seed, i.e. the key) and combine it with the input bit, giving you the output bit. So: c = m ⊕ G(k) m = c ⊕ G(k) Where c is ciphertext, m is plaintext, G is the RNG and k is the key. As such, all stream ciphers should be O(n) ...

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

To add to what fgrieu said, think of RC4 as a self-modifying rotor. Imagine a wheel with little tiles on it like Scrabble tiles, but labeled 0x00 to 0xff (or 0 to 255). Each time you crank out a value, you flip some tiles on the rotor and ratchet it one place. You initialize the wheel by spinning it completely once, using your key as values to control how ...

The algorithm you describe seems to have a class of special states (similar to the Finney states of RC4) consisting of the states such that $i = j$ and $k_x \bmod L = 1$, where $x := k_i \bmod L$. If we are at a state that belongs to this class at the beginning of the loop, the effect of the loop will be simply to swap $k_i$ and $k_{i+1}$ and to increment ...

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

As for your first question "is the S-box indistinguishable from a random permutation?", well, there are likely some subtle biases. For one, we know that, after exactly 4096 steps, the combination $j=1$ and $SBox[1] = 1$ is impossible; that's because $i=0$ after 4096 steps, and the combination $j=i+1$ and $SBox[j]=1$ is known to be impossible (given the ...

Regarding #1: You don't lose anything with regards to the algorithm itself. The algorithm to go from the key to the key schedule (KS) is deterministic and well known, so anyone who gets the key can easily get the KS too. The actual algorithm itself isn't made less secure by communicating the KS instead of the key. However, relying on the KS instead of the ...