Talk:The Thirteenth Labour

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