1
$\begingroup$

In my assignment there is a bonus question:

It asks me to decrypt a file which has been encrypted using an One-Time-Pad. But the ciphertext seems to contain english word fragments and other parts which in my opinion should not be in the file if an otp had been used.

The ciphertext seems to be some part of a boot log.

Now this all may have been done on purpose to confuse the students.

My question is:

Does this information help me in anyway to find the plaintext? Would there be another way to find the plaintext, assuming that they did not use a completely random key?

I've uploaded the ciphertext here.

$\endgroup$
  • $\begingroup$ Hi, intrigus, and welcome to Crypto Stack Exchange. Please note that requests for analyzing ciphertext, which your question looks a lot like, are off-topic here. Personally, I think your question may be just barely on-topic, since you seem to be asking how to potentially exploit a non-random one time pad and just using the specific ciphertext as an example, but others might disagree. It might be a good idea for you to edit your question to make it clearer that you're looking for a general answer, not just a solution to this specific exercise. $\endgroup$ – Ilmari Karonen Dec 20 '17 at 0:03
  • $\begingroup$ Also, insofar as the ciphertext is actually useful as an example, it might be helpful if you could include a short fragment of it in your question. Or, at least, could you please use a data sharing site that actually works and isn't loaded with shady-looking ads? I've heard that pastebin is pretty good, for example. $\endgroup$ – Ilmari Karonen Dec 20 '17 at 0:04
  • $\begingroup$ that file is a linux kernel bootloader, it is not encrypted $\endgroup$ – Richie Frame Dec 20 '17 at 1:04
2
$\begingroup$

I didn't actually manage to download the ciphertext you linked to — I'm pretty sure I clicked the real download button, and not the fake one in the ad next to it, but all I got was a long delay followed by an error message, and the site itself looked shady enough that I didn't feel like investigating further. However, since what you really seem to be asking is a general question about exploiting non-randomness in a one-time pad, and since anything else would be off-topic here anyway, let me just try to give a general answer.

A proper one-time pad, as the term is usually used in cryptography, requires each key letter (or byte, or whatever your cipher alphabet consists of) to be chosen independently and uniformly at random from the full cipher alphabet. As a consequence, it follows that the ciphertext will also look like a perfectly random sequence of letters.

While such a random sequence can, just by chance, contain occasional substrings that look like English words, they shouldn't appear significantly more often than any other substrings of the same length. (However, do note that the human brain tends to be good at picking apparent patterns out of randomness, so unless the non-randomness is really obvious, you really should check this with a proper statistical test rather than relying on just your intuition.)

If the ciphertext looks recognizably non-random, it's possible that either:

  1. the key used to encrypt it isn't really random, but might instead e.g. be the contents of some non-random file; or
  2. the encryption process itself might be somehow broken, e.g. some parts of the plaintext might not be encrypted at all for some reason.

In the first case, your situation is basically the same as if you were attacking a two-time pad (i.e. a proper one-time pad with a reused key). Specifically, with a reused key, combining the messages lets you cancel out the key, after which you're left with the XOR (or modular sum or difference, depending on which kind of OTP is involved) of the two non-random plaintexts.

If you're lucky, you may be able to identify the source of one of the plaintexts (e.g. it might be available online), which will then let you directly decrypt the other.

If you're not so lucky, you may be faced with a painstaking letter-by-letter reconstruction process, using crib dragging, intuition and lucky guesses to construct two plausible messages that, when XORed, yield the known XOR of the ciphertexts (or, in your case, the ciphertext itself). While this process can be automated to some extent, in my experience it tends to work poorly without close human guidance, at least unless you have a very good predictive statistical model available for at least one and preferably both of the messages.

Anyway, since this was given as an exercise, I assume it probably is solvable somehow using a reasonable amount of effort. You'll just first have to figure out exactly what's gone wrong with the encryption, to produce such a non-random ciphertext.


Ps. See also:

There are probably other relevant earlier questions on this site, too, but those happened to be ones that I'd answered myself before.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.