After (re)watching LEMMiNOâs amazing video on the Kryptos puzzle at CIA HQ, I got inspired to take a small crack at it, if nothing but to push the research ever so slightly forward.
If you are not familiar with the puzzle itself, stop reading this and go watch that video, itâll give you all the background in a much better presentation.
The Plan
The unsolved part of Kryptos, K4, is not a vigenere cipher as far as we know.
Based on frequency analysis, we also know that the ciphertext does not follow the english language distribution for most common characters used. This could be because the text is so short and using uncommon phrases or words, but itâs unlikely- the other attempts people have done indicate that K4 is probably enciphered using multiple cipher phases.
What I mean by that, is that the ciphertext was most likely ran through another cipher, so that the text we see is at least twice removed from the original plaintext.
Given that we have almost 25% of the plaintext already known because of clues from the creator, it bothered me that we are still unable to solve this. I mean, thereâs modern encryption algorithms that arenât secure if you expose enough of the plaintext.
So, the solver I set out to write followed this rough outline:
Basically, weâll take the source ciphertext, feed it through a bunch of different ciphers, and then feed each output into a different cipher, and compare the resulting text with the known plaintext portions we have.
Ideally, if we get a match on the known plaintext, we can identify what techniques we used to gather them.
Using Python
I started coding this by reaching for Python - I figured I could get close to what I wanted based on my prior experience. I coded up some custom functions to perform the actual ciphering/deciphering, with help from Gemini 2.5 Pro.
Then, I tried my best to multi-thread the evaluation function, so this wouldnât be running for months on end.
After I had it running for a few hours, I took a look at my CPU usage and it was abysmally low, barely even breaking 25% utilization:
This wasnât going to cut it. I donât have a cutting edge CPU in terms of clock speed, but I do have 8 cores that I should be making use of in parallel. If I wanted to actually attempt and solve this, I would need to go much faster. It looked like Pythonâs multithreading constraints were actually a real problem in this case, something I couldnât work around without much better knowledge and time.
âJust rewrite it in Rust broâ
Luckily we live in the 21st century, and all the Rust fanatics arenât completely wrong about the speed increases gained from compiling to assembly. Also, even though I had never written Rust before, LLMs were able to handhold me through the process.
So after a few short iterations, I had the same functionality up and running in Rust:
I also had some major advantages with this one. It would:
- Save the index for where it was periodically, so if it got interrupted it could be resumed
- Actually multithread over all 16 threads on my CPU
- Gave an ETA as to how long it would probably take to finish
(Also need to admit, getting Rust up and running to develop with on my PC was actually really easy. Long ago I used to write C# and ASP.NET code, and this was so much easier compared to that, props to the Rust community for great tooling.)
Sure enough, once I had it running my CPU usage pegged at a nice 100%:
A disappointing end
After letting it run for exactly [03:48:36], it had tried every combination of the different ciphers I had outlined, with every 8 letter word in the english dictionary (when attempting the Vigenere cipher), with no matches đ
Deep down I was somehow hoping that the solution would have been as simple as two ciphers used back to back. Which, it is still possible- maybe I just didnât choose the right two ciphers?
All my code is public on my Github repo, extend it or modify it however you see fit.
I hope someone can go beyond where I have tried, and eventually solve this puzzle. Itâs remained unsolved for 30 years, but letâs not give up just yet shall we?