# Tag Info

## Hot answers tagged rc4

20

It's meaningless nonsense. I would be inclined to avoid spending any money with these people. If you scroll down on this page, you'll find a table labelled key size vs. time to crack, according to which their $2 \times 256$ bit encryption takes $3.31 \times 10^{112}$ years to crack, making it (apparently) superior to ordinary $256$-bit encryption (which can ...

8

If a large file enciphered using RC4 is partially corrupted, the uncorrupted portions remains fully decipherable, including what's after a corrupted portion if the corruption modifies this data's value, but not its length (a length corruption could occur e.g. for serial communication, but is unlikely on a hard disk). This is a property of all stream ciphers. ...

5

I think the 10100 is a typo and should be $10^{100}$ as shown here The period would be something along the lines of how long until the byte stream repeats. For example if the byte stream were "ABCDABCDABCD" and so on, then the period would be 4. For security you want a large period so that you can encrypt large amounts of data.

4

ECB is not secure even with per file keys, because if two blocks of the file are identical, this is visible in the ciphertext. The only * cases where ECB is secure is encrypting completely random data or encrypting a single block per key. You should pick something more secure if your can help it. If there is literally no other option than RC4 and AES ECB, ...

4

Does the value of the key array(T) have to be in this range [0-255] if yes could you please specify why? Yes. RC4 operates on bytes. There are 256 possible values for an 8 bit (1 byte) number, that range from 0 to 255. RC4 treats the key as an array of bytes, so every entry in the key array is by definition in the range 0 to 255. Why did they use ...

3

RC4 is some kind of pseudo random number generator. You input a key (seed) and now can get a stream of pseudo random numbers. The values here are this numbers, always a byte at a time. Unlike a block cipher, you don't have a plaintext. You use this key stream to add it to the plaintext to get the ciphertext. "Adding" can be done with XOR, because that's ...

3

Verilog is Turing complete, so you can implement any algorithm in Verilog, if you really want to.

2

No, to the best of our knowledge, it is not possible, apart from a brute force search over all possible keys. RC4 has known cryptographical weaknesses; however, none of them are of much help in recovering the key, given a plaintext/ciphertext pair. There are backtracking approaches that might take circa $2^{700}$ effort independent of the key size; however ...

2

Maarten appears to make it look like it's an impossible (or, at least, an exceedingly difficult task) to recover the two plaintexts. Indeed, if you literally know nothing about the plaintexts, it can be difficult. However, you typically have a reason you are interested in the messages, and hence often have a clue as to what language they might be. If the ...

2

At least one thing goes very wrong: if an adversary can obtain the ciphertext for a few short chosen plaintexts and the same reused key/initial state, that allows reconstructing the state because the indexes vary in a controlled way. That certainly works if we obtain the ciphertext for the $2^{24}$ plaintexts consisting of the 3 bytes $u$ $v$ $w$ $0$ ...

1

Like fkraiem's answer points out, passing a statistical test does not prove a PRNG is cryptographically random, or even statistically random with regard to other tests. In the case of RC4 the biases are most prominent in the beginning of the keystream. To borrow a useful illustration from Vanhoef and Piessens' "All Your Biases Belong To Us: Breaking RC4 in ...

1

Statistical tests have no value to evaluate randomness in a cryptographic sense, because an attacker is not required to use any specific test. The fact that a stream passes some set of predetermined tests tells you nothing about how it fares against tests which are not in the set.

1

Unless you know more about the plaintexts two ciphertexts may not convey all the information to reconstruct the two messages. For instance if you have a bit 0 then both messages may contain a 0 at that location or they may both contain a 1. If you have a 1 message 1 may contain a 0 and message 2 may contain a 1, but it could also be the other way around. ...

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