Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider emulating x86's AESKEYGENASSIST? #389

Open
workingjubilee opened this issue Oct 4, 2023 · 5 comments
Open

Consider emulating x86's AESKEYGENASSIST? #389

workingjubilee opened this issue Oct 4, 2023 · 5 comments

Comments

@workingjubilee
Copy link

workingjubilee commented Oct 4, 2023

This is inspired by rust-lang/miri#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.

@RalfJung
Copy link

RalfJung commented Oct 4, 2023

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.^^

@newpavlov
Copy link
Member

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.

@workingjubilee
Copy link
Author

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.

@newpavlov
Copy link
Member

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.

@tarcieri
Copy link
Member

tarcieri commented Oct 5, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants