This post, and the programming it contains, were some of the first programming I ever did. As a result, they’re really quite bad. I include it for posterity, and because it’s funny.
In high school I used to use a Wordlock on my locker. It had four dials of ten letters each, and each ring rotated independently. Predictably, one summer I returned to school to find that I had forgotten my combination - one of a thousand possibilities.
But not probabilities. There were a few caveats. Most of the words that could have been formed (
WQRX) were unlikely. I had the advantage of knowing that I would have chosen a real word (
OXEN) rather than a jumble of letters. I figured the 1000 possibilities could be narrowed down to just a few (~100) probabilities, and that a little scripting would do the trick.
I had been learning just a little bit of Python over the summer and this challenge seemed like the very definition of a real-world application. It was combinatorics, arrays, recursion, and language analysis. I found the Enchant module for Python (although, in retrospect, just a simple check against wordlist.txt would have done the trick).
After a standard preamble, I wanted to create a structure to approximate the physical structure of the rings on the real lock. My ring function took the alphabet and turned it from a straight string of characters into an array of string literals.
The four rings ran
[k-t] again, respectively. I assigned four ring arrays using the ring function.
Then came the combinatorics. Using every possible combination of the four rings, I wanted to compile the string literals back into a word, check the word against a dictionary, and, if it was a real word, print it. Despite there being a thousand combinations, there were rarely more than about 50 words.
Using this method, I found my combination (
NEXT) almost immediately from the list of twenty or so words, but the thought occurred to me: what if there had been fifty words to sift through? A hundred?
The next thing I did was to write a frequency generator. I compiled a few large, well-known texts off Project Gutenberg (the Declaration of Independence, Sherlock Holmes, Leaves of Grass, Huckleberry Finn, and Ulysses - that seemed to cover all my bases) and wrote a script to strip the text of punctuation, divide it by spaces into words, and create a table with each word and the number of times it appears in a good sampling of the english language.
The script took nearly no time at all to run, and it gave me a pickl’d version of the dictionary class I could import later into another program without having to run lockpick_freqgen.py all over again. The next step was to take my list of candidates and reorder them by frequency.
Once the dictionary (not the Enchant english-language dictionary, the python-array-classification dictionary) was imported, every word in the candidates was checked against the array and sorted into a new list by frequency; words like
this went to the top, and words like
tank went to the bottom. I assumed (hopefully with some degree of accuracy) that the words most likely to be chosen for a word lock would fall somewhere near the middle-top; not too likely, but not seriously obscure either.
The general workflow was to take the 1000 possibilities, reduce them down to far, far fewer probabilities, and sort them byfrequency in the hopes of finding the correct combination sooner than later. There were a few implicit assumptions, however:
- That the combination would have meaning. (WQXR rather than XRQW)
- That the combination would be a real word. (WOOT rather than WQXR)
- That the word would be in the dictionary. (FORK rather than WOOT)
- And then a final hope that the word would be a likely one.
As it turned out, the script worked nearly perfectly, running in under five seconds total and figuring out my combination nearly immediately. However, there were a few issues:
The scripts were written very early on during my Python learning curve, and are thus clunky. They do array manipulations that could have more easily been done with mapping or list comprehensions, they juggle strings and string literals, and they’re actually pretty slow. Compared to the far preferable grep-based solution, five seconds is abysmal.
They make assumptions. In a real cryptographic situation, this would be a last-ditch effort, hoping the password was truly
password rather than
The scripts were distributed. They did in three scripts what should have been just one. This is because I wasn’t sure of the exact terms and conditions of the problem I was working on, and I wasn’t confident enough to risk damaging the first step in the process to add the second step in the same script. There’s lots of juggling of text files and pickled dictionaries and the like. To my further shame, I learned a few weeks later that regular expressions (of which I heard much but understood little) were designed to handle exactly these sorts of problems. With 20/20 hindsight, opening up a terminal and entering
would have done the trick about a million times faster, but that wasn’t the point, was it?