Page 1 of 2

Didactic Scrambled Egg Cipher

Posted: Tue Oct 21, 2008 4:22 pm
by MerickOWA
The challenge text is incomplete, unless the problem is to unscramble the pseudocode ;)

Posted: Tue Oct 21, 2008 6:20 pm
by MerickOWA
heh ok, I see the problem now, actually, if you leave it the way it is, it might be more 'interesting' (depending on your browser ofcourse)

the flip array isn't defined, and unless its a bug they key variable is never used.

Posted: Tue Oct 21, 2008 6:26 pm
by MerickOWA
maybe it would be better if you posted the encryption algorithm in a language like java or something so that you can be assured that questions about exact byte order or custom arrays are easily answered.

As these problems get more complicated, I can see it getting harder to explain the algorithm without just giving all the details of each function or line of code.

Posted: Tue Oct 21, 2008 8:44 pm
by tails
key is a 16-byte value and flip has 16 elements, so flip are 8-bit independent values ...?

If so, this challenge should be very tough!

Posted: Tue Oct 21, 2008 10:17 pm
by MerickOWA
tails wrote:key is a 16-byte value and flip has 16 elements, so flip are 8-bit independent values ...?

If so, this challenge should be very tough!


O that seems very likely. Yea, this will be an extremely difficult challenge. 128 bits of possibilities ><. Maybe at least could we hope that flip is some permutation of the 0-15 (meaning no repeats or duplications of numbers)

Posted: Tue Oct 21, 2008 11:14 pm
by adum
sorry about the mess... added that one late last night while tired, and didn't check it thru carefully.

should be better now. flip was meant to read 'key'.

good luck!

adum

Posted: Wed Oct 22, 2008 4:15 pm
by MerickOWA
adum wrote:sorry about the mess... added that one late last night while tired, and didn't check it thru carefully.

should be better now. flip was meant to read 'key'.

good luck!

adum
Is it safe to assume that "print eggs;" prints out a hex encoded number with the most significant byte (of the three) first?

Or to put it another way, is the first encoded "eggs" 0x0043ed82 or 0x0082ed43?

Also just to be clear on "for (int eggs = {each 3-byte tuple in plaintext})"

If the plain text bytes were (in order from least significant to most significant) {0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff, ... }

would eggs start off being 0x00ccddaa the first time around and 0xffeedd the second time around?
OR
would eggs start off being 0x00ccddaa the first time around and 0xddccbb the second time around?

Posted: Wed Oct 22, 2008 7:44 pm
by adum

Is it safe to assume that "print eggs;" prints out a hex encoded number with the most significant byte (of the three) first?
yes.
Also just to be clear on "for (int eggs = {each 3-byte tuple in plaintext})"

If the plain text bytes were (in order from least significant to most significant) {0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff, ... }

would eggs start off being 0x00ccddaa the first time around and 0xffeedd the second time around?
OR
would eggs start off being 0x00ccddaa the first time around and 0xddccbb the second time around?
eggs would first be 0x00aabbcc, then 0x00ddeeff. and there is no feedback between the first tuple and the second.

Posted: Wed Oct 22, 2008 9:27 pm
by MerickOWA
I really don't see much hope of this problem being solved ><

I'm not even sure I could solve the problem if i knew the first half of the sentence! ;)

Possibly if LOOP wasn't so high, and there wasn't several bytes of key overlapping each bit of the "egg" variable, it might be possible.

This is one evil problem! ;)

Posted: Wed Oct 22, 2008 9:57 pm
by adum
in the original cipher, the LOOP was 1000 =)

i played around with it. at lower than 10, it barely looked scrambled. i guess i can put on a simpler version just for people to get their feet wet...

Posted: Wed Oct 22, 2008 10:23 pm
by falcon2424
I don't know if figuring this out is part of the challenge, but how are you defining the << and >> operators?

I'm assuming that they're just left and right shifts, where zeros are inserted when new bits are required, but I want to double check. (Wiki says that '>>' is implementation defined)

Posted: Wed Oct 22, 2008 11:05 pm
by adum
I don't know if figuring this out is part of the challenge, but how are you defining the << and >> operators?

I'm assuming that they're just left and right shifts, where zeros are inserted when new bits are required, but I want to double check. (Wiki says that '>>' is implementation defined)
just so: like in C.

Posted: Sat Oct 25, 2008 1:48 am
by therethinker
I'm with MerickOWA on this one, its looking pretty tough. I can't believe this is the "warmup"! :shock:

The only solace I can find is that you're given every 1 in 3 key "code nibbles", and a single bit of another.

Overall, I'm loving these didactic challenges (especially since crypto is a bit of a weak spot for me) Although, you might want to start moving somewhere else ;-) There's all those castles/forts down at the bottom that might be worth invading :-D

Posted: Sat Oct 25, 2008 5:20 pm
by MerickOWA
therethinker wrote:I'm with MerickOWA on this one, its looking pretty tough. I can't believe this is the "warmup"! :shock:

The only solace I can find is that you're given every 1 in 3 key "code nibbles", and a single bit of another.

Overall, I'm loving these didactic challenges (especially since crypto is a bit of a weak spot for me) Although, you might want to start moving somewhere else ;-) There's all those castles/forts down at the bottom that might be worth invading :-D
Yea, and I'm having a hard time even knowing that to figure out the key. I think i've got about 14 out of the 128 bits, and anytime I try to guess at the others, it never makes any sense.

Posted: Sat Oct 25, 2008 7:48 pm
by therethinker
You can also make confident guesses for several more.

This challenge is looking to be more paper & pencil, or at least a significant portion of it.