The scope of this article is to present the one time pad cipher method and its biggest vulnerability: that of the many time pad.
The one time pad: what it is and how it works
The one time pad is the archetype of the idea of stream cipher. It’s very simple: if you want to make a message unintelligible to an eavesdropper, just change each character of the original message in a way that you can revert, but that looks random to another person.
The way the one time pad works is the following. Suppose is the clear-text message you would like to send securely, of length . First, you need to generate a string of equal length . Then, you can obtain a cipher-text version of your message by computing the bitwise XOR of the two strings:
The best thing is that decoding is just the same as encoding, as the XOR operator has the property that (and that ). The only difference is that the cipher-text is involved in the XOR, rather than the clear-text:
Below is an example of the one time pad encoding achieved with Python, with a made-up pad string.
In the first section, result holds the XOR result. In the second part, the result and one_time_pad variables are XORed together to obtain the original plain-text message again.
It is not difficult to realize that the whole strength of the algorithm lies in the pad. Of course, as an attacker, if you can obtain in some way, then it is not difficult to get the clear-text message from the ciphered one as well.
For a challenge in a university security class, I was given this file to crack: reverse1. I started with reverse0, which was considerably easier than the second one. In this post I will briefly explain how I tackled reverse1. I provided the files so you can you try on your own and then came back for hints if you are stuck! If you are new to this business, as I relatively am, I advise you to start from reverse0 and crack that first.
Hashes of reverse1 file:
MD5 – c22c985acb7ca0f373b7279138213158
SHA256 – cd56541a75657630a2a0c23724e55f70e7f4f77300faf18e8228cd2cffe8248e
Disassembling and hoping for the best
The first thing I did was to disassemble the file with Radare to have a look at the code.
#In a terminal
r2 -A ./reverse1
The assembly is quite jumbled up, and difficult to analyse all together. A quick look tells us that trying to crack the file just by reversing the assembly is no easy task, and actually a silly idea to begin with. There’s a cycle after the password is read from standard input, then some other instructions, then another cycle… it’s difficult to get what is going on…
Instead, let’s seek the Bad password print section, and see what should happen for the code to jump there. If we are lucky enough, we may find a bunch of final checks that will send over to the Bad password section. If we can find those, we may then look at those bits of assembly to understand how to avoid going there.
Scroll down enough, and down at the bottom I can see the Bad password part, starting at 0x080484f0.
Radare helps in showing two different arrows going into this address. The related comparisons are the following: