So dumbass Alice and dumbass Bob are exchanging Messages. They encrypt the Messages using XOR because they read about one-time-pad on Wikipedia. But because they're dumbasses they share the same Key!
Evghenyi, the drunken Russian, listens in and picks up Ma (Message Alice) and Mb (Message Bob). Knowing that their Messages have been XOR'd with the exact same Key, can he decrypt them?
(For simplicity Ma, Mb and the Key all have the same length.)
Other urls found in this thread:
crypto.stackexchange.com
twitter.com
If they didn't share the key, it would be impossible to decrypt because any possible key could yield any possible message.
If they used the same key, then it becomes merely improbable. Because you have two messages with the same key, you can compare arbitrary keys to both messages and see if non-shit comes out of BOTH encrypted messages. It's a lot like finding a hash collision.
Did I just go back to 1941?
Without some starting info on the message or on the key, brute force would be the only way, and that becomes unfeasible really quickly.
It seems that in theory it's not possible to crack. Considering that you have a system of 2 equations with 3 unknowns, it means you have an infinite number of valid solutions:
PA + Key = CAPB + Key = CB
Where:
'+' is the XOR operation
PA and PB are the plaintexts
CA and CB are the ciphertexts
PA, PB and Key are unknown
cont'd
That's theory, of course in practice things change like said. Alice and Bob aren't sending each other random gibberish, but English words, so that narrows it down. Then the words put together must form a sentence and be meaningful, which narrows it down further. Goes without saying that the longer the messages, the more difficult this gets, especially in cases where words/sentences begin at the same index in both messages.
If I'm wrong, and you geniuses found a way to take advantage of XOR being its own inverse function to crack this, that would be cool!
Read about tunny traffic and thank Bletchley Park for doing the work for you.
One-time pads are unbreakable if they're used only one time. After that the more messages you have the easier it is to crack. With two I'm guessing he'd have to be very lucky to break it.
XOR captured messages result will be XOR of message cleartext.
Separate result with basic frequency analysis.
Without information about message bruteforce is not possible at all, because you cannot say whenever message is decrypted correctly.
thx for the pic kind user !
XOR is commutative and associative, it should be easy for you to go from there op.
Got it.
For this part I'd probably use a 26*26 table (obviously bigger if your alphabet includes numbers, casing etc) of A xor A, A xor B... Z xor Z etc. Of course you only need half of the table, and the diagonal is zero. That might help with the decryption, since you'll reduce each letter position to fewer possibilities.
Holy shit you ignorant twats, what OP is talking about is the fucking Lorenz cipher machine, the methodology has already been perfected 60 years ago.
There are 2 messages with same key, so even without info about message you can keep trying until both messages decrypt to something that makes sense.
With a single message it s completely impossible, of course.
Lazy nigger do your own homework
and this.
How viable are XOR encryptions? I assume they're shit because otherwise they'd be more common. Can someone explain to me why having a message, ex. "Hello world!" XOR'd with a word like "shit" is bad? In a way that would XOR letters individually. For example, 'H' (XOR) 's' in this case would be ';', etc.
Look up what a one time pad is.
If it's not a one time pad (that means the key is at least the same length as the message and completely random), xor encryptions are shit. Otherwise they're literally unbreakable.
For example, let's assume we know your message is plain english ascii text. Then all most significant bits in the message are zero. If the key is shorter than the message, this results in a repeating pattern in the ciphertext's most significant bits, which tells your key's length and also is the key's most significant bits, no calculations needed. Also in plain ascii english, the second most significant bits of the message is likely but not guaranteed to be one. The corresponding bits in the ciphertext might not be a repeating pattern, but as the key's length is already known, we can spot anomalies easily. These anomalies are most likely spaces, punctuation, and digits. So we can tell words apart. The third most significant bits are likely to be one, unless you write your messages in all caps. The fourth most significant one can be deduced using statistics as letters aren't occuring equally frequently. Half your key is broken at this point. The rest can be bruteforced by checking if decryption results in meaningful words.
If your message is not plain ascii text but some binary file, we can hope that your file contains a sequence of equal bytes (for example, a null padding somewhere), which may result in a repeating pattern if it is longer than the key.
I'm sure there are more ways to crack xor encryption but I'm just an uneducated nobody on the internet.
or maybe because they want it to work.
if that's all he knows, obviously no.
Sharing the same key for sending their own messages is not necessary.
wrong
xor is symmetric, by definition
therefore encryption key = decryption key
how can you be this dense
That's not what OP's scenario is about.
There's a misunderstanding. The problem is that Alice and Bob both use the same key for encrypting their own messages. Meaning one key for all messages. If they did it properly they would use two (pre-shared) keys, then the eavesdropper would have to crack two keys (KeyAlice and KeyBob) instead of just one to decrypt all messages.
Ma ^ K = MaK
Mb ^ K = MbK
MaK ^ MbK = MaMb
problem space is reduced to two interleaved texts
when MaMb[x] is 0: Ma[x] = Mb[x]
when Ma[x] is 0: MaMb[x] = Mb[x]
when Mb[x] is 0: MaMb[x] = Ma[x]
MaMb ^ 000... (repeating) = K
key is recover
Upskirting is a decent hobby for a gentleman! ;)
Nit doing your 1932 homework faggot.
