Camellia Key Schedule Difference from RFC #4349
-
|
I noticed while writing an implementation of Camellia that the key schedule in the RFC is not the same as the key schedule in botan for 192-bit and 256-bit keys. In the RFC (and the original Camellia paper) the bits are taken in the order high/low throughout, however in botan starting with subkey 22 the sequence changes from high/low to low/high. Botan is presumably correct as it produces the ciphertext from the RFC while the key schedule from the RFC does not. Does anyone know how the it was determined that this difference needed to be included or why the RFC was never updated? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
Sorry I wrote that (checks git history) 12 years ago and have definitely forgotten what happened here. I don't remember if I even noticed the problem; it's quite possible I misread the spec in some way, or followed some other description besides or in addition to the RFC, and accidentally ended up with something that passed the test vectors. As to the RFC being incorrect and not being updated, that's unfortunately quite common especially with more obscure or non-standards track RFCs. You could try reporting an errata against the RFC but being 20 years after publication it may well not be acted upon. |
Beta Was this translation helpful? Give feedback.
Sorry I wrote that (checks git history) 12 years ago and have definitely forgotten what happened here. I don't remember if I even noticed the problem; it's quite possible I misread the spec in some way, or followed some other description besides or in addition to the RFC, and accidentally ended up with something that passed the test vectors.
As to the RFC being incorrect and not being updated, that's unfortunately quite common especially with more obscure or non-standards track RFCs. You could try reporting an errata against the RFC but being 20 years after publication it may well not be acted upon.