Sunday Decryption Challenge - difficult but possibly trivial

Inspired by TheIdeasMan: http://www.cplusplus.com/forum/lounge/108371/

https://www.dropbox.com/s/s58fjz7oqrme0pn/encrypted.dat

- The message is an English sentence
- Start at 0,0 and wrap around after 15
- There are only 5 instructions
- There is randomness involved but every byte has a purpose

No other encryption or compression is used, this is something I invented a few years ago. It's not really effective if you know how to break it. I don't think you could do it by hand, but you will need a table.

If this takes a long time to solve I'll post the program I used to generate it (it only encrypts though because I just threw it together quickly).
Last edited on
Ok then, here's the program that encrypts messages:
https://www.dropbox.com/s/dagxt9hs1hx39cq/LB_Encryptor.exe
use the arrow keys to select a character and spacebar to add that character to the message.
How about you give us the source code, pseudocode and full documentation instead of a mere trojan? [/semi-joke]
It wasn't written in C++, that would have taken too long - it's just a simple app that I threw together in under ten minutes :p if you're willing t pay for the software that I made it in you can definitely have the source.
Now I'm curious, what software did you use to make it?
Multimedia Fusion 2: https://www.clickteam.com/
@ LB: When you say "Wrap around after 15" are you telling us that the key is 15 characters long? Also, by "There are only 5 instructions" do you mean that there are 5 layers of encryption? Sorry Crypt-analysis is an on again off again hobby for me, I'm not too familiar with the terminology.
Last edited on
@ LB: You seemed to have forgotten to filter for control characters. This isn't even reversible, never mind crackable.
The key is that 16x16 grid in the application (does 15 sound familiar now?). And I don't know what you mean by control characters. I can easily write an application to reverse the encryption. If you don't figure it out I might even write it in C++ :p
Last edited on
@ LB: OK, I'll give in. I actually stopped trying at this sometime last night and haven't been able to build enough interest to go at it again. To me it looks like a bad cipher, its not that it doesn't encode the same character the same way twice in a row since I expect someone at your level would be seeding it anyway. My problem is that it doesn't encode them to the same length every time, which is why I suspect you did not filter out control characters such as 'delete' from the possible output. I even tried to account for white space being part of the cipher but either I am really bad at this or your "code" isn't reversible. If you did do all of this on purpose though, let me say that I thought it was a pretty good idea to put EOF in the sample output you provided, that one had me going for a minute.
Last edited on
It doesn't encode the same length because you're not using the same combination of arrow key presses :)

I'll write the decryptor in a moment...
Last edited on
I think I tried that already, I know you're seeding it with something else besides keyboard strokes (maybe mouse movements?) either that or you're not accurately counting the number of arrow key presses (less likely).

The test I did wasn't to in depth, I simply output the first character, null, then renamed the resulting file and did the same thing again. In Notepad++ the first file displays as "GS" and the second one is a "xEO", which I could translate to their integer values and look up in the ASCII chart to see what they are but I have already seen enough to know that the cipher isn't consistent.

I tried something similar with 'A' using the same key presses, but that doesn't even encrypt to the same length consistently so I must be missing something.
Try decrypting each of your tests:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
#include <iostream>
#include <fstream>
#include <limits>

int main()
{
	signed x = 0
	,      y = 0;
	std::ifstream in ("encrypted.dat", std::ios::in|std::ios::binary);
	char op;
	while(in.get(op))
	{
		switch(static_cast<unsigned>(op) % 5)
		{
		case 0: //right
			++x;
			if(x > 15) x = 0;
			break;
		case 1: //left
			--x;
			if(x < 0) x = 15;
			break;
		case 2: //up
			--y;
			if(y < 0) y = 15;
			break;
		case 3: //down
			++y;
			if(y > 15) y = 0;
			break;
		case 4: //select
			std::cout << static_cast<char>(x + y*16) << std::flush;
			break;
		}
	}
	std::cin.ignore(std::numeric_limits<std::streamsize>::max(), '\n');
}
It works for me ;)
OK, so I gave up way too early then and I probably should have looked at your clues a little better. I see what you did here. When you mentioned the wrap around after 15 I was expecting a straight forward Vigenère or a Key cipher which is why I got suspicious when I noticed the control characters. But you wouldn't need to filter for them in this case (But I noticed you swapped them out for white space anyway). You win this round.

EDIT: Does anyone thing it would make things too easy if we named the type of cipher? Not like the length of the key or anything that would immediately give it away like that.
Last edited on
Computergeek01 wrote:
(But I noticed you swapped them out for white space anyway).
That's not my doing, that's just how the Windows console represents control characters.

Also, I'm not really into encryption or cyphers that much, this is the only encryption I am really familiar with because as far as I know I invented it (or at least came up with the idea independently while it was already invented) so you probably know a lot more than me.
Last edited on
Out of curiosity, how strong is this encryption? There's some factors to consider here. In my example there are five instructions, and I take he remainder of division from the randomized value to get which instruction it is. I cold use any set of numbers for each kind of instruction, and I could also have nop instructions and backspace instructions, shift instructions, etc. or even multiple bytes per instruction. I could also change the character grid so instead of 16x16 of the usual ASCII chart, it could be scrambled. Therefore the key would be the chart used and also the instructions and their values.

How strong then could this encryption be?
Topic archived. No new replies allowed.