# Tag Info

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

6

One problem with RC4 is that, while it does take a variable length input (up to 256 bytes), it's known not to be great at mixing those bytes together. Specifically, we see correlations between the RC4 key and the RC4 output stream. My first recommendation to you would be to use something other than RC4. About the only advantage RC4 has over most other ...

5

Nobody can tell you not to "have fun with it" but I would strongly recommend you to first study attacks on other ciphers. Spritz (Rivest & Schuldt) fortunately mentions a lot of research on its predecessor, RC4. This makes it a rather good starting point in my opinion. It is necessary to understand the linguistics and mathematical constructs that are ...

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

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

Afaik, the general export restrictions on keylengths of common ciphers were lifted during the Clinton administration. Here's the relevant wiki article.

4

Poncho does a good job of explaining why you could use a KDF before RC4. But you are talking about a password and a PBKDF. A PBKDF does more than just provide a good way to extract entropy from the given input (the password): It uses a salt, which can be used to protect against rainbow tables (which could be created for known plaintext). This salt could ...

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

The correction question you should ask about why various operations in RC4 (or, for that matter, any other cipher) are there would be "if I were to remove that, what would the impact be? Would this weaken the cipher in some way?" At your current state of knowledge, that may be a rather imponderable question, but it is still the correct one. I can try to ...

2

I have looked at some attacks on RC4 and be curious if some of them can be applied to Spritz as well. Does anybody else has analysed Spritz so far? Or is it far too early for results against Spritz? No third party analysis. Probably way too early. (Even the paper you linked is unpublished.) The answer may of course change any time. From the ...

2

NO. Without changing the API, it is not possible to coerce a 40-bit-key or 128-bit-key implementation of RC4 to behave like a 256-bit-key one, because there is no way to inject any key material in the RC4 state after initialization. Dave_Thompson_085 has an interesting comment for OpenSSL specifics.

2

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

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

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

1

Since you already know $K$, you just need to know the length of $H$ based on the hash algorithm you are using, which should be constant, then simply split the output of $D_k$ into the 2 parts of appropriate length. You can then perform the keyed hash on the first part and match it against the last part, which will match if the decryption was successful. It ...

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