Here's a better way to generate random nums than using Rnd

Using Rnd always gives you the same set of numbers, whenever you start the program. Even if you use Randomize first to set a random number seed at the start of the program, it will eventually cycle through all the numbers (plus there are certain patterns of numbers that you can see under certain situations). You can get a much better random number generator (in fact, cryptographically secure level of randomness) if you used the crypto API functions. Here's a simple program I made to demonstrate how to use the crypto API to generate random numbers.

Code:

---

Private Declare Function CryptAcquireContext Lib "advapi32.dll" Alias "CryptAcquireContextA" (ByRef phProv As Long, ByVal pszContainer As String, ByVal pszProvider As String, ByVal dwProvType As Long, ByVal dwFlags As Long) As Long
Private Declare Function CryptReleaseContext Lib "advapi32.dll" (ByVal hProv As Long, ByVal dwFlags As Long) As Long
Private Declare Function CryptGenRandom Lib "advapi32.dll" (ByVal hProv As Long, ByVal dwLen As Long, ByRef pbBuffer As Any) As Long

Private Declare Sub Sleep Lib "kernel32.dll" (ByVal dwMilliseconds As Long)

Dim hProv As Long
Dim Quit As Boolean

Private Sub Form_Load()
    Dim a As Long
    CryptAcquireContext hProv, vbNullString, vbNullString, 1, 0
   
    If hProv = 0 Then
        Unload Me
        Exit Sub
    End If
   
    Show
    Do Until Quit
        CryptGenRandom hProv, 4, a
        Cls
        Print a
        Sleep 100
        DoEvents
    Loop

End Sub

Private Sub Form_Unload(Cancel As Integer)
    Quit = True
    If hProv Then CryptReleaseContext hProv, 0
End Sub

---

