Bug ID: JDK-8326123 The MSCAPI provider does not fully support the CNG APIs

There is always a way to implement it. See P11SecureRandom.
08-05-2024
Response from the submitter to [~weijun]: I don’t know that it’s going to be possible to implement SetSeed. You might say in the release you choose to implement BCryptGenRandom to say something along the lines of “in this release, it was discovered that Microsoft’s implementation of Random Number Generation in Windows 8 and later no longer accepts seed input. As such, this function is deprecated in this release and simply returns a success error code while performing no operation”
08-05-2024
Microsoft has confirmed your observation. Therefore it's safe to switch from CryptGenRandom to BCryptGenRandom. We will need to find out how to implement `setSeed`.
06-05-2024
Additional information from the submitter: The CryptGenRandom references the call to bcryptprimitives.dll with CERT 258. That cert is listed here (https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/details?validation=23567) and to answer that question would need to be answered by Microsoft themselves more likely than not. (FIPS@microsoft.com) Looking at Microsoft’s documentation on their FIPS submissions (https://learn.microsoft.com/en-us/windows/security/security-foundations/certification/validations/fips-140-windows-previous#windows-8) their submission on bcryptprimitives.dll suggests that the entropy to the RNG is supplied by an in-kernel RNG and that user supplied entropy is not used. This all seems to suggest that calling “setSeed” (or equivalent on Windows 8 and later offers no entropy input and since the release of Windows 8, 10, and 11, the setSeed function has done nothing. As I stated above, if the preference is for backward compatibility, then creating a CNG provider with a security.cpp (or other) that would provide only CNG functionality would allow those who have used CAPI (and still continue to do so) on Windows 7 or earlier machines to do so, while Windows XP and later machines can take advantage of the CNG features that are in Windows, including the merge of the CryptGenRandom and BCryptGenRandom function on Windows 8 and later machines.
10-04-2024
No, this is not for backward compatibility since we we won't change the APIs. This is just semantic: if setSeed() is meant to add user provided entropy, then it had better do so. On the other hand, if I understand correctly, you seem to believe that even the legacy CryptGenRandom does not add any user provided entropy after Windows 7 because it's using the same underlying mechanism as CNG. If this is true (quite likely), then we can switch the CNG function with no lost of function. I should ask Microsoft on this. Thanks.
10-04-2024
OK, so you are saying that RNGs of CAPI and CNG are using the same underlying mechanism but the CNG function is certified recently and it's closer to the underlying mechanism (or itself is). The only concern is still the setSeed() method. If BCRYPT_RNG_USE_ENTROPY_IN_BUFFER is ignored now, it means setSeed has no effect in CNG. But, does it still have effect in CAPI? If yes, how could CAPI and CNG's RNG be equivalent? Or, does CAPI maintain its own mixed-in RNG that's seeded separately?
05-04-2024
Further information from the submitter: The benefit to switching to the new function is 3 fold: 1. NIST hasn’t certified (or Microsoft hasn’t submitted it for certification) the RSAENH.dll that CryptGenRandom comes from since December 2014 (almost 10 years ago). 2. The function clearly states in the Windows 8 submission (https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp1894.pdf) that CryptGenRandom “merely forwards the call to a FIPS approved RNG from the cryptographic Primitives Library (bcryptprimitives.dll)”. Therefore, moving to BCryptGenRandom will save the code an unnecessary step of forwarding every call to the bcryptprimitives.dll instead of just calling the function directly. 3. Microsoft hasn’t deprecated the CryptoAPI: Next Generation and since the call is functionally equivalent (on windows 8 and later) moving it bears no issue. Since windows 7 went EOL in 2020, all versions of the CryptGenRandom function that would have used the seed value (windows 7 and previous) haven’t been using it for over 4 years.
05-03-2024
Thanks a lot for the additional information. However, the BCryptGenRandom page still claims BCRYPT_RNG_USE_ENTROPY_IN_BUFFER is ignored since Windows 8. Also, if BCryptGenRandom and CryptGenRandom are equivalent, what is the benefit to switch to the new function?
04-03-2024
Additional information from the submitter: Sorry for belaboring a point, but I want to add in one more comment before this comes into review to hopefully add some context to help ease the move to BCryptGenRandom. In Windows 7 Microsoft updated CryptGenRandom to behave almost identically to BCryptGenRandom. https://learn.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptgenrandom (Under Remarks). https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptgenrandom (Under Remarks). Microsoft’s submission for the updated Enhanced Cryptographic Provider (which is the provider that the Java MSCAPI provider uses) contains more information. https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/1330 The section on CryptGenRandom states that the generator is initialized by the in-kernel PRNG and that caller supplied data “is mixed with the seed”. The in-kernel PRNG is in CNG.sys which is has the #4515 certificate. https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4515 This in-kernel PRNG is SystemPrng and both CryptGenRandom and BCryptGenRandom use it internally. (page 24-25, and the diagram in page 8). Because of the change between CAPI released with Windows XP and Vista and CAPI released with Windows 7 and later and its dependency on the in-kernel PRNG, there really isn’t a difference between calling CryptGenRandom the way that it’s been called, and moving to BCryptGenRandom. The result is the same that the user’s input data is put into the pool of entropy and then used to generate the seed for reseeding the PRNG from which the random number is generated.
04-03-2024
Additional information from the submitter: If the preference is to leave the current CAPI provider as it is, maybe there could be a new sun.security.mscng.SunMSCNG provider with the appropriate classes. The windows folder would then have a libsunmscng folder with a security.cpp file that implements the same functionality as the current security.cpp but with the cng functions (in the bcrypt.h header). The new Java release would have this new provider available for use (and hopefully backported) and would just have a comment in the javadoc saying that the engineSetSeed on the spi or the setSeed function on the SecureRandom that will say that the seed will be used as extra entropy (or will be discarded based on choice of implementation).
01-03-2024
Additional information from the submitter: This function doesn’t support seeding in a typical sense the way CAPI supports it. However, if you call it with dwFlags is set to BCRYPT_RNG_USE_ENTROPY_IN_BUFFER then you should be able to put the seed value set in the input buffer and use that as additional entropy. However, NIST has approved BCryptGenRandom for its functionality and it’s automatically reseeded by the platform and doesn’t need to be seeded externally. Like IBM (whose z platform also reseeds its approved RNG), it might be prudent to deprecate the function for the ms-capi provider when switching to BCryptGenRandom because there’s no reason to seed it.
27-02-2024
Requested above information from the submitter.
26-02-2024
We've looked into BCryptGenRandom in JDK-8213621 but it does not support the setSeed() method. Does the bug reporter have other particular areas where CNG is necessary?
22-02-2024
Moved to JDK for further investigations.
19-02-2024