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 Mon Nov 18, 2024 5:40 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 15 of 35 [518 Posts]   Goto page: Previous 1, 2, 3, ..., 13, 14, 15, 16, 17, ..., 33, 34, 35  Next
Author Message
AFINZEL
Kilroy

Joined: 01 Dec 2005
Posts: 1

 		Hi guys,

I spent ages last night looking at the thirteenth labour and it seems to mean a very labourouse task. I also tried lots of words to do with this thirteenth labour that Herculese had to do. So I gave up and figured we may need to brute force it, after speaking to the guys in distributed, they suggested that I raise a bug report to see if distributed.net would add our problem to their server and allow us to use the cow client to try and brute force it in a coordinated mannar. I'll keep you guys posted on what they say.

Adam

PostPosted: Tue Dec 06, 2005 9:23 am
 View user's profile
 Back to top 
Kvasir
Boot

Joined: 15 Oct 2005
Posts: 48
neuromancer wrote:

unmodified??? interesting...means we already have the means to decrypt then...I'll work on a way to pass 'dictionary files' to the app so that you can leave it decoding in the backround unattended.


Ok, if they used rccrypt in an unmodified way, I'm thinking the 64/12/8 bit doesn't refer to the encryption standard.

I like the idea of the page/line/word George Washington stylee code-book, and the book that have a five cow rating is DES: Cracking the Encryption. Does anyone have this, and are they able to tell us which word appears at page 64, line 12, word 8.

I'm guessing that this might be the initialisation vector we need.

That said:
a) I know sweet f-a about RC5/DES encryption (although I did run the distributed.net client for a few years) so I might have completely misunderstood the initialisation vector thing, and
b) the amazon.co.uk "look inside" feature suggest that the DES book's pages might not be numbered in the normal way....

So I may be completely off track, but it's worth a go if someone on here has the book. ricksoft?

PostPosted: Tue Dec 06, 2005 9:38 am
 View user's profile
 Back to top 
Kvasir
Boot

Joined: 15 Oct 2005
Posts: 48

 		Another question for people that actually know something about RC5/DES encryption:

Given that we know the length of the encrypted output, can we determine the length of the input? even if we could determine a maximum length it would rule out a lot of possible answers.

The plaintext would need to be converted to hexadecimal prior to encryption. The hexadecimal information would then need to be padded out to fill a number of 8 bit blocks.

If the encryption process returns the same number of hexadecimal pairs in output as are provided in input, the 176 pairs we are considering would represent between 169 and 176 characters.

I am guessing that the encryption process probably returns a greater number of hexadecimal pairs than are input, but I don't know this. Does anyone on here?

Given that RC5 and DES encryption are supposed to be pretty good, it presumably isn't open to attack on this basis though...

PostPosted: Tue Dec 06, 2005 10:10 am
 View user's profile
 Back to top 
ReeKorl
Boot

Joined: 14 Nov 2005
Posts: 32
Location: St. Albans, Hertfordshire
Kvasir wrote:
I like the idea of the page/line/word George Washington stylee code-book, and the book that have a five cow rating is DES: Cracking the Encryption. Does anyone have this, and are they able to tell us which word appears at page 64, line 12, word 8


clicky
_________________
Cards I have and need

PostPosted: Tue Dec 06, 2005 11:24 am
 View user's profile
 Back to top 
EvilOverlord
Greenhorn

Joined: 02 Dec 2005
Posts: 6
Location: Ann Arbor, MI, US
neuromancer wrote:
ricksoft wrote:
I've contacted the nice people behind Perplexcity (as they are using my code), and I don't think I'm giving anything away by saying that they did use rccrypt in an unmodified form to encrypt something.


unmodified??? interesting...means we already have the means to decrypt then...I'll work on a way to pass 'dictionary files' to the app so that you can leave it decoding in the backround unattended.


Doesn't c0123's program already do this?

PostPosted: Tue Dec 06, 2005 12:46 pm
 View user's profile
 Back to top 
Ashin
Veteran


Joined: 22 Nov 2005
Posts: 140

 		Hi Richard,

I poked around and as it turns out I used v1.4 as a basepoint to start from (I apparently downloaded the 'latest' source from an old mirror), but I checked the v1.6 and the error is present there, too.

