The current AES-CCM implementations in hardware (#62 and precursors as well as libcrux in #53) will be merged with the caveats that they don't do in-place encryption/decryption yet, and no streaming AAD.
The hardware ones are subject to ongoing experimentation, the outcome of which will either be an improved implementation (quite possibly with extra requirements on the AadGenerator iterator, eg. that it has an associated const or type through which the list of chain elements can be built), or revisit a very early and IMO important design decision.
For libcrux, implementing this will mean working off a branch of libcrux temporarily; experience gained there should help justify merging that in libcrux mainline.
[edit: added libcrux]
The current AES-CCM implementations in hardware (#62 and precursors as well as libcrux in #53) will be merged with the caveats that they don't do in-place encryption/decryption yet, and no streaming AAD.
The hardware ones are subject to ongoing experimentation, the outcome of which will either be an improved implementation (quite possibly with extra requirements on the AadGenerator iterator, eg. that it has an associated const or type through which the list of chain elements can be built), or revisit a very early and IMO important design decision.
For libcrux, implementing this will mean working off a branch of libcrux temporarily; experience gained there should help justify merging that in libcrux mainline.
[edit: added libcrux]