# Tag Info

0

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

0

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

0

Disclaimer: the only reason to go this way is if you have an 8 bit CPU. Otherwise, select AES. Sending nextKey in the data packet is silly. What you want is key + iv. Look up the CipherSaber 2 variant of RC4. This covers the attack used on WEP just fine. Bear in mind though this wants a good RNG (probably hardware RNG) and 10 bytes of iv. Unless you can ...

0

If a given 64-bit sequence is known to be the bit-by-bit XOR sum of the outputs of two 16-bit LFSRs, then the degree-32 LFSR feedback polynomial found by the Berlekamp-Massey algorithm is indeed the product of the (16-bit) feedback polynomials of the two 16-bit LFSRs, and as @poncho said, you need to factor the degree-32 polynomial into two 16-degree ...

6

Well, if we have plaintext^shiftedPlaintext, what we have is the values $P_i \oplus P_{i+k}$, where $k$ is the length of the shift. What does this imply? Well, if we consider the values $P_i \oplus P_{i+k}$, $P_{i+k} \oplus P_{i+2k}$, $P_{i+2k} \oplus P_{i+3k}$, ... we get a chain where, if we guess one of the values $P_{i+nk}$ for some $n$, we can ...

Top 50 recent answers are included