First let's take a look at some readily observable aspects of the puzzle:
- The algorithm is not disclosed
- The algorithm can be done by hand on paper without the use of a computer
- The ciphertext is readable (albeit a bit Lewis-Carol-esque)
This puzzle presents an interesting situation. On the one hand the puzzle itself is hand-made, without the aid of a computer, and I do not realy consider myself a cryptography expert; so perhaps the code will be cracked quite easily by some smart MIT student or something. On the other hand, although it didn't take long to design the algorithm, I made it pretty tough, and I don't see how anyone could do it! I know it would be beyond my own ability to solve it if I ever came across something similair.
As the title on the challenge page says, strong cryptography may be easier than it looks. This puzzle is intrinsically harder because the problem has changed. Usually you know or can somehow guess the algorithm and are searching for the key. Here you do not even have the algorithm. The puzzle is so ambiguous that you look at it and have no idea where to begin. I could have taken this idea a lot farther than I did. This is an experiment in meta-problems as much as it is a contest.
Cryptography through Obscurity?
Someone pointed out that this puzzle might be called an excercise in cryptography through obscurity. Let's consider what that means on a practical basis. Let's say I want to send a message to Osama Bin Laden. Using a custom algorithm or cipher, I encipher my message and disguise it so well that no one would know by looking at it that it was encoded. Even if the CIA was logging all the email that goes to email@example.com and just knew that the email was a secret message, traditional attacks would be useless. Why? The algorithm is not only unknown, but the message would be just too ambiguous for meaningful attempts at figuring it out.
There is a historical example of this. During WWII, the Germans used a cipher they invented called Enigma. This was a very complex and advanced cipher, but being based purely on technology, it was eventually cracked by the Allies. The Americans hired a bunch of Navajo American Indians and simply used their little-known extinct language as part of a code. Even if the Germans could have figured out what language they were using it would have been almost uncrackable. As it was, no one ever cracked it because the cipher was on another level than what they were expecting, a level which just can't be practically tackled with technology and mathematics.
I'm guessing that in such a case, the old objection to "security through obscurity" simply doesn't apply. This is axiomatically not the same as attacking a piece of software where you have somewhere to start and know areas and points of the program and its design where security holes would be likely to exist. The reason obscurity doesn't work there is that you can never have true obscurity in computer software! Something is always known that gives you a starting point from which to proceed with your testing, probing and deductions, no matter how tight the source code.
Notes on the contest itself
Someone made an intersting point: "If it can be cracked from just one sample then the algo is really weak. But there are weak algorithms which are difficult to crack if you have only one sample and not told what the algorithm is....In effect it's similar to the case of a one time pad - except that it's more of a one time algorithm...In order for a proper evaluation/examination there should be more samples and the algorithm should be provided as well."
Perhaps this guy is correct. I'll wait a bit (just to see if this falls under the first case he mentioned) and then maybe post more examples using the exact same algorithm. If that doesn't help then maybe I'll analyze the tacks some people have been taking and give out a few hints. As I've noted, this is my first shot at a crypto challenge, so I'll augment the contest if somebody raises good points that I hadn't thought of and that warrants a change.
Lastly, I hope all this made some kind of sense ;-)
 We are talking about textual person-to-person level communication here, not machine-to-machine methods such as encrypting TCP/IP packets.
 This is just an example :-)