[email protected] (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
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
