# Tag Info

21

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

6

Wanted to expand on my comment as an answer. The KSA in RC4 permutes the bytes [0,1,...,255] using a key, say $k_u$. For any permutation of these bytes, there exists a key that will get you that permutation. The idea you outline is basically to start by permuting the bytes [0,1,...,255] according to some fixed initial permutation, then permuting the bytes ...

5

RC4 has several known weaknesses, including: Rather strong biases in the initial parts of its keystream Weaker biases in the rest of the keystream. Now, RC4 does take a variable length key, potentially up to 2048 bits (256 bytes). So, if you wanted, you could take a 2048 bit RSA modulus, and use that as the RC4 key. However, doing so would not affect ...

5

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

4

I'm happy to have a crack at this one, providing I've understood your question correctly. Firstly I wouldn't say the cipher possibly exhibits low level bias at any point. It experiences plenty of bias and I'll attempt to explain how we can use it to launch practical attacks. As I'd imagine you know, the strongest bias is found right at the start of the KSA, ...

4

To build on mikeazo's answer (since it's not really practical to post code in comments), here's a quick Python program that takes any two permutations of $\{0, \dots, 255\}$ and generates a key that transforms one into the other when run through the RC4 key setup: # source and target permutations s = range(256) t = [181, 172, 179, 178, 177, 168, 175, 174, ...

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

It can be attacked in the same way, but not as efficiently. The RC4 "NOMORE" attack (pdf), for example, uses both Fluhrer-McGrew biases, which are biases towards certain pairs of values in certain positions, and Mantin's "ABSAB biases", which are repetitions of bigrams. Both of those biases will survive a XOR of two keystreams, but will be less frequent. A ...

3

The reference definition of Spritz seems to be: Ronald L. Rivest and Jacob C. N. Schuldt, Spritz - a spongy RC4-like stream cipher and hash function, presented at Charles River Crypto Day (2014). The code snippet of the question shows how the state of Spritz repeatedly used in DBRG output mode is updated and its next output byte $z$ produced; the state ...

3

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

3

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

3

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

2

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

Part of the problem you're having is that there are multiple distinct vulnerabilities in WEP, and you're getting confused by the sheer number. For example: I still don't have an understanding of how one might exploit [repeating IVs] to retrieve the key Answer: those are two separate vulnerabilities. The shortness of the IV space is an obvious ...

1

It seems that because it uses a initialization vector of 24 bits, which is relatively short, is easy to determine which key was used to encrypt the data. Actually, it's not the shortness of the IV that does cause the key leakage (although it does cause other problems). Instead, it's due to how WEP combines the IV and the key, and then how the RC4 key ...

1

You're given $c,p$ and are challenged to find $k$ using the relation $c=p\oplus k$ (where $\oplus$ denotes bit-wise XOR). As the inverse operation of XOR is, well, XOR, you can recover $k$ by computing $k=p\oplus c=c\oplus p$. You may be wondering a) why is XOR the inverse of XOR and b) why is XOR commutative (e.g. $a\oplus b=b\oplus a$). For b), we ...

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