This cipher seems to me to have very significant weaknesses, obvious relation to things we know, and a gradation of approaches, depending on what you know. Consider what if you have chosen plaintext and just want to know the key. Or what if you have probable or repeated words? Etc. Your writeup might want to explore these weaknesses and you might want to use them before trying any general solution. Also, there's a big plus in that you have a head start with an encryption and decryption program (if you find bugs, let me know!). I must say that so far no solutions have been found and I may be wrong about the difficulty. That's why it's a challenge.
Long, long ago, before you were born, Prof. Brown was a postdoctoral fellow at the U. of Edinburgh in Scotland. There was another postdoc there called Nat Nit (not his real name). He was a quiet guy, not given to social intercourse, and in fact seemed a little secretive and unforthcoming. Maybe a little furtive, standoffish? Definitely the sort of person who would read-protect his top-level directory in UNIX. In short, a guy that I probably should have tried to get to know but who instead I just decided not to like very much.
He published a technical report and its acknowledgements looked a little bit something like this:
Naturally this was a challenge. Our computer was made by Imperial Chemical Company (Ltd.). I'm not making any of this up. We had teletype access: those things that electromechanically type on paper. No "glass terminals" yet. Anyway it must be that there was not much concept of file security because without much trouble I found Nit's encryption program. This is OK since as we know with a proper encipherment scheme you don't care if the opposition knows the algorithm; all security lies in the key. This code works. Here it is, itself, running in this very directory: Sample Run .
OK, OK, this wasn't really Nit's program but this is my hopelessly naive Perl version. A real Perl programmer could probably do it in 10 lines. I was about to tell you what it does, but that's not too hard to figure out, so I'll preserve that as part of the challenge. As you can see it calls for a six-figure key, which is used symmetrically to encrypt or decrypt simply by applying it "in reverse" in an obvious way.
In the above reconstruction of Nit's algorithm I am sacrificing some ASCII characters (like blank, comma, and period(!)) so that almost everything is printable. (Maybe you'd like a peek at the ASCII character set in Decimal or maybe more usefully in Octal and Hex . ). Probably the original version used a completely different character encoding, maybe EBCDIC, but it's not important except that as you will see this version replaces blanks with ' , periods and commas with letters, and other infelicities with most non-alphabetic chars upon decoding. Changing a line in the algorithm changes this feature.
Anyway, sure enough, just as I suspected, applying the key (23 56 198 444 3 520) to the above acknowledgements yields (again with added CRLFs);
as you can easily verify. As you see, the periods, commas, spaces, etc. are screwed up but it's readable.
Last, I have to admit that this assignment is a way of reliving and I hope improving a disappointing part of my life, because actually I never broke that cipher, and I'll always wonder if maybe those acknowledgements were actually thanking me for being such a wonderful person and cheery colleague. Nahhhhh....
This input and the next are just one very long string. I hope it's all there! If you have trouble downloading to a file let me know!
This page is maintained by CB.
Last update: 27.07.01.