Tag Info

Hot answers tagged

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

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

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


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

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

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

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

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?


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



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