introducing macro LTC_NO_WIN32_BCRYPT

[karel-m]

Forcing the use of BCryptGenRandom with newer MS Visual Studio makes me troubles with my CryptX module.

See https://www.cpantesters.org/cpan/report/00af9ff6-6e86-1014-b515-6e66cb952333

Defining LTC_NO_WIN32_BCRYPT avoids using BCryptGenRandom

[sjaeckel]

hmm, we're also building against 2022 and the build is fine!? shouldn't you better fix the build instead of disabling the "correct/modern API"? I'm just asking :) if you prefer it like that, we can also merge it!

[karel-m]

The thing is that when building perl bindings with VS2022 I need to explicitly instruct linker to link with bcrypt.lib the trick via #pragma comment(lib, "bcrypt.lib") in source code does not work due to the way how perl bindings are compiled and linked.

Although BCryptGenRandom might be called "modern API" I still consider CryptGenRandom more traditional and definitelly correct as well.

I only suggest to have an option to opt out from using BCryptGenRandom this is what this patch does.

[levitte]

This PR doesn't make sense to me. The use of BCryptGenRandom() or CryptGenRandom() is a build-time decision, while tomcrypt_cfg.h is a public header that somehow should reflect how libtomcrypt was built.

All this considered, I don't quite understand why LTC_WIN32_BCRYPT is even defined in a public header... unless it's something for others to use as an indicator if bcrypt.lib should be added when linking, which is actually reasonable.

Actually, the way tomcrypt_cfg.h is designed and meant to be used is pretty clear, and the comment at the top does clarify it:

libtomcrypt/src/headers/tomcrypt_cfg.h

Lines 4 to 8 in 427ce33

	/* This is the build config file.
	*
	* With this you can setup what to include/exclude automatically during any build. Just comment
	* out the line that #define's the word for the thing you want to remove. phew!
	*/

In other words, if you want a special build, you're supposed to patch (and I guess, carry around the patch). For example like this:

diff --git a/src/headers/tomcrypt_cfg.h b/src/headers/tomcrypt_cfg.h
index 3d90d03c..93e2c3d2 100644
--- a/src/headers/tomcrypt_cfg.h
+++ b/src/headers/tomcrypt_cfg.h
@@ -313,7 +313,7 @@ typedef unsigned long ltc_mp_digit;
 #endif
 
 #if defined(_MSC_VER) && defined(_WIN32_WINNT) && _WIN32_WINNT >= 0x0600 && !defined(LTC_WIN32_BCRYPT)
-#   define LTC_WIN32_BCRYPT
+#   undef LTC_WIN32_BCRYPT
 #endif
 
 /* Define `LTC_NO_NULL_TERMINATION_CHECK` in the user code

[levitte]

... maybe I'm being a bit too loud. Dunno. I just had a look at tomcrypt_custom.h, and that gave me pause. I'll dig deeper this evening...

[levitte]

I gave this another thought, and found that the easiest is to make LTC_WIN32_BCRYPT a private macro, see #660. Fortunately, this macro doesn't exist in any release, so that won't break anything, as far as I can tell.

[karel-m]

I am basically fine with whatever solution that allows me to opt out from using BCryptGenRandom(). This was just the easiest hack. I would stick to an official way how to do it, if we have one.

[levitte]

My vote is obviously on #660 😉

[sjaeckel]

Thanks @karel-m for bringing this up!

Since #660 is basically this patch, but in tomcrypt_private.h, I'm closing this PR.