I'm working on an integration of this AES implementation into https://github.com/mupq/pqm4.
I ran into the following issue:
ldm and stm require the address to be aligned to 4 bytes.
As keys, plaintexts, and ciphertexts are unsigned char*, those are not guaranteed to be aligned in that way (actually, the way e.g., Kyber and NTRUPrime use AES, ciphertexts or keys are guaranteed to be unaligned.
I replaced the ldm/stm with normal ldr/str which don't require such alignment. It does increase the code size a bit, but hopefully that does not impact performance too badly.
I've only tested the unmasked ffs implementations, but I tried to fix it in all implementations. Hopefully, I did not screw up.
Indeed I did not take into consideration data alignment for the inputs, which was clearly affecting code portability.
Thanks @mkannwischer for your contribution!
I'm working on an integration of this AES implementation into https://github.com/mupq/pqm4. I ran into the following issue:
ldm
andstm
require the address to be aligned to 4 bytes. As keys, plaintexts, and ciphertexts areunsigned char*
, those are not guaranteed to be aligned in that way (actually, the way e.g., Kyber and NTRUPrime use AES, ciphertexts or keys are guaranteed to be unaligned. I replaced theldm
/stm
with normalldr
/str
which don't require such alignment. It does increase the code size a bit, but hopefully that does not impact performance too badly.I've only tested the unmasked ffs implementations, but I tried to fix it in all implementations. Hopefully, I did not screw up.