ni...@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 -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs