On 24 April 2017 at 13:50, Daniel P. Berrange <berra...@redhat.com> wrote: > For subject line, better to describe the change made, rather than > the problem. > > On Mon, Apr 24, 2017 at 02:17:56PM +0200, gm.ijew...@web.de wrote: >> Now it calls CryptGenRandom() if is it compiled for windows. >> >> It might be possible to save the cryptographic provider in between >> invocations, e.g. by making it static -- I have no idea how computationally >> intensive that operation actually is. > > I'd think most people should really just enable gnutls during build. This just > has to provide a fallback that's good enough to be functional. If someone > really > cares about performance of this fallback, they can send patches later....
What I think is more worrying is the suggestion in the CryptAcquireContext docs that this might for instance prompt the user for a password to decrypt keys. We definitely don't want to do that every time. In fact we'd rather not do it at all. Googling suggests that the approach used by web browsers is to use the not-very-documented RtlGenRandom function: https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/freebl/win_rand.c#141 https://chromium.googlesource.com/chromium/src.git/+/master/base/rand_util_win.cc That looks much simpler than trying to use the official crypto APIs. (It's also what the MS C runtime library does to implement rand_s().) thanks -- PMM