On 32-bit platforms, Keccak-F1600 is best implemented in an even/odd bit-interleaved presentation since it trades 64-bit rotates -- which are likely not natively supported -- for pairs of 32-bit rotates.
It seems that the current Keccak code can easily be adjusted to this case by providing an alternative ROL implementation; however, one would also need bit-interleaved implementations for XOR/ExtractBytes.
It is also a concern/consideration whether the 2-fold unrolled nature of the default Keccak implementation is suitable for 32-bit platforms.
In a nutshell: We currently don't do anything to support those platforms, and I wonder if we should, and if so, if this would necessitate an entirely separate Keccak implementation, or whether a decent shared implementation can be developed. Let's discuss that here.
On 32-bit platforms, Keccak-F1600 is best implemented in an even/odd bit-interleaved presentation since it trades 64-bit rotates -- which are likely not natively supported -- for pairs of 32-bit rotates.
It seems that the current Keccak code can easily be adjusted to this case by providing an alternative ROL implementation; however, one would also need bit-interleaved implementations for XOR/ExtractBytes.
It is also a concern/consideration whether the 2-fold unrolled nature of the default Keccak implementation is suitable for 32-bit platforms.
In a nutshell: We currently don't do anything to support those platforms, and I wonder if we should, and if so, if this would necessitate an entirely separate Keccak implementation, or whether a decent shared implementation can be developed. Let's discuss that here.