nisse@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