[erekose]

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.

[BovineOne]

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"...

[BovineOne]

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/ 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];     }

[SteveC]

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.

[Mosestrotsky]

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

[BrianEnigma]

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.

[BovineOne]

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 */

[BrianEnigma]

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.

[Seej]

More shaded bits on this at the top and bottom that look like they're part of large letters extending onto other cards, just like I mention in this thread.

EDIT: Oops, cassandra mentioned this too

[SteveC]

Just to catch anyone up who's floundering....

rc5 is a very heavy encryption protocol that's used internationally. The little cows on the picture are a direct reference to the nice folks (well, mostly nice) at www.distributed.net. The bits I can understand of the code are as follows:

the 64/12/8 is notation to tell you the parametrs used to encode.. It's a block size of 64 bits (as it 64 ones and zeros are processed at a time), you pass over it 12 times and the "key" used is 8 bytes (64 bits making it an rc5-64) long.

The five cows could be a reference to ingrain that it's RC5 as well as pointing us to them.

Now, to decrypt this, you need a few more things..

1/ software to decrypt
2/ an IV (initial vector) which are the initial starting values of the system.
3/ a key - the machine readable password

1/ I don't have

2/ We might have, but I'm not sure if because this is 64 bit it'll be more difficult to achieve. At a guess, it's possibly using the RC5-64 IV mentioned on http://www.rsasecurity.com/rsalabs/node.asp?id=2106

3/ my only guess is to use the same key (0x63DE7DC154F4D039) as www.distributed.net used.

Thanks to Nerf who's a distributed hanger on-er for help with some of this..

[Axys Denyed]

The 64/12/8 refers to the particulars of the RC5 encryption. It basically means it has 64-bit wordsize, 12 rounds and 8*8=64bit encryption

[JebJoya]

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.

Jeb

[Mosestrotsky]

Hi,

Now I know I won't be able to solve this one but can you guys explain what RC5-64 code is in very simple terms as I have no idea.

Also could the date be reversed?

8th December 264 Perplexian time or is that numer part of the code?

[Enigmaster]

Atrophied wrote:

There are currently 12 RC5 challenges posted by RSA security, this would be a thirteenth challenge.

Oh, I see. Clever.
How long do these things take to crack on average?

(EDIT:Never mind - 'far too long' will be a good enough answer for that one )

[Atrophied]

From Steve C (IRC)

There are currently 12 RC5 challenges posted by RSA security, this would be a thirteenth challenge.

the cows link to www.distributed.net (5 pointing to RC5 possibly)