Return to Unfiction unforum
 a.r.g.b.b 
FAQ FAQ   Search Search 
 
Welcome!
New users, PLEASE read these forum guidelines. New posters, SEARCH before posting and read these rules before posting your killer new campaign. New players may also wish to peruse the ARG Player Tutorial.

All users must abide by the Terms of Service.
Website Restoration Project
This archiving project is a collaboration between Unfiction and Sean Stacey (SpaceBass), Brian Enigma (BrianEnigma), and Laura E. Hall (lehall) with
the Center for Immersive Arts.
Announcements
This is a static snapshot of the
Unfiction forums, as of
July 23, 2017.
This site is intended as an archive to chronicle the history of Alternate Reality Games.
 
The time now is Tue Nov 12, 2024 8:05 pm
All times are UTC - 4 (DST in action)
View posts in this forum since last visit
View unanswered posts in this forum
Calendar
 Forum index » Diversions » Perplex City Puzzle Cards » PXC: Silver Puzzle Cards
[PUZZLE] #251 - Silver - The Thirteenth Labour
Moderators: AnthraX101, bagsbee, BrianEnigma, cassandra, Giskard, lhall, Mikeyj, myf, poozle, RobMagus, xnbomb
View previous topicView next topic
Page 2 of 35 [518 Posts]   Goto page: Previous 1, 2, 3, 4, ..., 33, 34, 35  Next
Author Message
BrianEnigmaModerator
Entrenched


Joined: 05 Oct 2003
Posts: 1199
Location: Pacific Northwest

If anyone wants to look at the actual RC5 spec (it is not too terribly long, but very mathematically/algorithmically dense and includes C samples), you can find it in RFC-2040.

Edit to add: I have a little piece of code from Schneier's most wonderful book that I have butchered up a little to try to solve this. My modifications are not the cleanest in the world and there are lots of bits commented out as I tried one thing, then another. Basically, going on the following assumptions, I was unable to come up with a solution.

1) That my code is correct. Most of the computer cryptography I have worked with in the past has been fairly high-level PKI. I believe I tweaked the correct constants to adjust for the proper key bytes, etc, but am willing to admit that I may be wrong.

2) That the key is ASCII text and in my system dictionary (while adding a few custom words like "PerplexC" and the street names found on the back of the card). This is probably not a valid assumption. It is likely 8 bytes of binary. I did try the key from the RSA challenge, but that did not turn up anything useful.

3) That the result is ASCII text (I also allow for carriage return and linefeed).

So, if anyone wants to take a look at the code, it is attached. There are three different rotateKey() functions, one to pull words from a dictionary file, one to rotate through all possible ASCII, and one to rotate through all possible alphas. I am running the plain-letter rotations now, but have not found anything of interest.

Also, it should be noted that as a time/processor saver, I am only calculating the first block of the cyphertext, not the whole thing. If the first block looks interesting (so far, none really have), then I will go back and decrypt the whole message.

Edit2: the last line of 8 bytes all by itself may be the initialization vector and not part of the code itself.
rc5.c
Description  RC5 Decoder
c

 Download 
Filename  rc5.c 
Filesize  8.5KB 
Downloaded  503 Time(s) 
_________________
Y0 Resources / VP Wiki / PXC Catalog / Metacortex

PostPosted: Mon Jul 11, 2005 3:25 pm
 View user's profile Visit poster's website
 Back to top 
BovineOne
Guest


BriEnigma wrote:
If anyone wants to look at the actual RC5 spec (it is not too terribly long, but very mathematically/algorithmically dense and includes C samples), you can find it in RFC-2040.


Your code is slightly wrong. The word size (w) must be 64, the doubling that is mentioned in the RFC is not directly relevant. These are the correct constants for the top (tested with gcc):

typedef unsigned long long WORD; /* Should be 64-bit = 8 bytes */
#define w 64 /* word size in bits */
#define r 12 /* number of rounds */
#define b 8 /* number of bytes in key */
#define c 1 /* number words in key = ceil(8*b/w)*/
#define t 26 /* size of table S = 2*(r+1) words */

WORD S[t]; /* expanded key table */
WORD P = 0xb7e151628aed2a6bULL; /* magic constants */
WORD Q = 0x9e3779b97f4a7c15ULL; /* magic constants */

PostPosted: Tue Jul 12, 2005 1:27 am
 Back to top 
BrianEnigmaModerator
Entrenched


Joined: 05 Oct 2003
Posts: 1199
Location: Pacific Northwest

Yeah, I got home and was actually able to grab my copy of Applied Cryptography and discover that some of my assumptions were wrong and that the code I picked up was for RC5-32.

Quote:
RC5 is actually a family of algorithms... Rivest designates particular implementations of RC5 as RC5-w/r/b, where w is the word size, r is the number of rounds, and b is the length of the key in bytes.


