SHA-1, SHA-224 & SHA-256 with x86 instructions

[MarekKnapek]

WIP - there are still things that need to be resolved, see #716.

[sjaeckel]

FYI: Please feel free to read the commit messages of the commits I added, they contain the reasoning behind most of the changes.

[sjaeckel]

Looking at the results in appveyor it seems like this somehow doesn't result in any improvements on MSVC ...

[sjaeckel]

Looking at the results in appveyor it seems like this somehow doesn't result in any improvements on MSVC ...

So that's a little surprising, but it seems the CPUs of Appveyor don't support the SHA instructions!? https://ci.appveyor.com/project/libtom/libtomcrypt/builds/53881218

libtomcrypt/src/hashes/sha1_desc.c

Line 68 in c175284

printf("\nCPU says: %d && %d && %d && %d\n\n", sse2, ssse3, sse41, sha);

CPU says: 1 && 1 && 1 && 0

I'd suggest we simply ignore this and someone using Windows will maybe pop up if something else is broken. I'll rebase and squash this all together, OK @MarekKnapek ?

[MarekKnapek]

• Looks great. Much neater than my attempts!
• Not sure why you removed the LTC_ARGCHK sanity checks in 6a9e083 and in 1b68c95.
• Regarding MSVC, I prepared a Visual Studio 2026 project files. They are using the MSVC compiler and also the clang-cl compiler. They are building with warning level 3 (MSVC) and warning level4 (clang-cl). And x86 dispatching and execution works fine. (I do have SHA-capable Windows machine and SHA-not-capable Linux machine.) Edit: They are at https://github.com/MarekKnapek/libtomcrypt/commits/msvs/ and at https://github.com/MarekKnapek/libtomcrypt/commits/msvs-sha-x86/

[sjaeckel]

• Not sure why you removed the LTC_ARGCHK sanity checks in 6a9e083 and in 1b68c95.

Because

1. they were in the compress functions, so they would get executed each round, but they need only to be tested once.
2. they are redundant

    LTC_ARGCHK(md != NULL);
    LTC_ARGCHK(buf != NULL);

are already verified here

libtomcrypt/src/headers/tomcrypt_private.h

Lines 150 to 151 in 68aae28

	LTC_ARGCHK(md != NULL); \
	LTC_ARGCHK(in != NULL); \

    LTC_ARGCHK(((ltc_uintptr)(&md->sha{1,256}.state[0])) % 16 == 0);

is aligned by us in the init() function, so doesn't need checking again

    LTC_ARGCHK(((ltc_uintptr)(&K[0])) % 16 == 0);

is aligned by the compiler, c.f. its declaration

    LTC_ARGCHK(sizeof(int) == 4);

I'm not sure why that's even checked, and if it were required it should be a compile-time check via LTC_STATIC_ASSERT(sizeof(int) == 4); in some other place.

• Regarding MSVC, I prepared a Visual Studio 2026 project files.

We provide VS2008 project files which should be sufficient to be updated to a newer VS version, or not? Also you should most likely simply use the CMake file instead of a custom VS solution.

[MarekKnapek]

.... aaand it is building on ci https://github.com/MarekKnapek/libtomcrypt/actions/runs/24456588598

[sjaeckel]

.... aaand it is building on ci https://github.com/MarekKnapek/libtomcrypt/actions/runs/24456588598

Could you please check whether you can simply build and run the CMake project on a Windows GitHub runner?

[MarekKnapek]

Yes, I can run CMake -> generate Visual Studio 2026 project. But the build fails because libtommath and because the s_mp_rand_platform function. I think it is illegal to use code such as if(false){ non_existing_function(); } and relying on the optimizer to remove never used functions - but there is nothing to remove, the compilation fails before the optimizer realizes nobody calls the functions. It should be an #if instead of an if. https://github.com/MarekKnapek/libtomcrypt/actions/runs/24461800098/job/71477784630#step:3:16613 and https://github.com/MarekKnapek/libtomcrypt/actions/runs/24461800098/job/71477784630#step:3:33223 If I fix / comment out the problematic function calls, everything builds just fine.

[sjaeckel]

Yes, I can run CMake -> generate Visual Studio 2026 project. But the build fails because libtommath and because the s_mp_rand_platform function. I think it is illegal to use code such as if(false){ non_existing_function(); } and relying on the optimizer to remove never used functions - but there is nothing to remove, the compilation fails before the optimizer realizes nobody calls the functions. It should be an #if instead of an if. https://github.com/MarekKnapek/libtomcrypt/actions/runs/24461800098/job/71477784630#step:3:16613 and https://github.com/MarekKnapek/libtomcrypt/actions/runs/24461800098/job/71477784630#step:3:33223 If I fix / comment out the problematic function calls, everything builds just fine.

Did you read the comment in s_mp_rand_platform?

[MarekKnapek]

Yes, I read it. And I explained to you here few moments ago why I think you are wrong there.

We intentionally don't fix this issue in order to have a single point of failure for misconfigured compilers.

This is nonsense, according to me. This is not misconfigured compiler, this is bending the rules of the C language and relying on it.

Similarly as pragma align(x) or __decspec(align(x)) or __attribute__(aligned(x)) are hacks and proper way of doing things is alignas(x). But that is not available in ancient C standard. Only in recent standard.

I would suggest to convert those ifs from run-time ones (even if evaluating constants, still run-time) into compile-time ones instead. Via using the #if preprocessor.

[sjaeckel]

[sjaeckel]

Looks great. Much neater than my attempts!

Thank you.

And thank you for the contribution and most of the implementation and integration work!