I’m using OpenSSL as a module in PHP (php_openssl), and I need to call
the CGI page may times per second
but the initialization process in RAND_poll is too slow.
I’m thinking to modify OpenSSL to use the rtlGenRandom call available in
XP/2003 Server/Vista OSs
(see http://blogs.msdn.com/michael_howard/archive/2005/01/14/353379.aspx
for comments on rtlGenRandom )
Does the above statements and posted code means that you can actually
confirm that you've verified that it's call to CryptGenRandom [or
CryptAcquireContext] that is holding RAND_poll back and not something
else? If not, then one should first figure out that, rather than jumping
at something they don't guarantee there is and even in clear text advise
to favor CryptGenRandom. Once it's done one should make an effort to
find a [more] legitimate way to optimize the "guilty" one.
As for CryptGenRandom and "RtlGenRandom" in more general sense. Registry
access tracing suggests that both calls maintain a shared 80-bit
Cryptography\RNG\Seed value in HKLM. How do unprivileged programs do it
is actually [smaller] mystery, because the key is not writable for
mortals [what I see is most likely kernel driver access accounted to my
user-land application]. But what appears alerting is that the key value
is publicly readable, meaning that adversary non-privileged application
can follow its changes. Is there evidence that this adversary
application can't deduce the random values obtained by application based
on observed seed values? A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
