The old code relied on adjust-array of a simple-array yielding a new
simple-array, which is the case on most implementations and corresponds
with my reading of the standard. However ACL returns a non-simple array
in this case, which would later on clash with the declared types in
keccak-state-merge-input, leading to erroneous data accesses and
possible non-termination, etc. Since our use of adjust-array is not
central to the pad-message-to-width function, and that function is not
really performance critical (only called once during the digest
finalization), we just switch to new allocation and replace.
The final FIPS 202 SHA-3 standard mandates the prepending of a
01 suffix to the message prior to padding, which the original
Keccak submission did not specify. This change adjusts all
sha3 wrappers to behave standard conforming, and adds an optional
keyword argument raw-keccak-p to specify the original treatment.
Fixes#2.
The superfluous last iteration when start = end wasn't harmful, since the
iteration body winds up as a no-op in that case anyway, but wasn't
intended or needed.
Calls to sha3-update that did not completely fill an already partially
filled buffer were handled incorrectly, in that the buffer-index wasn't
properly updated. Thanks to Orivej Desh for the bug report.
Quick and dirty benchmarks seem to imply that 32bit implementation is
faster for 64bit LispWorks than 16bit implementation, even though it
causes more consing.
