Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
Then the key need to be taken out from the cmac128_ctx. I'm trying that out, on the branch cmac-layout. Patch below. What do you think?
Do you see significant performance benefits?
Main benefit is that it makes it possible to make the context argument to siv_cmac_aes128_encrypt_message and similar functions const.
With a const context, one can, e.g., create a single siv_cmac_aes128_ctx instance, call the _set_key method once, and then share it between multiple threads processing messages independently.
With the current code (on the siv-mode branch), _siv_s2v uses parts of the context struct as working storage for cmac128_update, instead of using local temporaries. This clobbering of the context is a side effect with no benefit to the caller.
If we can change
#define SIV_CMAC_CTX(type) { struct CMAC128_CTX(type) siv_cmac; type siv_cipher; }
to
#define SIV_CMAC_CTX(type) { struct cmac128_key siv_cmac; type siv_cipher; }
then only the _set_key method needs to modify this context.
Being consistent in hashing/MAC APIs is also a benefit for the library and I think the change should be balanced against that.
It's not necessarily a change to the advertised cmac api (the new struct cmac128_key stays inside struct cmac128_ctx, and applications are not expected to depend on the details of the context struct), but it would be a small api/abi break, which is why I'd prefer to make the change before we make the release including the new cmac code.
At least the specific functions, cmac_aes*, should stay unchanged, for consistency with other macs.
For the general ones, cmac128_set_key, _update, _digest, maybe they should take a separate cmac128_key argument, and maybe be demoted to internal for now? For siv, we would need some variant of cmac_set_key function that takes only a cmac128_key argument, not a cmac128_ctx, and the new cmac128_message. These could be internal or public.
Regards, /Niels