New amd64 implementations?

Jussi Kivilinna jussi.kivilinna at
Mon Jul 1 12:18:51 CEST 2013

On 27.06.2013 21:21, Werner Koch wrote:
> On Thu, 27 Jun 2013 16:33, jussi.kivilinna at said:
>> Would it make sense to re-evaluate rndw32.c for current Windows versions (32/64bit) and drop support for Windows versions that have reached end of life?
> Better don't touch it ;-)  IIRC, I already remove some old code.
>> As I understand it, the CryptGenRandom function is supported by all current Windows and is the '/dev/urandom' of WIN32.
> I wouldn't trust CryptGenRandom.  It is used only as one entropy source.
> What should really be done is to compare the changes Peter did in
> Cryptlib and port them back to Libgcrypt. 

Here's my observations for latest cryptlib vs libgcrypt. I've also set up git repository that shows differences of cryptlib versions at: "". From there you can see that __WIN64__ ifdefs appeared in random/ with release 3.3.3. Those ifdefs disable Win95 random poller and change timer/TSC reading from 64-bit.


cryptlib uses same random/win32.c for 64-bit Windows.

cryptlib vs libgcrypt slow poll differences:

In cryptlib slow poll is partially done from separate thread; slowPoll() launches thread running slowPollWinNT().

Hardware information (from third party programs) and system RNG is fetched in current thread.

In addition to MBM (Motherboard Monitor), cryptlib has sensor reads from:
 - Everest
 - SysTool
 - RivaTuner
 - HMonitor
 - ATI Tray Tools
 - CoreTemp
 - GPU-Z

Libgcrypt does not implement reading of PnP data... "/* readPnPData ();  - we have not implemented that.  */"

cryptlib does not have special handling for win2k systems with pNtQuerySystemInformation ID 17 (SystemObjectInformation). Maybe win2k check can be removed since win2k is EOL.

Apart from above, slow poll appear to be quite the same in libgcrypt and cryptlib.

cryptlib vs libgcrypt fast poll differences:

cryptlib has 'addRandomHandle' for adding pointer type return values to random pool. This macro discards the upper 32 bits of pointer, casts to 'long'.

cryptlib does not use "GetQueueStatus(QS_ALLEVENTS)" as random source because:
	/* Calling the following function can cause problems in some cases in
	   that a calling application eventually stops getting events from its
	   event loop, so we can't (safely) use it as an entropy source */
	/*	addRandomValue( randomState, GetQueueStatus( QS_ALLEVENTS ) ); */

cryptlib adds values minimumWorkingSetSize and maximumWorkingSetSize from GetProcessWorkingSetSize to random pool using addRandomValue(), which casts values to 'long'. On 64-bit, this means that upper 32 bits are ignored and not used.

cryptlib has 'ifdef __WIN64__' for getting TSC directly with __rdtsc() intrinsic instead of calling QueryPerformanceCounter() or GetTickCount().

cryptlib does VIA RNG and Intel RDRAND in win32 fast poll.


> Shalom-Salam,
>    Werner

More information about the Gcrypt-devel mailing list