views:

60

answers:

2
+1  Q: 

RC2 key schedule

Can someone explain how the RC2 key schedule works (particularly the very beginning of it)? i know it uses little endian, but my implementation is not working for any key except "0000 0000 0000 0000"

Test Vector
Key = 88bc a90e 9087 5a
Plaintext = 0000 0000 0000 0000
Ciphertext = 6ccf 4308 974c 267f

im assuming that the first thing to do with the key would be to change it into

bc88 0ea9 8790 5a

and yes i know RC2 is not even used anymore, but i would still like to know

+1  A: 

It's all here

GregS
i could swear its not. it tells you that its little endian for 16 bit words, but thats it. if it is, could you possible explain what to do with the key i gave?ive looked at other peoples codes, but i have not found anything that even resembles "little endian" im trying to look for examples of worked out calculations
calccrypto
The RFC tells you exactly what it means when it says little endian. I don't see any ambiguity.
GregS
humor me. what is the key supposed to look like after changing it to little endian?
calccrypto
If you're a Java programmer, I recommend taking Bouncycastle's RC2Engine.java class and copying it out of the package, rename it to something like MyRC2. Then you can instrument this to see what happens at each step and see where your implementation differs.
GregS
+1  A: 

The RFC says:

The key expansion algorithm begins by placing the supplied T-byte key into bytes L[0], ..., L[T-1] of the key buffer.

So if your key is 88bc a90e 9087 5a you get L[0]=0x88, L[1]=0xbc, ... L[6]=0x5a.

No need to consider any endianess here.

If you want to treat the key-buffer as 16-bit words you get:

K[i] = L[2*i] + 256*L[2*i+1]

I.e. K[0] = 0xbc88, K[1] = 0xa90e, K[2] = 0x8790. L[7] is only assigned later in the key-expansion step, so strictly speaking K[3] is undefined at this point. Feel free to choose any value you want however, since it makes no difference to the algorithm. If you select 0, you get K[3] = 0x005a.

Rasmus Faber
hm... im having trouble with the key 3000000000000000 (the rest of the values are in the rfc). for some reason, that is the only key that is messing up the encryption. any ideas?
calccrypto
Not really. If you can get the correct values for /all/ the other keys, my guess would be that you have made a bad transcription somewhere. Either with the key or plaintext for the test vector or when entering the PITABLE (if you didn't just copy'n'paste it).
Rasmus Faber
You need to choose the number of effective key bits T1 first. The other constants (T8, TM) are derived from this. By the way, how do you know your problem is in the key expansion? It could be in the other steps.
GregS
T1 = 64. and it wouldnt really make sense if PITABLE was wrong, or else, one of the other test vectors is bound to be wrong (i'll check anyways). and i checked the inputs, and they are correct
calccrypto
The test vector with key=3000... is the only one where the plaintext does not consist of 8 identical bytes. So you are probably making a mistake in the way you map the plaintext into R[0],.. R[3]. Are you able to properly decrypt the test-vectors? Here are some intermediate values from the test-vector: the expanded key should be K[0]=0xd4ef, ... K[63]=0x025c and R[0]=0x0010, R[1]=0x0000, R[2]=0x0000, R[3]=0x0100.
Rasmus Faber
odd... i did not do the decryption right. i'll get on it. thanks!
calccrypto