The error is on line 257 in the main .c file:

Code:
      
252:   /*read in the key if the file exists*/
253:   if (keyfile != NULL)
254:   {
255:      rd_count = fread (key_buffer,1,MAX_BYTES_IN_KEY,keyfile);
256:      /*make the end null*/
257:      key_buffer[rd_count-1]='\0'; //<-----------------
258:      /*set the k_chars to point to the buffer*/
259:      k_chars = key_buffer;
260:      /*close the file*/
261:      fclose(keyfile);
262:   }


The 'rd_count-1' is actually accessing the last character read, as opposed to force null terminating key_buffer. So if your keyfile only had one character in it, you would be getting null back. If you have a space at the end of your keyfile, you wouldn't even notice this, but if the last character is part of the key you have a problem. The fix just needs to be 'key_buffer[rd_count]='\0';'.

Which means it could be possible MindCandy gave us a 64/12/7.5 problem....

Richard, Do you by any chance keep a detailed changelog between versions?

Feel free to PM me for more contact info.

PostPosted: Tue Dec 06, 2005 11:01 pm
Last edited by Ashin on Wed Feb 07, 2007 2:56 pm; edited 1 time in total
 View user's profile
 Back to top 
Ashin
Veteran


Joined: 22 Nov 2005
Posts: 140
Kvasir wrote:

Ok, if they used rccrypt in an unmodified way, I'm thinking the 64/12/8 bit doesn't refer to the encryption standard.
...
I'm guessing that this might be the initialisation vector we need.


64/12/8 does refer to the encryption standard. blockbits/rounds/keybytes is a standard notation that is rather unique to RC5.

rccrypt is apparently one of the only implementations of RC5 for a 64 bit block. If you read the distributed.net "RC5-64" challenge documentation, what they meant by "we cracked 64 bit RC5" was a reference to the key size. What they really cracked in the notation form was 32/12/8. 64-bit blocks haven't even been touched by RSA challenges yet.

