Tag Info

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

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

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

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

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

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

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

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

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

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

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

Well, it depends on what your 'RC4' function does, and what you mean by the key. Let's step through the possibilities: Possibility 1: if the RC4 function takes the key, runs the RC4 Key Setup Algorithm on it, and then generates some keystream with that state, and exclusive-or's that keystream with the message to generate the ciphertext. In addition, this ...

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

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

The obvious problem with Shortcut 1 is that the same keystream will be used to encrypt all the messages. That is, an attacker can exclusive-or two ciphertexts together, and the result will be the exclusive-or of the two plaintexts; this may very well allow the attacker to recover both messages. How easy this is depends on the language the messages are in; ...

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

Got news: http://en.wikipedia.org/wiki/Transport_Layer_Security#RC4_attack It's not very practical yet (at least 224 ciphertexts), but attacks can only get better, not worse. Remember how it was with WEP cracking.