Talk:The Thirteenth Labour

This is a candidate to be a Collaboration of the week. Please see this page's entry to support or comment on the nomination.

As far as I can tell "Assault on 13th Labour" are attacking the wrong cipher. They are attacking standard RC5 - that is, RC5-32/12/8 - when they should be attacking the nonstandard variant RC5-64/12/8. Ciphergoth 09:00, 3 June 2006 (PDT)

Comment from chimera245: The Assault Client was developped from the RCCRYPT package - according to Von's hint - version 1.6 to be exact (though 1.4 id identical in decryption terms). From the first page of the Unfiction thread:

64/12/8

This is VERY standard notation for the encryption used. It means that when it's being processed, 64 bits of the text are processed at a time. They are processed 12 times and that the key used to process them is 8 bytes (64 bits) long. This makes it almost certain that it's RC5-64 encryption.

Each block is processed in two 64 bit words at a time, for 12 rounds, using an 8 byte key.

The source has been verified by people who were actually involved in the original d.net assault on RC5-64 as a valid port of RCCRYPT 1.4 or 1.6. All of the clients used in this attempt (even those prior to mine) have been based upon the same premise - that Von's hint of RCCRYPT is the appropriate pointer. In actual fact, RCCRYPT calls itself 128 bit, not 64 bit - but by definition it is RC5-64.

Chimera245 Edited to clarify twice, last at 17:00, 6 June 2006 (PDT)

I am familiar with this notation (I'm a cryptographer) but it's not standard for block ciphers in general - it's specific to RC5. RC5-32/12/8 processes 64 bits at a time. RC5-64/12/8 would process 128 bits at a time. The number is half what you would expect because RC5 splits the input into two halves and each half acts on the other. I have checked the original RC5 paper - I recommend you do the same if you think I'm mistaken. Thanks! Ciphergoth 02:37, 22 June 2006 (PDT)

Hi I thought I made it clear earlier with the description of RCCRYPT a processing data in two 64 bit words at a time, but the RCCRYPT source, and the 13th labour client both process the data correctly - as RC5-64. I posted a more detailed explanation on UNFICTION - which you probably haven't seen. I am wondering where you are getting your information that we are doing otherwise?

Much cut and pastage follows, but the complete link is here

<QUOTE> There has been some discussion in places that we MAY not be performing the correct RC5 decryption process. In fact this morning I had my own doubts.

SO, I talked to the organ grinder (not the monkey) as it were, and referred to the original paper - to confirm once and for all in my own mind that all was well:

http://theory.lcs.mit.edu/~rivest/Rivest-rc5.pdf

I would like to answer this one and for all now.

To quote from the paper:

As noted above� RC� is word�oriented� all of the basic computational oper� ations have w�bit words as inputs and outputs� RC� is a block�cipher with a two�word input �plaintext� block size and a two�word �ciphertext� output block size�

The 64/12/8 refers to the following

w/r/b

w == Word Size (64 bits) r == Number of Rounds b == Number of Bytes in Key

The RCCRYPT package, which I used to base my code on, and is the subject of Von's hint, uses EXACTLY this pattern.

I know a few of you have reviewed the code privately, but just to quell any further speculation, here is, size by side, the code from RCCRYPT and my code for open comparison:

RCCRYPT:

/*now we have sixteen bytes ready to work on*/ /*split it into two ULLONGs, left and right*/

L = (ULLONG *)buffer; R = (ULLONG *)(buffer+8);

/*Put the data into host byte order*/ *L = ntohll (*L); *R = ntohll (*R);

/*decrypt the data...*/ for (i=rounds;i>=1;i--) { *R = rrotate(*R - S[2*i+1] , *L ) ^ *L; *L = rrotate(*L - S[2*i], *R) ^ *R; } *L -= S[0]; *R -= S[1];

/*Convert buffer back to network order*/ *L = htonll(*L); *R = htonll(*R);

And my DLL:

L = System.BitConverter.ToUInt64(buffer,0); R = System.BitConverter.ToUInt64(buffer,8);

if (this.m_clientType == 1) { L = NToHLL(L); R = NToHLL(R); }

//decrypt the data for (i=this.m_rounds;i>=1;i--) { R = RRotate(R - this.m_S[2*i+1] , L ) ^ L; L = RRotate(L - this.m_S[2*i], R) ^ R; }

L -= this.m_S[0]; R -= this.m_S[1];

if (this.m_clientType == 1) { L = HToNLL(L); R = HToNLL(R); }

Hopefully this can now move on. <END QUOTE>

Chimera245 23rd June 2006 (PDT)

Hey, y'all...let me make it totally clear that I know -nothing- about the technical side of this, so the following comments are from an outsider's perspective. My thoughts are first, that MC are definitely aware of our efforts, and if we were doing this monumental undertaking on the wrong kind of cipher, they certainly would have had one of the characters slip it into a blog post, or even have done a Sentinel article on it, if they really wanted to get our attention. Second, it can probably be resolved by e-mailing them to ask...I'd go for Kurt or Adrian. Hope that helps! -Lhall 10:35, 23 June 2006 (PDT)