As for the initialization vector(s), rccrypt already has the vectors built in, specifically, phi (the Golden Ratio), and e (Euler's number).

Kvasir wrote:

Given that we know the length of the encrypted output, can we determine the length of the input? even if we could determine a maximum length it would rule out a lot of possible answers.


We know the length of the input actually, but it is somewhat long. The first and last working blocks for rccrypt are garbage characters. In the last block, before encrypting, the amount of padded characters is put into the lower four bits of the first character on the last working block (say that fast). So the only way to know exactly how many characters are in the message is to decrypt the message. Doh!

We do know the message is between 128 and 144 characters long because of this, though.

Kvasir wrote:

The plaintext would need to be converted to hexadecimal prior to encryption. The hexadecimal information would then need to be padded out to fill a number of 8 bit blocks.


In ASCII, or more directly, because of computer processor architecture, all characters are represented as one byte of memory. In the C languages, memory is memory, however you reference it is however it gets treated. So "abcd" is memory as a string could be "12439052" as an integer or "61626364" in hex (the int is the wrong actual number, it's just an example). This is how the message is encoded, aka. memory is memory.

Kvasir wrote:

Given that RC5 and DES encryption are supposed to be pretty good, it presumably isn't open to attack on this basis though...


Just a side note that DES is actually VERY insecure. It was designed for the 70's when computers were, well, lame. DES can be cracked in a matter of hours now by relatively simple machines, which is what the 'Cracking DES' book is all about. This is why the NSA decided a few years ago that in order to keep information safe, a new standard was needed, and that's where AES came from.

Hope that clears some things up.

PostPosted: Wed Dec 07, 2005 12:11 am
Last edited by Ashin on Wed Feb 07, 2007 2:56 pm; edited 1 time in total
 View user's profile
 Back to top 
Mark_1984
Greenhorn

Joined: 10 Dec 2005
Posts: 3
Location: London

 		Sorry to ask a stupid question, but can somebody tell me where I can download an executable version of RCCrypt. I don't have a C compiler so can't use the Ricksoft version

Many thanks

PostPosted: Sat Dec 10, 2005 5:50 am
 View user's profile Visit poster's website
 Back to top 
ALISDAIRPARK
Unfictologist


Joined: 27 Nov 2005
Posts: 1646
Location: Everywhere else

 		I really do not think the answer to this will come from brute force decryption, for starters it's an extremely un-elegant solution, and all the the other answers, silvers included (so far), have been puzzles to solve.

I don't have this card so was just browsing this topic, but I suspect the answer will not come from the de-code, if that is ever acheived.
_________________
Absorb what is useful <> Reject what is not <> Add what is uniquely your own
Playing : http://cerebrumachine.com and http://www.westunfictionopia.info

My charity page: http://www.justgiving.com/alisdairpark3

PostPosted: Sat Dec 10, 2005 10:01 am
 View user's profile
 Back to top 
Langley Moor
Veteran

Joined: 27 Oct 2005
Posts: 86

 		I have to disagree on that point - they've pointed us in the direction of the program to decode it via the clue, I think that's a very strong hint that we have to crack the code... the challenge is to determine the password, given the clue of the title and the cows (at a guess).

PostPosted: Sat Dec 10, 2005 6:30 pm
 View user's profile
 Back to top 
poozleModerator
Entrenched

Joined: 15 Aug 2005
Posts: 1090

 		Although brute force is not the best way to solve it, it will be a possible way of solving it if we can't work out the password (and it'll give my computer something to do in the meantime Razz)

PostPosted: Sat Dec 10, 2005 7:37 pm
 View user's profile
 Back to top 
ricksoft
Greenhorn

Joined: 25 Nov 2005
Posts: 4

 		rccrypt - bug in reading from file...
Why the last character is sometimes dropped when reading from a file.

It turns out that all the editors I've used to create a keyfile file add an unseen "newline" character (ascii value decimal 10), so the rd_count-1 is actually correct for this case.

I would suggest making sure that this is the case in all key files used.

This does pose a possible problem forWindows users - the default end of line is TWO character (CR,LF, decimal 13,10). This means rccrypt will effectively ADD a character to the key if there is an end of line character.

I'll put in some code to deal with this in the next release, but it suggests to me that Windows and Unix systems will work differently.

Cheers,

Richard.

PostPosted: Mon Dec 12, 2005 7:59 am
 View user's profile
 Back to top 
Ashin
Veteran


Joined: 22 Nov 2005
Posts: 140

 		Re: rccrypt - bug in reading from file...
ricksoft wrote:

I'll put in some code to deal with this in the next release, but it suggests to me that Windows and Unix systems will work differently.


Hi Richard,

This is true. But!, I'm running on Linux. Using vi to edit is what dropped the character for me.

This is just my personal recommendation. I would remove the fread call, and replace it with fgets (to account for multiline input). Then check if the last character is a newline or not. This will yield the same effect for files ending in '\n' and files ending in EOF.

The fact I'm running on *nix is what concerns me about this puzzle though. Getting rccrypt to run in Windows requires some editing of the code, which would seem to imply MindCandy also used *nix to make the card. So hopefully they didn't use vi either....

PostPosted: Mon Dec 12, 2005 1:04 pm
Last edited by Ashin on Wed Feb 07, 2007 2:56 pm; edited 1 time in total
 View user's profile
 Back to top 
neuromancer
Decorated


Joined: 04 Aug 2005
Posts: 168
Location: Birmingham, UK

 		Hey Richard, do you remember how long ago MC contacted you about using your code? That way we can determine what version of the code they may have used to encrypt the message. Not sure if that would affect our efforts or not but it's probably useful to know anyway.
_________________
The car in front.....it's mine!!!

Windows, the most successful computer virus in history...

PostPosted: Mon Dec 12, 2005 7:20 pm
 View user's profile
 Back to top 
Relish
Boot

Joined: 12 Dec 2005
Posts: 57
Location: Sunny Sunny Wales!

 		dont think its been posted but i have the card and just entered the number to see what the enry screen looks like. fraid its just a bog standard one text box entry, no clues at all (didnt think itd be as easy as that to be honest but worth a try!)

Rolling Eyes

PostPosted: Tue Dec 13, 2005 2:36 pm
 View user's profile
 Back to top 
Display posts from previous:   Sort by:   
Page 15 of 35 [518 Posts]   Goto page: Previous 1, 2, 3, ..., 13, 14, 15, 16, 17, ..., 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