Just paste the above code into your Form1, and make sure that its AutoRedraw property is set to True. Then run the program, it will generate a new random number every tenth of a second (that's what "Sleep 100" is for). I have it doing that instead of running at max speed, so as not to max out your CPU cycles and cause unnecessary heating of your computer if you leave it running for a while. If you don't intend to have it running for a long time, you can remove the Sleep 100 line of code, so it can run at maximum speed (limited only by your CPU speed). Just close the Form1 window to end the program (make sure you DON'T use the stop button in the VB6 IDE, or the Unload event won't fire, and it won't run the required cleanup function CryptReleaseContext.

CryptGenRandom will NEVER repeat a set of numbers, and will NEVER produce any visible pattern of numbers.

This does nothing on Win10 home 64bit. hProv is always zero.

If I add the following constants and change the 1,0 in the call then it works. But I find it uncontrollable as a random number generator. Also if you reduce the dwLen parameter from 4 down to 1, it readily produces duplicates.

Code:

---

Private Const PROV_RSA_FULL As Long = 1
Private Const CRYPT_VERIFYCONTEXT As Long = &HF0000000

---

Quote:

---

Originally Posted by Steve Grant

This does nothing on Win10 home 64bit. hProv is always zero.

If I add the following constants and change the 1,0 in the call then it works. But I find it uncontrollable as a random number generator. Also if you reduce the dwLen parameter from 4 down to 1, it readily produces duplicates.

Code:

---

Private Const PROV_RSA_FULL As Long = 1
Private Const CRYPT_VERIFYCONTEXT As Long = &HF0000000

---

---

You must be doing something wrong then. I wrote this program while using VB6 on Windows 10 64bit. I have never had it give me an hProv of 0, or repeat numbers in the sequence.

Well as you are expert/arrogant enough to be able to tell me 'I must be doing something wrong!' Perhaps you can tell me what is wrong with this scenario;

Directly copy all code from post #1, paste into VB6 Pro SP6 on 64bit Win 10 Home. Change forms AutoRedraw to true then run programme.

There is a very brief flash and then the programme quits. Re-run the programme checking the value of hProv, it is ZERO therefore triggers the unload event!!!

Quote:

---

Originally Posted by Ben321

CryptGenRandom will NEVER repeat a set of numbers, and will NEVER produce any visible pattern of numbers.

---

Not true, and you wouldn't want it to be. Imagine a penny you can only flip twice. Once you get heads and tails then it refuses to flip ever again? Besides, even if that worked it wouldn't be random at all. Same for a 6-sided die, or anything else.

I think you are after a "shuffle and deal" algorithm or something. This isn't it.

Quote:

---

Originally Posted by dilettante

Not true, and you wouldn't want it to be. Imagine a penny you can only flip twice. Once you get heads and tails then it refuses to flip ever again? Besides, even if that worked it wouldn't be random at all. Same for a 6-sided die, or anything else.

I think you are after a "shuffle and deal" algorithm or something. This isn't it.

---

Actually of course for small numbers there will be repeats, like you will eventually get repeats like 255 will occur once, and if you keep using CryptGenRandom, you will get 255 a second time, but what if you don't just look at one byte, what if you look at 2 consecutive bytes? Well if you look at that then of course 255 followed by 255 will be less likely to happen, than simply 255 followed by any number. And the longer the string of bytes that you look at, for which you ask the question "How likely is this combination" the more improbable it gets, up to a certain point.

With VB6's internal Rnd command. it returns a value of type Single, which takes 4 bytes. Any 4 byte number can only hold 4 billion possible values, and with single precision floating point values, quite a few of these values represent error conditions or infinity, further limiting the pool of valid numbers. So if you run it enough times, you can GUARENTY that you will run through EVERY POSSIBLE VALUE. And after that, the entire pattern of numbers just repeats itself. And not only does it use the same pool of numbers, but they always occur in the EXACT SAME ORDER.

With CryptGenRandom, it is guarentied to NEVER repeat itself. If you run it 4 billion times (assuming you are using it to generate 4byte values), you will get one set of numbers. If you run it another 4 billion times, even though you will be using the same set of numbers, they won't be in the same order. The order will be COMPLETELY DIFFERENT from the first time it was run through all possible combinations. Unlike VB6's Rnd function, CryptGenRandom does NOT use a simple "add then multiply" pseudo random number generator. Instead, according to Microsoft documentation, it uses a hashing technique. A bunch of of data from the system (harddrive serial number, value returned from the last time that the function was run, current system time, etc) is concatenated together and then fed into a cryptographic hash function, to generate a highly random number. Because it takes current system time into account, and the probability of selecting a specific instant (down to the milisecond) at which you run the function is nearly impossible, it is more than just pseudo-random. It can be considered truly random. Because it takes hardware info from your PC, it also guaranties that it will be unique to your PC, so even if 2 computers were synchronized to run the function at the exact same time, it would be different for the 2 separate computers. Furthermore, because it takes into account the output value from when it was last called, if another program that is using crypto functions happens to call it at some point you are not aware of, that isn't the specific program you are working with at the moment, that further adds randomness to it. This means even if you knew what the last value returned from the current program was, and knew all of the other factors (including the time, down to the millisecond), and knew what the algorithm was so that you could calculate ahead what you expected the new output to be, if another program running happens to call this function (and this is quite likely as there are many background/system processes running on a typical PC, and many of these probably use crypto functions in one way or another), it will cause the output when you called it to be different from what you predicted it would be.

Therefore, CryptGenRandom is the BEST POSSIBLE random number generator you can use, short of using a hardware random number generator that depends on thermal/quantum noise (which is a VERY EXPENSIVE piece of equipment).

Quote:

---

Originally Posted by Steve Grant

Well as you are expert/arrogant enough to be able to tell me 'I must be doing something wrong!' Perhaps you can tell me what is wrong with this scenario;

Directly copy all code from post #1, paste into VB6 Pro SP6 on 64bit Win 10 Home. Change forms AutoRedraw to true then run programme.

There is a very brief flash and then the programme quits. Re-run the programme checking the value of hProv, it is ZERO therefore triggers the unload event!!!

---

I just started a new instance of VB6, copied the code into it, and ran it. It worked as expected. I do not know what you did, but it clearly is making the program not work. Try copying the code again, and make sure you get every line of code, so that you know you didn't accidentally miss a line of code when copying it. Start a new instance of VB6, paste it into the Form1 code section, and set the form's AutoRedraw property to true. Then run the program.

If it still does not work for you, copy the entirety of your form's code, and paste it in a reply to this thread, and I will see what (if anything) is wrong with your copy of the code.

Also, I have included a compiled EXE copy of this program in this post. It is in the ZIP file RandomTest.zip which I have attached to this post. Try running the EXE version on your computer. It may be that your copy of VB6 isn't compiling or interpreting correctly, so I have included this, just in case that's what's happening.

CryptGenRandom() wraps a call to RtlGenRandom() which has already been covered to death here.

It is not magical and has few of the amazing attributes you ascribe to it.

Quote:

---

Originally Posted by dilettante

CryptGenRandom() wraps a call to RtlGenRandom() which has already been covered to death here.

It is not magical and has few of the amazing attributes you ascribe to it.

---

According to https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx in the section called "Remarks":

Quote:

---

With Microsoft CSPs, CryptGenRandom uses the same random number generator used by other security components. This allows numerous processes to contribute to a system-wide seed. CryptoAPI stores an intermediate random seed with every user. To form the seed for the random number generator, a calling application supplies bits it might have—for instance, mouse or keyboard timing input—that are then combined with both the stored seed and various system data and user data such as the process ID and thread ID, the system clock, the system time, the system counter, memory status, free disk clusters, the hashed user environment block. This result is used to seed the pseudorandom number generator (PRNG). In Windows Vista with Service Pack 1 (SP1) and later, an implementation of the AES counter-mode based PRNG specified in NIST Special Publication 800-90 is used. In Windows Vista, Windows Storage Server 2003, and Windows XP, the PRNG specified in Federal Information Processing Standard (FIPS) 186-2 is used. If an application has access to a good random source, it can fill the pbBuffer buffer with some random data before calling CryptGenRandom. The CSP then uses this data to further randomize its internal seed. It is acceptable to omit the step of initializing the pbBuffer buffer before calling CryptGenRandom.

---

Note in particular where it says: "To form the seed for the random number generator, a calling application supplies bits it might have—for instance, mouse or keyboard timing input—that are then combined with both the stored seed and various system data and user data such as the process ID and thread ID, the system clock, the system time, the system counter, memory status, free disk clusters, the hashed user environment block."

It also states that with Vista SP1 and later it uses a NIST specification for the random generator, and in XP it uses a FIPS specification for the random generator. Both of these are very advanced, and are far more random than VB6's internal Rnd function.

Also note that nowhere does it say that CryptGenRandom is equivalent to RtlGenRandom. In fact, common sense would say they are significantly different. RtlGenRandom does not have an argument to pass the crypto provider's handle (called hProv), but CryptGenRandom does have this function argument. It would seem that the randomness of CryptGenRandom depends on what level of security is required, which is determined by how advanced of a crypto provider you select. Whereas with RtlGenRandom a default level of randomness must be used, because there's no argument to pass an hProv to that function.

In fact, if you look at https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx which provides the documentation for RtlGenRandom, it says to NOT use that function, and to instead use CryptGenRandom, as RtlGenRandom may be removed in future versions of Windows. If CryptGenRandom were just a wrapper function for RtlGenRandom, then removing RtlGenRandom would disable CryptGenRandom's ability to run properly. So these are clearly 2 separate functions, unless you can provide Microsoft documentation that shows that CryptGenRandom actually uses RtlGenRandom.

Right here is my current code copied from post #1. It does not work. Your exe does not work either (a very brief flash of something and then nothing). Instead of keep saying I must be doing something wrong, why not look at the bigger picture. I am using Win10 Home 64bit, version 1607, build 14393.693. 8GB Ram, Athlon A10-7700K 4.2GHz. Is your system so very different?

Code:

---

Option Explicit
Private Declare Function CryptAcquireContext Lib "advapi32.dll" Alias "CryptAcquireContextA" (ByRef phProv As Long, ByVal pszContainer As String, ByVal pszProvider As String, ByVal dwProvType As Long, ByVal dwFlags As Long) As Long
Private Declare Function CryptReleaseContext Lib "advapi32.dll" (ByVal hProv As Long, ByVal dwFlags As Long) As Long
Private Declare Function CryptGenRandom Lib "advapi32.dll" (ByVal hProv As Long, ByVal dwLen As Long, ByRef pbBuffer As Any) As Long

Private Declare Sub Sleep Lib "kernel32.dll" (ByVal dwMilliseconds As Long)

Dim hProv As Long
Dim Quit As Boolean

Private Sub Form_Load()
    Dim a As Long
    CryptAcquireContext hProv, vbNullString, vbNullString, 1, 0
   
    If hProv = 0 Then
        Unload Me
        Exit Sub
    End If
   
    Show
    Do Until Quit
        CryptGenRandom hProv, 4, a
        Cls
        Print a
        Sleep 100
        DoEvents
    Loop

End Sub

Private Sub Form_Unload(Cancel As Integer)
    Quit = True
    If hProv Then CryptReleaseContext hProv, 0
End Sub

---

Quote:

---

Originally Posted by Steve Grant

Right here is my current code copied from post #1. It does not work. Your exe does not work either (a very brief flash of something and then nothing). Instead of keep saying I must be doing something wrong, why not look at the bigger picture. I am using Win10 Home 64bit, version 1607, build 14393.693. 8GB Ram, Athlon A10-7700K 4.2GHz. Is your system so very different?

Code:

---

Option Explicit
Private Declare Function CryptAcquireContext Lib "advapi32.dll" Alias "CryptAcquireContextA" (ByRef phProv As Long, ByVal pszContainer As String, ByVal pszProvider As String, ByVal dwProvType As Long, ByVal dwFlags As Long) As Long
Private Declare Function CryptReleaseContext Lib "advapi32.dll" (ByVal hProv As Long, ByVal dwFlags As Long) As Long
Private Declare Function CryptGenRandom Lib "advapi32.dll" (ByVal hProv As Long, ByVal dwLen As Long, ByRef pbBuffer As Any) As Long

Private Declare Sub Sleep Lib "kernel32.dll" (ByVal dwMilliseconds As Long)

Dim hProv As Long
Dim Quit As Boolean

Private Sub Form_Load()
    Dim a As Long
    CryptAcquireContext hProv, vbNullString, vbNullString, 1, 0
   
    If hProv = 0 Then
        Unload Me
        Exit Sub
    End If
   
    Show
    Do Until Quit
        CryptGenRandom hProv, 4, a
        Cls
        Print a
        Sleep 100
        DoEvents
    Loop

End Sub

Private Sub Form_Unload(Cancel As Integer)
    Quit = True
    If hProv Then CryptReleaseContext hProv, 0
End Sub

---

---

As it is currently set with vbNullString for provider name, it uses the default provider for the current user. Depending on your current user permissions on your computer, that default could vary, so you may not be getting the same crypto provider (or possibly none at all) that I'm getting in my call to CryptAcquireContext. If the current default crypto provider does not support the use of CryptGenRandom, or if you are getting no crypto provider, then of course you can't make a call to CryptGenRandom.

So I have a question for you. Are you using a "user" level Windows account or an "administrator" level Windows account? I'm logged in as an administrator account. If your account is only at a user level, then you may have a very underpowered default crypto provider or even no default crypto provider.

Well this gave me food for thought, so I ran your exe with 'Run as Admin' but no change. I also tried setting net user to admin in an elevated cmd windows, no difference. Please also look at post 2 again. Here is my account name and I guess what you are looking for;

Perhaps one of you has an Intel processor and the other an AMD. While quite compatible, they are not 100% compatible. Not all software problems are software problems. Hardware can make a difference, unfortunately.

Quote:

---

Originally Posted by Ben321

Also note that nowhere does it say that CryptGenRandom is equivalent to RtlGenRandom. In fact, common sense would say they are significantly different.

---

We must have different definitions of "common sense." Verification of dilettante's original statement, which is 100% correct:

Quote:

---

On a default Windows XP and later install, CryptGenRandom calls into a function named ADVAPI32!RtlGenRandom, which does not require you load all the CryptAPI stuff.

---

@Steve: you are a good man to try and help a frequently aggressive forum member. The original code sample has a number of problems (you should generally always supply your own provider name, as the "default" one varies by system and is unpredictable - as you've discovered!), but if you want to continue to debug this, I'd check the value of Err.LastDllError after the initial call to CryptAcquireContext. This may have additional details.

Or you could just forgo this sample entirely, and manually request a known provider per the MSDN documentation. I think there are a number of code samples here in the forums that demonstrate this. (If not, feel free to start your own thread. You'd probably get a lot more participation from members that have learned to avoid threads from certain problematic participants.)

@Tanner: As always you are a wise man. Point taken!

@Passel: Yes I am on AMD.

I don't need this function, I was just curious. Now I've just done a forum search and find that Ben has submitted this in the past and been rebuked for his not doing the job properly. I feel like a fool.

Quote:

---

Originally Posted by passel

Perhaps one of you has an Intel processor and the other an AMD. While quite compatible, they are not 100% compatible. Not all software problems are software problems. Hardware can make a difference, unfortunately.

---

I have Intel, not AMD. I don't think this makes a difference though for CryptGenRandom though. I don't think that CryptGenRandom depends on any CPU-specific randomness function (in fact I don't even think that any consumer-level CPUs have internal randomness functions).

Checking the lower level (API level) error that's being generated might help solve this.

Quote:

---

Originally Posted by Steve Grant

@Tanner: As always you are a wise man. Point taken!

@Passel: Yes I am on AMD.

I don't need this function, I was just curious. Now I've just done a forum search and find that Ben has submitted this in the past and been rebuked for his not doing the job properly. I feel like a fool.

---

Have you checked for the actual API level error yet? You CLAIMED you were going to do so, but have not yet posted it here. PLEASE DO SO. It will help me to figure out EXACTLY why the default crypto provider failed to allow for random number generation (or why it failed to even get a crypto provider, if in fact it didn't get one).


Until that's figured out though. Here's the revised code, which does not depend on getting a default crypto provider, but rather explicitly specifies one by name. In this case, it's the Microsoft Base crypt provider.

Code:

---

Private Declare Function CryptAcquireContext Lib "advapi32.dll" Alias "CryptAcquireContextA" (ByRef phProv As Long, ByVal pszContainer As String, ByVal pszProvider As String, ByVal dwProvType As Long, ByVal dwFlags As Long) As Long
Private Declare Function CryptReleaseContext Lib "advapi32.dll" (ByVal hProv As Long, ByVal dwFlags As Long) As Long
Private Declare Function CryptGenRandom Lib "advapi32.dll" (ByVal hProv As Long, ByVal dwLen As Long, ByRef pbBuffer As Any) As Long

Private Declare Sub Sleep Lib "kernel32.dll" (ByVal dwMilliseconds As Long)

Private Const BaseProvider As String = "Microsoft Base Cryptographic Provider v1.0"
Private Const EnhancedProvider As String = "Microsoft Enhanced Cryptographic Provider v1.0"
Private Const StrongProvider As String = "Microsoft Strong Cryptographic Provider"




Dim hProv As Long
Dim Quit As Boolean

Private Sub Form_Load()
    Dim a As Long
    CryptAcquireContext hProv, vbNullString, BaseProvider, 1, 0
   
    If hProv = 0 Then
        Unload Me
        Exit Sub
    End If
   
    Show
    Do Until Quit
        CryptGenRandom hProv, 4, a
        Cls
        Print a
        Sleep 100
        DoEvents
    Loop

End Sub

Private Sub Form_Unload(Cancel As Integer)
    Quit = True
    If hProv Then CryptReleaseContext hProv, 0
End Sub

---

Just copy and paste this code into your form. and make sure your form's AutoRedraw property is set to True.

If for some reason the Base provider isn't working, go to the line that says

Code:

---

CryptAcquireContext hProv, vbNullString, BaseProvider, 1, 0

---

and change BaseProvider to either EnhancedProvider or StrongProvider.

By the way, can somebody here provide the PROOF that RtlGenRandom is in fact called by CryptGenRandom? If so, using RtlGenRandom is certainly MUCH EASIER to use.

Quote:

---

You CLAIMED you were going to do so

---

Where EXACTLY did I claim to do so?

Just to shut you up! Here is the error codes from your new version which does not work either. All 3 were tried with exactly the same Err.LastDllError = -2146893802. Err.description remained blank.

Your rudeness astounds me - we are done!

Some of you folks have been around here long enough to rub each other raw, and it's showing in this thread. I did have to remove that one attachment, as it was compiled code, which isn't allowed in CodeBank, either. I considered cleaning out some of the gratuitous comments, but there wasn't any bad language, only the strange behavior of people who've run up against each other too often. Please try to keep it respectful.

Quote:

---

Originally Posted by Steve Grant

Here is the error codes from your new version which does not work either. All 3 were tried with exactly the same Err.LastDllError = -2146893802. Err.description remained blank.

---

According to MSDN, that means NTE_BAD_KEYSET. The answer may be to use CRYPT_VERIFYCONTEXT in the dwFlags field of the CryptAcquireContext function. The value for the CRYPT_VERIFYCONTEXT constant is &HF0000000. With that as the dwFlags value, try using CryptAcquireContext with vbNullString again as the pszProvider field (and if that still doesn't work, keep using CRYPT_VERIFYCONTEXT as dwFlags but now try also explicitly using these 3 different crypto provider constants in the pszProvider field).

Code:

---

Private Const BaseProvider As String = "Microsoft Base Cryptographic Provider v1.0"
Private Const EnhancedProvider As String = "Microsoft Enhanced Cryptographic Provider v1.0"
Private Const StrongProvider As String = "Microsoft Strong Cryptographic Provider"

---