1

I will be generating RSA keys in a multi thread application. I use RtlGenRandom as RNG.

I know I can call in multi threads with hanging/crash or bugs.

My question is:

May calling RtlGenRandom in multiple threads give me duplicate bytes on each thread?

Please don't remind me to use CNG or cryptgenrandom as this answer says they all end up in bcryptPrimitives!AesRNG*.

titan
  • 13
  • 5
  • Does this answer your question? [Is CryptGenRandom() thread-safe?](https://stackoverflow.com/questions/46147805/is-cryptgenrandom-thread-safe) – Simon Mourier Nov 21 '20 at 15:26
  • @SimonMourier thanks for you effort , it does not, that question is about CryptGenRandom not RrlGenRandom , CryptGenRandom has a few more functions (warppers) in the way to bcryptPrimitives!AesRNG and it requires some additional objects when called ,that answer CryptGenRandom does serialize calls so safe,RrlGenRandome has different route so we can't judge – titan Nov 21 '20 at 15:46
  • 1
    Only Microsoft could tell you that for sure. But Microsoft basically says you should get away from this function. Anyway, if you disassemble it, you find the "ProcessPrng -> AesRNGState_generate -> SymCryptRngAesGenerate" (last function is public https://github.com/microsoft/SymCrypt/blob/master/lib/aesCtrDrbg.c) function call chains and there are also EnterCriticalSection calls along the way, so I'd "imagine" it's thread safe. See also https://github.com/golang/go/issues/33542 – Simon Mourier Nov 21 '20 at 16:59
  • @SimonMourier thanks, i think you can write it as an answer and i'll accept – titan Nov 22 '20 at 16:10
  • i did some experments my self i couldn't get 10bytes of duplicate data in 100mb buffers – titan Nov 22 '20 at 16:11

1 Answers1

1

Only Microsoft could tell you that for sure, or what exactly is the contract behind that function, but Microsoft basically says you should get away from this function.

The RtlGenRandom function is available for use in the operating systems specified in the Requirements section. It may be altered or unavailable in subsequent versions. Instead, use the CryptGenRandom function

Anyway, if you disassemble it, you find the

ProcessPrng -> AesRNGState_generate -> SymCryptRngAesGenerate

function call chains and there are also EnterCriticalSection calls along the way, so I'd "imagine" it's thread safe.

PS: the last SymCryptRngAesGenerate function is open source.

See also this crypto/rand: Currently using deprecated API for random number generation on Windows github discussion about the subject.

Kirko
  • 64
  • 4
Simon Mourier
  • 132,049
  • 21
  • 248
  • 298