# Tag Info

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

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

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

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

4

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

3

Using the same key for encryption and MAC is generally bad style, but may be secure in your implementation. FMS isn't relevant for file segment decode because you don't reuse the same key. FMS isn't the only attack, though. I have to ask though - is there some reason why you don't use SSL?

3

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

3

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

3

In short, short keys are susceptible to a certain class of attacks, key information over 2048 bits is just getting discarded, and exotic keys (those not aligned to bytes) are really either getting aligned to bytes by your implementation, or are just a very bad idea, depending. RC4 is a fairly straightforward algorithm, let's walk through initialization to ...

3

Yes. 256-bit WEP is insecure. There are a broad range of attacks against WEP. Most of them aren't affected by the key length. Wikipedia has references to many attacks on WEP; for more, read those references. Don't use WEP. Go straight to WPA2.

3

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

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

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

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

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

2

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.

2

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

1

As far as I understand, RC4 is not as secure as we would love it to be and considered to be a temporary fallback solution against BEAST attacks on TLS 1.0. I know Google uses RC4 for most of its services, and this is the reason one shouldn't keep gmail opened all the time ;-) I believe it must be replaced with AES-128-256. And TLS 1.1 supports such modes, ...

1

According to the paper, it takes up to 53 seconds for enough data to be transferred for the attack to be attempted. Then it takes 1-3 seconds with 50% probability on a 1.7 GHz Pentium-M to perform the crack (presumably this actually means between 1 and 6 seconds for 100% probability?). I would do a back of the napkin calculation how long the same attack ...

1

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

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