RustCrypto
Consider emulating x86's AESKEYGENASSIST?
This is inspired by https://github.com/rust-lang/miri/pull/3101
The reason why: People want to write software instruction emulators. They want to be able to run real code on them, not only toy programs. That means they may want to emulate AES instructions. People who want to do this might have to emulate AESKEYGENASSIST, for which the easy-to-find implementation is sbox-based, which elicits well-reasoned disapproval from certain cryptographers, at least with respect to secure contexts. Even if the context such emulation is used in is not security critical, having more such examples in the wild, especially if used in popular and permissively-licensed software, might leave people inclined to copy such bad implementations into their own code which runs in security-sensitive contexts, instead of using a good emulation.
Also the people writing the emulator might just not want to be in the business of having AES sboxes in their code that someone has to review for correctness.^^
I am not sure that aes is a right place for keeping emulation of such instructions. Maybe it would be better to introduce a different repository for software emulation of hardware-accelerated instructions for different platforms? Things like PCLMUL and SHA-NI also could be a good fit for it.
Yes, we have the hazmat module, but it's not the same thing as piling on emulation of various instructions present in x86/ARM/RISC-V/etc. There could be some degree of code duplication, but I think clear separation of concerns and keeping frequently used crates relatively lean is more important in this case.
I think you could make "complete the virtual emulation of AES-NI" and "don't scope-creep to other platforms" as a principled decision, because the hazmat module already represents so much of that, but I am not in a rush to tell you what to do.
IIRC the hazmat module exists because AES round function is used as a building block in some other cryptographic algorithms. Similarity with AES-NI is somewhat accidental. Of course, there are reasons for that, but we do not intentionally emulate AES-NI.
aeskeygenassist is effectively the key schedule setup for the AES equivalent inverse cipher, and in that regard as the hazmat module implements the equivalent inverse cipher API portably, it is a missing piece of the API
