Results 1 to 21 of 21

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

  1. #1

    Thread Starter
    Frenzied Member
    Join Date
    Oct 2008
    Posts
    1,181

    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.
    Last edited by Ben321; Mar 10th, 2017 at 05:31 AM.

  2. #2
    Fanatic Member
    Join Date
    Jul 2007
    Location
    Essex, UK.
    Posts
    578

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

    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

  3. #3

    Thread Starter
    Frenzied Member
    Join Date
    Oct 2008
    Posts
    1,181

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

    Quote Originally Posted by Steve Grant View Post
    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.

  4. #4
    Fanatic Member
    Join Date
    Jul 2007
    Location
    Essex, UK.
    Posts
    578

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

    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!!!

  5. #5
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

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

    Quote Originally Posted by Ben321 View Post
    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.

  6. #6

    Thread Starter
    Frenzied Member
    Join Date
    Oct 2008
    Posts
    1,181

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

    Quote Originally Posted by dilettante View Post
    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).

  7. #7

    Thread Starter
    Frenzied Member
    Join Date
    Oct 2008
    Posts
    1,181

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

    Quote Originally Posted by Steve Grant View Post
    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.
    Last edited by Shaggy Hiker; Mar 16th, 2017 at 12:04 PM. Reason: Removed attachment, with regret.

  8. #8
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

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

    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.

  9. #9

    Thread Starter
    Frenzied Member
    Join Date
    Oct 2008
    Posts
    1,181

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

    Quote Originally Posted by dilettante View Post
    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":
    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.

  10. #10
    Fanatic Member
    Join Date
    Jul 2007
    Location
    Essex, UK.
    Posts
    578

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

    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

  11. #11

    Thread Starter
    Frenzied Member
    Join Date
    Oct 2008
    Posts
    1,181

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

    Quote Originally Posted by Steve Grant View Post
    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.
    Last edited by Ben321; Mar 13th, 2017 at 03:29 AM.

  12. #12
    Fanatic Member
    Join Date
    Jul 2007
    Location
    Essex, UK.
    Posts
    578

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

    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;
    Last edited by Steve Grant; Mar 13th, 2017 at 08:58 AM.

  13. #13
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    6,582

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

    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.

  14. #14
    Fanatic Member
    Join Date
    Aug 2013
    Posts
    806

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

    Quote Originally Posted by Ben321 View Post
    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:

    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.)
    Check out PhotoDemon, a pro-grade photo editor written completely in VB6. (Full source available at GitHub.)

  15. #15
    Fanatic Member
    Join Date
    Jul 2007
    Location
    Essex, UK.
    Posts
    578

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

    @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.

  16. #16

    Thread Starter
    Frenzied Member
    Join Date
    Oct 2008
    Posts
    1,181

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

    Quote Originally Posted by passel View Post
    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.

  17. #17

    Thread Starter
    Frenzied Member
    Join Date
    Oct 2008
    Posts
    1,181

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

    Quote Originally Posted by Steve Grant View Post
    @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.

  18. #18

    Thread Starter
    Frenzied Member
    Join Date
    Oct 2008
    Posts
    1,181

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

    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.

  19. #19
    Fanatic Member
    Join Date
    Jul 2007
    Location
    Essex, UK.
    Posts
    578

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

    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!

  20. #20
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,988

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

    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.
    My usual boring signature: Nothing

  21. #21

    Thread Starter
    Frenzied Member
    Join Date
    Oct 2008
    Posts
    1,181

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

    Quote Originally Posted by Steve Grant View Post
    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"

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width