I was correct in remembering the block size is twice the word size, but I thought we were dealing with 64-bit blocks and 32-bit words rather than 128-bit blocks and 32-bit words. It also looks like I may have made an incorrect assumption in packing bytes into and removing them from the two words.
_________________
Y0 Resources / VP Wiki / PXC Catalog / Metacortex

PostPosted: Tue Jul 12, 2005 2:07 am
 View user's profile Visit poster's website
 Back to top 
Mosestrotsky
Veteran

Joined: 18 May 2005
Posts: 147
Location: Brighton, Uk

Just want to say thanks for the description of what the code etc is. Good luck guys

PostPosted: Tue Jul 12, 2005 7:16 am
 View user's profile
 Back to top 
SteveC
Unfettered


Joined: 05 May 2005
Posts: 381

OK, some of my things are solved and I'm not being forced to look at RC5 (despite the fact that my computer has been crunching keys for it for the past 6 or so years).

1/ Are we sure that the IV set as:

WORD P = 0xb7e151628aed2a6bULL; /* magic constants */
WORD Q = 0x9e3779b97f4a7c15ULL; /* magic constants */

Is valid? I'm not so sure... How does that relate to an initial vector of say, "79 ce d5 d5 50 75 ea fc" ?

2/ What is the benefit of rotating the keys? Are we just taking the set point as a starting point and hitting it from there? That makes little sense, I'd have thought it preferable to be able to manually enter a key each time as we're clearly not going to dedicate the resources to hit this brute force.

PostPosted: Tue Jul 12, 2005 7:28 am
 View user's profile
 Back to top 
BovineOne
Guest


SteveC wrote:

1/ Are we sure that the IV set as:

WORD P = 0xb7e151628aed2a6bULL; /* magic constants */
WORD Q = 0x9e3779b97f4a7c15ULL; /* magic constants */

Is valid? I'm not so sure... How does that relate to an initial vector of say, "79 ce d5 d5 50 75 ea fc" ?


Those are not the IV. Those are the magic constants for the algorithm itself. The constants change depending on the word size (w), and are documented in the PDF/RFC for the algorithm. (For 32-bit word size, the magic constants are just the upper 32-bits of each of those two.)

