While NTT looks into this, I'm posting this as a "solution":
By inspection of the function
void camellia_setup256(const unsigned char *key, u32 *subkey)
it is clear that all the accesses to the output vector 'subkey' are performed using the macros
#define CamelliaSubkeyL(INDEX) (subkey[(INDEX)*2])
#define CamelliaSubkeyR(INDEX) (subkey[(INDEX)*2 + 1])
Nowhere in the function are references to the indexes 1 and 33 to be found. These indexes would write to the word positions 2, 3, 66 and 67. These are the exact 4 words that are not written to in the tests.
The OpenSSL port of the Camellia cipher (Apache License 2.0) doesn't have this problem: assembly and c available.
Update:
I've compared the two ports above with the code from NTT linked in the question, as follows:
- generate a random 256 bits key
- generate a random 16 bytes block
- with each of the 3 implementations encrypt the block to compare the ciphertext
Summary: despite the unused words in the keyTable for the NTT implementation, in all the millions of key/block pairs tested, all the ciphertexts generated by the 3 implementations matched.
Fix:
Since it doesn't affect the encryption/decryption, the fix only reduces the keyTable size from 68 to 64 words. Since the code is very clean and all accesses are performed with the two macros above, only 16 lines need to be changed (tested only with 256 bits keys):
- Find all macros accessing the index 24 and change it to 1
- Find all macros accessing the index 32 and change it to 24
I've tested this in the process described above.