Page 1 of 2
Didactic XOR Long Cipher
Posted: Tue Nov 04, 2008 11:46 pm
by Lysander
I just solved the Didactic XOR Cipher 3. It took my computer about 3 seconds to calculate all 65536 possibilities and finding the right one.
But in the Didactic XOR Long Cipher I would have to calculate about 4.3 billion possibilities! Even if I consider that my CPU was in dynamic clock signal frequency state and I graciously assume 100,000 calculations per second it would still take me about 12 hours to run through all possibilities. Well, I hope that the right combination is in the first half, but still it will probably take hours.
I would like to ask someone who has already solved this challenge: Did it really take hours to find the right values? Or is there something I have missed?
Posted: Wed Nov 05, 2008 12:25 am
by gfoot
Some challenges do take days to solve, but in most cases there are shortcuts of some kind. Usually the challenge is to think around the problem, and break down its complexity, rather than just to come up with enough CPU time to brute-force it.
So I think you should generally look harder for shortcuts yourself - that's half the fun - rather than ask if there are any. I won't say whether there is one or not in this case. Maybe by the time you've convinced yourself there's no shortcut, your brute force solver will have finished anyway!
Posted: Fri Nov 07, 2008 11:56 am
by stingr4y
Solving it manually (without computer) with an ascii table took me about 45 minutes
Posted: Fri Nov 07, 2008 7:23 pm
by CoreEvil
You can instruct your brute force algorithm to stop and move to the next iteration when a certain criteria is not met, the choice of criteria varies from one person to another, you can be very liberal or very conservative, the more intelligent your choice the less time it will take you to decipher the message (it can take seconds)
Posted: Sat Nov 08, 2008 2:39 pm
by Hawkeye
Nearly like stingr4y. Took me 70 minutes to solve with excel
Posted: Fri Nov 28, 2008 10:35 am
by lukas
not need to calculate all posibilities, I also tried first this way but it was for me to long xD
one hour of each variable testing and I was having it
Posted: Fri Nov 28, 2008 2:55 pm
by m!nus
trying through all 4 bytes of the key could indeed take long. i solved it with a lot less "tries" (about 1000)
Posted: Thu Dec 25, 2008 12:59 am
by Belriel
I also tried it with brute force first but was too slow and I had an error somewhere so after all the time there was no result. I went to bed then and kept thinking of the problem and I then found a much more efficient way, tried it the next day and it cracks the cipher in 2 seconds
.
Posted: Fri Jan 09, 2009 2:15 am
by higgs
I made 4 lists which each contained every 4th caracter (so that all the chars with the same key were together). Then I got all 255 possibilities for each key and I looked at the list for which result only featured mostly lower case letters and no weird mumbo-jumbo such as `nj/hzf/v/l. There was generally just one result that met that criteria so I could take an educated guess that it was the right byte. Then I only had to put them in order and violĂ !
Solved by hand
Posted: Sat Jul 04, 2009 2:03 pm
by Cobruto
Solved it with cryptool, with the analyse function, and adjust it by hand. Wasn't that hard. only made one small mistake with uppercase/lowercase. Took me 10/15 minutes.
Cya,
CoB
Posted: Thu Jul 09, 2009 6:07 pm
by Aldreyu
i splitet the string so i had 4x 1Byte chipher...
then wrote a programm that test all compinations 4*256 and display it when the chars in ascii make sense... 30mins i had...
Posted: Tue Sep 08, 2009 10:58 am
by chenkai036
I split the encrypted text into 4 parts as follows.
s[0] = txt[0] txt[4] txt[8] ...
s[1] = txt[1] txt[5] txt[9] ...
s[2] = txt[2] txt[6] txt[10] ...
s[3] = txt[3] txt[7] txt[11] ...
If we define key as k[0] k[1] k[2] k[3] for representation, we could find the k is only XORed with every elements in s. So It is easier to check only 256 possibilities for every k of key.
Posted: Tue Sep 08, 2009 1:47 pm
by Yharaskrik
Hello,
there is a "Challenges Solved" forum...
Posted: Fri Oct 30, 2009 2:05 am
by DaymItzJack
Sorry this might be a little late, but my program solved it in 3 seconds. There are ways to narrow down the possibilities.
I still had 4 nested loops however in each loop I made sure the first few characters were real letters (abcde..) to continue looping. Then I looked for words I thought might be in the encrypted message and I got it.
smart brute force
Posted: Mon Aug 15, 2011 10:23 pm
by compudemon
rather then incrementing the key i used
p=p%4
if p==0 : a=((key&0xff)+1)&0xff; b=key&0xffffff00; key=a+b
elif p==1 : a=((key&0xff00)+0x100)&0xff00; b=key&0xffff00ff; key=a+b
elif p==2 : a=((key&0xff0000)+0x10000)&0xff0000; b=key&0xff00ffff; key=a+b
else : a=((key&0xff000000)+0x1000000)&0xff000000; b=key&0x00ffffff; key=a+b
where p was a location in the string where the code found a character it didn't like
if val<32 or val>126 or (chr(val) in "&*~/{}[]=+_^%@$-`\\<>|#") : err=1; break
despite using this in a loop the answer was nearly instant. this method could be done with 4 loops one for each of the 4 bytes in the key i used one loop and broke the bytes with masks