The IV is actually XOR'ed on top of the decrypted text, and that is used as the basis for the next decryption block--but SteveC's code actually does not do any IV mixing yet. Here is some sample code of mine (from RC5-32/12/Cool that shows how IV is used during the decryption loop. Keep in mind it's a little different because of my 32-bit block size:

Code:

    // Setup the S / L values...
    RC5_SETUP(key);

    for (int i = 0; i < maxrows; i += 2) {
        WORD pt[2], ct[2]={0,0};

        // Decrypt the wordpair...
        ct[0] = bigcipher[i+0];
        ct[1] = bigcipher[i+1];

        // decrypt (including the initial vector):
        RC5_DECRYPT( ct, pt );
        bigplain[i+0] = pt[0] ^ iv[0];
        bigplain[i+1] = pt[1] ^ iv[1];

        // Prior step's cipher becomes the xor vector for the next step
        // (if we were doing more than 1 wordpair)...
        iv[0] = ct[0];
        iv[1] = ct[1];
    }


PostPosted: Tue Jul 12, 2005 12:57 pm
 Back to top 
BovineOne
Guest


BovineOne wrote:

The IV is actually XOR'ed on top of the decrypted text, and that is used as the basis for the next decryption block--but SteveC's code actually does not do any IV mixing yet.


I meant "BriEnigma's code"...

PostPosted: Tue Jul 12, 2005 1:00 pm
 Back to top 
erekose
Veteran

Joined: 10 Oct 2003
Posts: 111
Location: A maze of winding passages, all alike

Quote:
Umm, by a very brief calculation, if everyone's running Athlon 64 3200+ (my computer), it would take 142,000 computer-years of runtime. Ouch


Quantum computers, there's never one around when you really need it. Smile
_________________
Erekose³³³
You have dreamed too well, O wise archdreamer, for you have drawn dream's gods away from the world of all men's vision to that which is wholly yours-H.P Lovecraft


PostPosted: Wed Jul 13, 2005 11:55 am
 View user's profile
 Back to top 
Scott
Entrenched


Joined: 11 Sep 2004
Posts: 1140
Location: 390 Chestnut Ridge Rd, Rochester NY, 14624, USA

erekose wrote:
Quantum computers, there's never one around when you really need it. Smile
or maybe there is. *chuckles to self*
_________________
Perplex City is a game whose only rule is: There must be a party.
Balance of Powers is a game whose only rule is: There must be a political party.


PostPosted: Wed Jul 13, 2005 12:24 pm
 View user's profile Visit poster's website
 Back to top 
BrianEnigmaModerator
Entrenched


Joined: 05 Oct 2003
Posts: 1199
Location: Pacific Northwest

BovineOne (or anyone, for that matter), do you have access to some sample RC5-64 decryption code with IVs that you could point us to? I can't seem to find much through Goggle and I'm a bit nervous about tweaking the 32 code to use 64 and would rather use something that is a known-good rather than introduce unnecessary unknowns. Even OpenSSL doesn't have RC5-64 algorithms yet.

The RC5 IV's don't seem to be touched on in Schneier's book (which only has about 5 paragraphs devoted to this.) So when decoding the first block, each byte of the output is XOR'ed with the 8-bit IV, right? From that point onward, when decoding block "n", after passing it to RC5_DECRYPT, you XOR it with the decode of block "n-1," correct?
_________________
Y0 Resources / VP Wiki / PXC Catalog / Metacortex

PostPosted: Wed Jul 13, 2005 7:12 pm
 View user's profile Visit poster's website
 Back to top 
oliverkeers13
Entrenched


Joined: 23 May 2005
Posts: 917
Location: London, UK

Shocked I don't think that i understood one sentence of that Bri. Dunce
_________________
"You're talking last ditch, I need top drawer" V
"To be in opposition is not to be a nihilist" CH
"im iver an idiot or a genus" Dekuprince
Perplex City Video


PostPosted: Wed Jul 13, 2005 7:25 pm
 View user's profile Visit poster's website AIM Address MSN Messenger
 Back to top 
SteveC
Unfettered


Joined: 05 May 2005
Posts: 381

Just picking nits a little bit, but both codes are RC5-64, the 64 is how we refer to the keysize, not the blocksize. Still means we have to decypher the meaning of the code in order to double the blocks it's dealing with though.

PostPosted: Thu Jul 14, 2005 3:49 am
 View user's profile
 Back to top 
diddymac
Boot

Joined: 11 Jul 2005
Posts: 41
Location: In a corner, by the window

I've googled the phrase "thirteenth labour" and it's come up with- get this- poems, puzzles and this:
http://www.mytholmroyd.net/tedhughes/alcestis2.html
_________________
Black Ethel Rackham knows the script but searches for the cube nonetheless.
7/100


PostPosted: Thu Jul 14, 2005 10:38 pm
 View user's profile
 Back to top 
Night565
Boot

Joined: 14 Jul 2005
Posts: 31
Location: Noware, TN

Maybe

Maybe once the code is perfected we should wordlist that whole document and run it through dictionary-hack style. Synonomizing it, as well as running latin/greek/mythology wordlists wouldn't be a bad idea either.

For what its worth, have we tried de-hexing, ROT, divide-bys, etc.? Maybe the hardest part of the puzzle is figuring out it's not hard?

Also, no-one ever said this puzzle had to be read top-to-bottom, left-to-right. Keep that in mind while decrypting. If I come up with anything else, I'll let you know. Wink
_________________
People are afraid of what they don't understand. -Charles Xavier

Playing PXC and HOC.


PostPosted: Fri Jul 15, 2005 1:32 pm
 View user's profile AIM Address
 Back to top 
BovineOne
Guest


BriEnigma wrote:
BovineOne (or anyone, for that matter), do you have access to some sample RC5-64 decryption code with IVs that you could point us to? I can't seem to find much through Goggle and I'm a bit nervous about tweaking the 32 code to use 64 and would rather use something that is a known-good rather than introduce unnecessary unknowns. Even OpenSSL doesn't have RC5-64 algorithms yet.


Here is the code I used for the distributed.net "RC5-64" contest (RC5-32/12/8, ie: 64-bit key, 32-bit block):
http://www1.distributed.net/~bovine/bovine-rc5-64.cpp

Compile it and then supply the following line as stdin:
Code:
foo,foo,foo,63DE7DC154F4D039,foo,foo,foo,foo


You're right that most RC5 implementations do not support anything other than the 32-bit block variation (OpenSSL and Perl's Crypt::RC5 are both limited to that).

BriEnigma wrote:
The RC5 IV's don't seem to be touched on in Schneier's book (which only has about 5 paragraphs devoted to this.) So when decoding the first block, each byte of the output is XOR'ed with the 8-bit IV, right? From that point onward, when decoding block "n", after passing it to RC5_DECRYPT, you XOR it with the decode of block "n-1," correct?


Yes, that's basically it, if "CBC" (Cipher-Block Chaining) mode is what you are intending to use. The value chosen for IV must of course be known in advance in order to decrypt (just as the actual key value). Note that there are several different ways to use "IV" besides just CBC mode--see the rest of that wikipedia article for some of the others.

PostPosted: Wed Jul 20, 2005 3:42 am
 Back to top 
Display posts from previous:   Sort by:   
Page 2 of 35 [518 Posts]   Goto page: Previous 1, 2, 3, 4, ..., 33, 34, 35  Next
View previous topicView next topic
 Forum index » Diversions » Perplex City Puzzle Cards » PXC: Silver Puzzle Cards
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum
You cannot post calendar events in this forum



Powered by phpBB © 2001, 2005 phpBB Group