ni...@lysator.liu.se (Niels Möller) writes:
> There are some other, less trivial, changes I'm considering.
> * Tweaks to other context structs. E.g., for AES we have the nrounds
> field last, after the subkeys. If one could move it first, then one
> could allocate less space for subkeys when using shorter AES key sizes
> (not entirely sure how to make a decent C API for that, though).
I think it's going to get a bit messy to handle structs of varying size.
I think the simplest way would be to arrange the internal aes functions
to take number of rounds and the subkey as separate arguments. And then
define separate context structs and functions for each key size, like
struct aes128_ctx
{
uint32_t keys[44];
};
struct aes192_ctx
{
uint32_t keys[52];
};
struct aes256_ctx
{
uint32_t keys[60];
};
There should be no problem to also keep the current AES interface (with
variable key size) for backwards compatibility.
All the public AES functions would then call the same internal
functions, specifying the approproate number of rounds/subkeys in each
case.
Does that make sense? My impression is that most applications and
protocols typically treat AES128 and AES256 as different algorithms, and
have little use for an interface where the same function accepts a
variable key size.
And to recall, the motivation for the change is to avoid useless
allocation for the common case of AES128.
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
