# Would it be possible to create a game where one would need to decrypt a simple encryption?

This might sound pretty weird, but I was thinking of a game a person could play alone with a pen and paper.

I got this idea where the person would write a random four letter string on a paper, and would have to decode it. There would be a mean to verify if the person is getting closer to the goal or not. So, I decided to ask here.

Do you think it would be possible to create a simple game where one would have to decrypt a simple string (a bit like the BitCoin miners do, I guess?), where there would be a logical next step from every point during the decryption and where it would be possible to verify if the contemplated logical next step brings the player closer to the solution or not.

Similar Question: Toy encryption system that provides "hints"

Interesting, but not-quite-it option: Vigenère cipher (Wikipedia article)

-
Random four letter? It sounds like you're easily coming up with something similar to Mastermind, with some cryptotwist. –  user4982 Jan 16 at 20:53
Monoalphabetic substitution is a form of encryption. Many newspapers publish such cryptograms. –  Brock Hansen Apr 18 at 20:59

Define encryption as $ax = b$, for message $a$ and key $x$, then you have $a = {{b}\over{x}}$, so decryption corresponds to the long division algorithm. At each step you can verify a guess for the solution, $a'$, by computing $a'x - b = 0$.

If you don't want a key, how about computing roots: $x^2 = b$. A very similar iterative procedure where you converge on the solution, $x$, by repeated guessing to find the inverse function, $\sqrt b$.

-
Good idea, but too simple. –  Slackware Dec 17 '13 at 19:44

Caesar cipher? Its a simple substitution cipher where you can solve with just a pen and paper.

Encryption is done by shifting each plaintext letter, x by n places the alphabet or mathematically, ENCRYPT(x) = (x + n) mod 26. Similarly, the decryption will be the reverse, DECRYPT(x) = (x - n) mod 26. (see wiki http://en.wikipedia.org/wiki/Caesar_cipher#Example)

So, you get a friend to pick a random n and compute the encryption for a randomly chosen four letter string (using free online calculators like http://online-calculators.appspot.com/caesar_ext/). You should not know both n and the plaintext. But the plaintext should be some english word or equivalent in order for it to make sense when you decrypt.

Then, you start the decryption process by trying out all possible values of n until the decrypted plaintext is make sense. If your first two/three decrypted alphabets is not an valid word, that means your chosen n value is wrong and you should try another n.

-
What about that partial verification in the protocol OP needs? You haven't answered that in any way, while OP explicitly asks for a solution to that. Simpler said: currently, your answer does not really answer the question. But, I am pretty sure this could become a nice answer if you would also add some words about the verification part OP needs (and asks for). –  e-sushi Dec 17 '13 at 6:37
This looked like a good answer, but I was looking something perhaps a bit more complex. Also, it was meant to be a single-player "game," so the hash should be generated by the player. –  Slackware Dec 17 '13 at 11:44

I'm guessing "No" for good encryption/hash algorithms where being even one bit off key or cycle results in garblygoop.

If this is just for the fun of the game, hash the garblygoop after each step and append that hash.

foo
fooGarbly = encrypt(foo|fooHash)
fooGarblyGarbly = encrypt(fooGarbly|fooGarblyHash)
fooGarblyGarblyGarbly = encrypt(fooGarblyGarbly|fooGarblyGarblyHash)


Each step would be best as a single stage of some non-impossibly-large possibility, like an XOR with a single byte.

I mean I assume the idea is to have this game be fun, so positive re-enforcement within our lifetime?

So a stage that could take to long to complete, like a permutation of a base64 alphabet could result in people just getting frustrated and quitting. (for good reason)

-
Ach, your answer seems interesting, but I don't understand it... –  Slackware Dec 17 '13 at 20:18
Well an easy way to tell if you are getting closer to the original value of foo would be to append a hash after every step in the encryption. So you can check the hash to the encrypted string and if they match, they you're one step closer to foo. –  Andrew Hoffman Dec 17 '13 at 20:45
Alright, so basically this is a way of verifying that the next logical step brings the player to the answer. But this isn't a game in itself, it's just the method which would be used in a game. This answer that you're providing is not specifying any moderately simple encryption method. –  Slackware Dec 18 '13 at 14:07
en.wikipedia.org/wiki/XOR_cipher About as simple as it gets. The problem you'll run into with any encryption method is that, as far as I know, you won't be able to know if you're warm or cold until you've finished. –  Andrew Hoffman Dec 18 '13 at 14:20