You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Below are from self tests that exercise SHA::Transform (SHA is SHA1, SHA256, etc), which is a static member function. The code path for SHA::Transform is a little different than the code path when using an SHA object with Update and Final.
HASH::InitState and HASH::Transform are unique to hashes which derive from IteratedHashWithStaticTransform. Most hash classes simply derive from IteratedHash. The reason for the static HASH::Transform is, some classes like SEAL and MDC, call the transform function directly. The static functions allow the other classes to use, say, a user supplied key as state instead of the traditional SHA initialization values.
The self tests are fine on non-SHA-accelerated processors. However, due to the slightly different code paths, when ARM or Intel SHA is available, the code misses a required endian conversion. And again, calling Update and Final on a SHA object is fine because the conversions are present.
The reason only Message 3 fails can be seen in the sample messages. A string of zero's (Message 1) and a string of 1's (Message 2) don't have endianness problems per se. However, the bytes in Message 3 does suffer endianness.
Reworked SHA class internals to align all the implementations. Formerly all hashes were software based, IterHashBase handled endian conversions, IterHashBase repeatedly called the single block SHA{N}::Transform. The rework added SHA{N}::HashMultipleBlocks, and the SHA classes attempt to always use it.
Now SHA{N}::Transform calls into SHA{N}_HashMultipleBlocks, which is a free standing function. An added wrinkle is hardware wants little endian data and software presents big endian data, so HashMultipleBlocks accepts a ByteOrder for the incoming data. Hardware based SHA{N}_HashMultipleBlocks can often perform the endian swap much easier by setting an EPI mask so it was profitable to defer to hardware when available.
The rework also removed the hacked-in pointers to implementations. The class now looks more like AES, GCM, etc.
Below are from self tests that exercise
SHA::Transform
(SHA
isSHA1
,SHA256
, etc), which is a static member function. The code path forSHA::Transform
is a little different than the code path when using an SHA object withUpdate
andFinal
.HASH::InitState
andHASH::Transform
are unique to hashes which derive fromIteratedHashWithStaticTransform
. Most hash classes simply derive fromIteratedHash
. The reason for the staticHASH::Transform
is, some classes like SEAL and MDC, call the transform function directly. The static functions allow the other classes to use, say, a user supplied key as state instead of the traditional SHA initialization values.The self tests are fine on non-SHA-accelerated processors. However, due to the slightly different code paths, when ARM or Intel SHA is available, the code misses a required endian conversion. And again, calling
Update
andFinal
on a SHA object is fine because the conversions are present.The reason only Message 3 fails can be seen in the sample messages. A string of zero's (Message 1) and a string of 1's (Message 2) don't have endianness problems per se. However, the bytes in Message 3 does suffer endianness.
The text was updated successfully, but these errors were encountered: