2

This is a school challenge. Given an encrypted file (which is an audio file) I need to figure out how I can decrypt it. Don't have a key, of course.

Now the clue is that I have a small part of the original plain audio file, but I do not know from which part of the encrypted file it is aligned to. I also know the byte size used for encryption is 16 bytes. So my questions are, if you can give me the ideas:

  1. I believe trying to break the key by plaintext attack or bit flipping on the full encrypted file would be too much.
  2. How can I compare the 16-byte blocks in the small plain file with the blocks in the encrypted file, to spot the pattern that can help me figure out the key used for encryption? How do I even get the key even if I know "these 16-bytes in the plain file are these 16-bytes in the encrypted file"? How does that even help? But there is some point to it otherwise the challenge would not have given it.
  3. Is there any other way to approach this? Thank you.
user11672881
  • 35
  • 4
  • Is it possible to convert your small part you are given to an array and use a loop to compare it to segments of the target file by incrementing the position of the array comparison by one for each loop? – TheDataScienceNinja Nov 04 '22 at 20:16
  • Sure it is, but the file I have is plain file and the other one is encrypted, so the comparison would not make sense, right? – user11672881 Nov 04 '22 at 20:21
  • This seems to be an audio version of the famous ECB penguin example. Information is obtained in the penguin case by displaying the ciphertext as an image. In your case, you would need to convert the ciphertext to audio and listen to it. Perhaps when you do so it might remind you of e.g. "happy birthday" in which case that is your decryption. – John Coleman Nov 04 '22 at 20:22
  • Interesting indeed! But when I listen the encrypted audio file it is just a noise. The plain file is 2 seconds and voices no key for sure. Am I correct if I say that since I have a plain file and an encrypted file, I essentially have a dictionary, or part of it. I can then try to align it in 16-byte blocks with the encrypted file and try to see if I can match the bytes on both sides, or something similar? But how do I even know when I get it right, since it's not a text but an audio file? – user11672881 Nov 04 '22 at 20:31
  • Thanks a lot again. Here's my idea: I have the plain file of 20 Kb, and the encrypted file is around 550 Kb. I move through that file with offset of 16 bytes and each time I try to map how the bytes in my plain file maps to bytes in the encrypted file. Then I use that mapping to decrypt the rest of the encrypted file. Can this be the solution? I do not have to attack the key, but with the small plain file I actually have a map to some unknown same part of the encrypted file, and since ECB always maps the plaintext to the same cipher text (which is its weakness), then this must be the solution? – user11672881 Nov 04 '22 at 20:57

1 Answers1

1

Given a window of 20kb, break it into 16 chunks. If the 20kb of plaintext is not exactly a multiple of 16 bytes, truncate the end of it. Generate a vector of length 20kb/16 = 1280 numbers as follows: assign 0 to the first block. Store it in a dictionary keyed by the block and whose value is the index 0. Move on to the next block. If it is the same as the first block -- assign 0 to it. Otherwise assign 1 to it and create a second dictionary entry. Iterate over the blocks. For each block you check if it is in the dictionary. If it is -- assign to it the value of this entry. Otherwise increment the last index used and create a new dictionary entry.

The result will look something like [0, 1, 2, 3, 1, 4, 2, 5, 6, 7, ...]. This can be thought of as a statistical profile of the plaintext.

Now have a sliding window of width 20kb move over the ciphertext. For each window, compute its statistical profile (perhaps it can be updated rather that computed from scratch as the window slides). Eventually you will get a window with the same profile as the plaintext. You now know (with high probability) where the plaintext is within the ciphertext. This will give you up to 20kb of known plaintext-ciphertext blocks. Hopefully that will be enough.

The basic logic can be understood in the context of simple substitution ciphers. The word MISSISSIPPI would have profile 0 1 2 2 1 2 2 1 3 3 1. If it were encrypted with a substitution cipher it might map to e.g. XQTTQTTQKKQ -- which has exactly the same profile. If you knew that a given ciphertext contained an encryption of MISSISSIPPI, you could slide through the ciphertext in windows of width 11 until you found a window with the right profile. At that point you would know the ciphertext equivalents of MISP, which will give a partial break into the system. AES ECB is basically just a substitution cipher (albeit one on a much larger alphabet) so the same basic logic applies.

John Coleman
  • 51,337
  • 7
  • 54
  • 119
  • Thank you, had a similar idea. Cipher text is an audio file, so I do not know any text or pattern that I can map. My idea was this: I think the 16 byte blocks in the plain file would be encrypted as 256 byte in the cipher file (so 16 x 16). I can move in offsets by 256 bytes, and at some point that block starting from there having len of 20Kb * 256 bytes would be a chunk to map to the plain file. I just don’t know when is that. So each time I slide by offset I map the bytes and try to decode the file, then calculate the hash of that file (since I know what hash should be).Does this sound fine? – user11672881 Nov 05 '22 at 21:24