A fast CPRNG

Windows specific questions.
Josep Roca
Posts: 244
Joined: Sep 27, 2016 18:20
Location: Valencia, Spain

Re: A fast CPRNG

Postby Josep Roca » Aug 07, 2017 19:23

Especially for Windows libraries I would suggest to use the ones provided by Microsoft (in the Windows SDK) instead of trying to create them oneself.


How? I only find propsys.lib, whereas FB wants libpropsys.dll.a.
Josep Roca
Posts: 244
Joined: Sep 27, 2016 18:20
Location: Valencia, Spain

Re: A fast CPRNG

Postby Josep Roca » Aug 07, 2017 19:48

With languages that don't use import libraries, such PowerBasic, you declare a function to import as

DECLARE FUNCTION Foo LIB [or IMPORT] "dll name" ALIAS "Foo" (parameters) AS LONG [or wathever]

The compiler loads the needed dlls at startup and retrieves the addresses of the functions being called. If an address is not found, the application fails with a message indicating that the function "x" can't be found.

For delay loading, a syntax like

DECLARE FUNCTION Foo DELAYLOAD [or wathever] "dll name" ALIAS "Foo" (parameters) AS LONG [or wathever]

could be used. The application won't load the dll at startup, but only when you call a function that you have told in the declare that is inside the specified dll.

The first syntax is suitable for functions that exist in all Windows versions and, therefore, won't fail. The second syntax is suitable for functions that only exist in some (or one) versions of Windows.

Another advantage of not using import libraries is that for new versions of the dll you only need to update the header adding the new declares or even adding the declares in your application.
St_W
Posts: 1264
Joined: Feb 11, 2009 14:24
Location: Austria
Contact:

Re: A fast CPRNG

Postby St_W » Aug 07, 2017 19:54

Josep Roca wrote:How? I only find propsys.lib, whereas FB wants libpropsys.dll.a.
You should be able to use propsys.lib directly. (Otherwise you can also try to just rename it.) The linker searches for multiple variants of the library name.

And of course make sure that you use the 64-bit version for 64-bit FB and the 32-bit import library for 32-bit FB. Otherwise you'll get an error like this:
ld.exe: skipping incompatible ./libname.lib when searching for -llibname

//edit: thank you for explaining how library usage is implemented in PowerBasic. Of course it can't be mapped 1:1 to FreeBasic (due to the existing library handling implementation, if one wants to keep backward-compatibility), but it definitely gives a good idea how it could work.
deltarho[1859]
Posts: 1014
Joined: Jan 02, 2017 0:34
Location: UK

Re: A fast CPRNG

Postby deltarho[1859] » Dec 11, 2017 17:31

Replace

Code: Select all

#If (ALGO = 1)
  Private Sub CleanUpCryptoRndIIBuffer
    BCryptCloseALGOrithmProvider( hRand, 0  )
    CloseThreadpoolWork(Work1)
    CloseThreadpoolWork(Work1plus)
    CloseThreadpool(Pool)
  End Sub
#Endif

with

Code: Select all

#If (ALGO = 1)
  Sub on_exit( ) Destructor
    BCryptCloseALGOrithmProvider( hRand, 0  )
    CloseThreadpoolWork(Work1)
    CloseThreadpoolWork(Work1plus)
    CloseThreadpool(Pool)
  End Sub
#Else
  Sub on_exit( ) Destructor
    CloseThreadpoolWork(Work1)
    CloseThreadpoolWork(Work1plus)
    CloseThreadpool(Pool)
  End Sub
#Endif

We don't have to remember to call CleanUpCryptoRndIIBuffer now.
Last edited by deltarho[1859] on Dec 12, 2017 13:08, edited 1 time in total.
deltarho[1859]
Posts: 1014
Joined: Jan 02, 2017 0:34
Location: UK

Re: A fast CPRNG

Postby deltarho[1859] » Dec 11, 2017 21:09

Just had a crash on termination. Not the Destructor.

There are two ReDims, they should be 'As UByte' and not 'As Byte'. That has not been an issue until now - don't know why.
deltarho[1859]
Posts: 1014
Joined: Jan 02, 2017 0:34
Location: UK

Re: A fast CPRNG

Postby deltarho[1859] » Dec 12, 2017 13:19

The clean up dates back to CryptoRnd which used threads and the only clean up was BCryptCloseALGOrithmProvider used with 'ALGO = 1'. With CryptoRndII the thread pool objects got deleted as well. However, 'ALGO = 2' also uses thread pools so we need to clean up there as well.

The last but one post now has the correct clean up to use.

Without the correction we would get a memory leak when using 'ALGO = 2'. The leak would only occur per instance of CryptoRndII, it would not accumulate during a CryptoRndII session.

I should add that if I need cryptographic random numbers and speed is not an issue (62.8MHz for 32 bit 120.2MHz for 64 bit) then I will use 'ALGO = 2'. If I want the very best quality random numbers, with speed not an issue and I do not need to repeat sequences then I will use 'ALGO = 2' here as well. Of course, if your PC does not support Intel's RdRand then CryptoRndII will not compile with 'ALGO = 2', I reckon.
deltarho[1859]
Posts: 1014
Joined: Jan 02, 2017 0:34
Location: UK

Re: A fast CPRNG

Postby deltarho[1859] » Jan 21, 2018 19:07

I am currently reading 'Serious Cryptography: A Practical Introduction to Modern Encryption' by Jean-Philippe Aumasson, which was very recently published. From a quality perspective CryptoRndII is top drawer and it is very fast. However, even though it is a CPRNG, as opposed to a PRNG, it seems that my implementation has compromised the security aspect and should not be used in cryptographic work. The implementation is about speed and I treated the cryptographic aspect as a bonus. It was not a bonus - the cryptographic aspect went 'out of the window'.

If you are into crypto' this book is a good read, so far - only five reviews at Amazon but all five stars and it is receiving a good press.

Return to “Windows”

Who is online

Users browsing this forum: No registered users and 3 guests