nisse@lysator.liu.se (Niels Möller) writes:
Also, other AES-style algorithms, in particular, twofish and camellia, could have similar changes as AES.
I've had a closer look now. I was a bit mistaken about twofish; it uses the same number of rounds and subkeys independent of the key size. So the remanining algorithms with a number of subkeys depending on the key size are camellia and cast128.
Camellia uses fewer subkeys for 128 bit keys than for 192 or 256 bit keys. So this is a bit similar to AES, and I think an analogous reorg would make sense.
As for cast128, the smaller number of rounds apply only for keysizes shorter than 80 bits (possible choices: 40, 48, 56, 64 or 72 bits). Maybe we can totally drop support for that, and limit possible key sizes to 80, 88, 96, 104, 112, or 128 bits? Does anyone has a usecase, e.g., interop with some old applications, where CAST128 with shorter keys are important? I'd imagine anyone using CAST128 today is using the maximum key size of 128 bits.
If I go through with the plan to drop the length argument from nettle_cipher.set_*_key, I think I should also add some public wrapper functions like, e.g.,
void twofish128_set_key (struct twofish_ctx *ctx, const uint8_t *key) { twofish_set_key (ctx, 16, key); }
for algorithms which allow variable key size. (Current situation is that instead, ciphers with *fixed* key size, like the new aes128_set_encrypt_key, need wrappers for their corresponding nettle_cipher instance). Naming the cast128 wrapper function for the common case of 128-bit keys will be a challenge, though...
Regards, /Niels