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

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

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


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

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

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


1

The short answer to your question is because RC4 is a stream cipher. Try comparing the xors of the two plaintexts and the two ciphertexts... Better still, replace the second ciphertext with \x00...\x00 and then look what happens. A stream cipher works by taking a secret input (the key) and turning it into a long stream of pseudo-random data (the stream). ...


1

Note that the above discussion may be out of date after the Snowden revelations. For example, see the "Hardening Internet Infrastructure" panel at IETF88 where Schneier speculates that the NSA expects to be able to break RC4 and is recruiting staff to do so.


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



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