You can always implement your own source of random data and
push it into
the OpenSSL engine. If you do that the rand_win code will not be
executed.
Jeffrey Altman
As far as I can tell from reading rand_win.c and md_rand.c, this is not the
case.
Calling any of the useful rand
If that is the case, then THAT is the bug to be fixed.
- Jeffrey Altman
Lee Dilkie wrote:
You can always implement your own source of random data and
push it into
the OpenSSL engine. If you do that the rand_win code will not be
executed.
Jeffrey Altman
As far as I can tell from reading
I do not actually believe that a one time 30 second delay during process
initialization is inappropriate for a security application. In the
discussions that are being held with regards to the use of AES in
conjunction with Kerberos there is a belief that 30 seconds should be
the minimum
I do not actually believe that a one time 30 second delay
during process
initialization is inappropriate for a security application. In the
discussions that are being held with regards to the use of AES in
conjunction with Kerberos there is a belief that 30 seconds should be
the minimum
Lee Dilkie wrote:
well, it's a bit more complicated than that. all the heaps of all the
processes are walked. They don't have to be big, just lots of them. Which is
why this isn't a problem on some systems running few processes or with small
heap list lengths and is a big problem on others
I know this has been brought up a few times on this list - but since I
consider it a severe problem and I haven't found an acceptable solution
anywhere, I bring it up again.
Random number generation in crypto/rand/rand_win.c can be extremely
slow!
In our application (connecting to a SSL web
