[diddymac]

A long time.

[Riiick]

The Wikipedia page for RC5 states:

Quote:

12-round RC5 (with 64-bit blocks) is susceptible to a differential attack using 2^44 chosen plaintexts (Biryukov and Kushilevitz, 1998).

The cipher on the cards (i believe) is 12 round RC5 with 64 bit blocks.

Does this mean 17592186044416 different combinations have to be tried? If so how long would this take?

[oliverkeers13]

I haven't, but decipering 64 bit encryption is a herculean labour!

[tanner]

oliverkeers13 wrote:

This might seem stupid, but has someone emailed Kurt to ask, he seems like the helpful (and deceptive) sort, so might be willing to help us!

i find it really sad that you should give up so quickly -- how much pride for earthlings if we keep asking for help -- time we started to work this stuff out for ourselves

[madam o'brien]

Quote:

But is the idea to build a distributed client task to run which will decrypt this puzzle?

I don't think so. That would be too hard. The folks at disributed net took 1757 days to find do their decypt of RC5 with a 8 byte key.
That was 3 years ago but the benefit of faster processors will be offset by the fact that we are using the slower 64 bit (half-)block version and, more, significantly by the difficulty in getting such a large network working.

[Scott]

This is all sort of over my head. But is the idea to build a distributed client task to run which will decrypt this puzzle? I can lend a bunch of CPU cycles to the task, if that's the intention.

[BrianEnigma]

BovineOne wrote:

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

Hmmm... I was kind of hoping to find something that was RC5-64/*/*. There is a lot out there that is RC5-32/*/*. While I could probably convert the 32 bit word code to 64 bit size code, I am not sure how comfortable I would be in doing so. I would be worried that in my dim understanding of of the innerworkings of this particular shared-secret algorithm, I would make some kind of fundamental mistake, thereby wasting a lot of computational time. All of my professional work with cryptography to this point has been working with APIs into dual-key libraries as well as reading/writing PKCS files.

[oliverkeers13]

This might seem stupid, but has someone emailed Kurt to ask, he seems like the helpful (and deceptive) sort, so might be willing to help us!

[BovineOne]

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.

[Night565]

Maybe

[diddymac]

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

[SteveC]

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.

[oliverkeers13]

I don't think that i understood one sentence of that Bri.

[BrianEnigma]

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?

[Scott]

erekose wrote:

Quantum computers, there's never one around when you really need it.

or maybe there is. *chuckles to self*