Re: Slow crypto initialization.
Thanks for the information about the rt address. We sent the explanation and patch as you suggested, and can now see the issue on the tracker list. However, no one has commented on it. Are there additional steps we can take to further the process of accepting the patch? Thanks! Jake Goulding | Software Engineer gould...@vivisimo.com | Connect: www.vivisimo.com Vivisimo - Information Optimized - Ger Hobbelt g...@hobbelt.com wrote: Don't be sorry, this is great work!! I'm glad the culprit has been found (and fixed)! BTW: To help the OpenSSL core team help track and fix this, it would be good to submit your message + patch to r...@openssl.org so it ends up as an issue ticket in the tracker and this material does not disappear off the horizon of an ever progressing discussion list. A reference to this email thread in the RT would be handy, e.g.: http://www.bluequartz.us/phpBB2/viewtopic.php?t=131309 (the entire thread is easily viewable as a set of forum messages there, so one page carries all) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Slow crypto initialization.
The OpenSSL development team typically don't comment on a request until they've fixed it. (I believe this is poor customer service, but I also believe that I'm not entitled to good customer service until I've paid for it.) What appears to happen is this: 1) bug submitter sends an email to r...@openssl.org 2) rt records it, along with any attached patches, and mails openssl-dev and the core committers 3) One of the core committers (eventually) looks at it 4) One of the core committers (eventually) integrates it 5) The core committer comments on the bug about when the patch was checked in, or other pertinent details 6) Eventually, the next release of OpenSSL comes out, with the patch included. OpenSSL isn't an open open-source software, in that the core committers appear to maintain a separate mailing list where they coordinate how they're working on new pieces and how they're supposed to interact. (If I had to guess, I'd think that this was primarily done for the FIPS validation effort [since the CMVP is used to non-open-source development strategies], but it might have been that too many people without any knowledge of security were trying to suggest things that were completely and inexplicably just not getting the concepts of security is a chain of components, which is only as strong as its weakest link. I am not a member of the core committing team, and in fact I have no direct correspondence with them, so these are guesses.) It would be nice to interview the developers, and ask them what's different in 1.0.0 over 0.9.8, as well as to get an idea of their plans for the future and some of the flavors of their personalities. However, I'm also not a journalist, so I'm not the appropriate person to do that, either. However: the best way to add comments (including comments on how long it's taking to process your patch) to your bug report is not to complain on the openssl-users list, it's to reply to r...@openssl.org with your bug number in the Subject line. That will cause it to add your correspondence to its record, and bounce it to openssl-dev and all the developers. I wish there were a customer service organization for it as good as Debian's... but there are other issues there. -Kyle H On 7/27/10 1:31 PM, Jake Goulding wrote: Thanks for the information about the rt address. We sent the explanation and patch as you suggested, and can now see the issue on the tracker list. However, no one has commented on it. Are there additional steps we can take to further the process of accepting the patch? Thanks! Jake Goulding | Software Engineer gould...@vivisimo.com | Connect: www.vivisimo.com Vivisimo - Information Optimized - Ger Hobbelt g...@hobbelt.com wrote: Don't be sorry, this is great work!! I'm glad the culprit has been found (and fixed)! BTW: To help the OpenSSL core team help track and fix this, it would be good to submit your message + patch to r...@openssl.org so it ends up as an issue ticket in the tracker and this material does not disappear off the horizon of an ever progressing discussion list. A reference to this email thread in the RT would be handy, e.g.: http://www.bluequartz.us/phpBB2/viewtopic.php?t=131309 (the entire thread is easily viewable as a set of forum messages there, so one page carries all) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org smime.p7s Description: S/MIME Cryptographic Signature
Re: Slow crypto initialization.
Don't be sorry, this is great work!! I'm glad the culprit has been found (and fixed)! BTW: To help the OpenSSL core team help track and fix this, it would be good to submit your message + patch to r...@openssl.org so it ends up as an issue ticket in the tracker and this material does not disappear off the horizon of an ever progressing discussion list. A reference to this email thread in the RT would be handy, e.g.: http://www.bluequartz.us/phpBB2/viewtopic.php?t=131309 (the entire thread is easily viewable as a set of forum messages there, so one page carries all) On Fri, Jul 2, 2010 at 9:13 PM, Jake Goulding gould...@vivisimo.com wrote: -- Met vriendelijke groeten / Best regards, Ger Hobbelt -- web:http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 --
Re: Slow crypto initialization.
To start off with, we're sorry for any confusion we caused, but this
issue does not have any interaction with the heap-walking code. The
problem definitely has to do with the readscreen function. Making
readscreen() a no-op decreases initialization time by 3 seconds.
Delving more into the issue, we added debug prints to measure the
timing [1] of various sections of readscreen(). For our particular
case, the inner loop is called 47 times. Inside the loop, each
invocation of GetBitmapBits takes about 78ms. The total runtime of
readscreen alone was 3640ms.
The MSDN page indicates that GetBitmapBits is a 16-bit Windows
compatibility function [2]. Some random web searches seem to indicate
that it has to go through multiple layers of compatibility code,
involving acquiring a global lock of some kind.
The same MSDN page points to the suggested replacement function,
GetDIBits [3].
Please find attached a patch to modify readscreen to use the newer
GetDIBits function. On our problem machine, this decreases the time
taken in readscreen() to 94ms. The majority of the code in the patch
comes from a MSDN example on device contexts [4].
To verify that the new code functions identically, we modified the
original code and printed out the hex of the hashed data. For each
chunk of framebuffer, the hash is
1adc95bebe9eea8c112d40cd4ab7a8d75c4f961, in both the sets of code.
Of special note is that this code runs in the context of the anonymous
IIS user, which is unlikely to have a useful screen. One might wonder
how often this happens. Presumably, user-mode software can actually
access the screen, but server-type software will not have a screen.
Please let me know if we can provide further data or help. Any
comments, insight, or suggestions on the patch are appreciated.
Thanks!
[1] The timing information was provided by the Windows function
GetSystemTimeAsFileTime.
[2] http://msdn.microsoft.com/en-us/library/dd144850(VS.85).aspx
[3] http://msdn.microsoft.com/en-us/library/dd144879(v=VS.85).aspx
[4] http://msdn.microsoft.com/en-us/library/dd183402(v=VS.85).aspx
Jake Goulding | Software Engineer
gould...@vivisimo.com | Connect: www.vivisimo.com
Vivisimo - Information Optimized
- Brian Makin ma...@vivisimo.com wrote:
This is Windows 2003, 64 bit, and it's definitely in RAND_screen.
I'm trying to move things to 1.0.0a now.commit 3e66cd55c48596fb42da9c98635a347a5159eec2
Author: Jake Goulding gould...@vivisimo.com
Date: Fri Jul 2 14:42:32 2010 -0400
Update Windows function that gets the bits of the screen
diff --git a/source/openssl-0.9.8l/crypto/rand/rand_win.c b/source/openssl-0.9.8l/crypto/rand/rand_win.c
index 00dbe42..11394af 100644
--- a/source/openssl-0.9.8l/crypto/rand/rand_win.c
+++ b/source/openssl-0.9.8l/crypto/rand/rand_win.c
@@ -690,9 +690,7 @@ static void readscreen(void)
{
#if !defined(OPENSSL_SYS_WINCE) !defined(OPENSSL_SYS_WIN32_CYGWIN)
HDC hScrDC; /* screen DC */
- HDC hMemDC; /* memory DC */
HBITMAP hBitmap; /* handle for our bitmap */
- HBITMAP hOldBitmap; /* handle for previous bitmap */
BITMAP bm; /* bitmap properties */
unsigned int size; /* size of bitmap */
char *bmbits; /* contents of bitmap */
@@ -700,13 +698,13 @@ static void readscreen(void)
int h; /* screen height */
int y; /* y-coordinate of screen lines to grab */
int n = 16; /* number of screen lines to grab at a time */
+ BITMAPINFOHEADER bi; /* info about the bitmap */
if (GetVersion() = 0x8000 || !OPENSSL_isservice())
return;
- /* Create a screen DC and a memory DC compatible to screen DC */
- hScrDC = CreateDC(TEXT(DISPLAY), NULL, NULL, NULL);
- hMemDC = CreateCompatibleDC(hScrDC);
+ /* Get a reference to the screen DC */
+ hScrDC = GetDC(NULL);
/* Get screen resolution */
w = GetDeviceCaps(hScrDC, HORZRES);
@@ -715,13 +713,22 @@ static void readscreen(void)
/* Create a bitmap compatible with the screen DC */
hBitmap = CreateCompatibleBitmap(hScrDC, w, n);
- /* Select new bitmap into memory DC */
- hOldBitmap = SelectObject(hMemDC, hBitmap);
-
/* Get bitmap properties */
GetObject(hBitmap, sizeof(BITMAP), (LPSTR)bm);
size = (unsigned int)bm.bmWidthBytes * bm.bmHeight * bm.bmPlanes;
+ bi.biSize = sizeof(BITMAPINFOHEADER);
+ bi.biWidth = bm.bmWidth;
+ bi.biHeight = bm.bmHeight;
+ bi.biPlanes = bm.bmPlanes;
+ bi.biBitCount = bm.bmBitsPixel;
+ bi.biCompression = BI_RGB;
+ bi.biSizeImage = 0;
+ bi.biXPelsPerMeter = 0;
+ bi.biYPelsPerMeter = 0;
+ bi.biClrUsed = 0;
+ bi.biClrImportant = 0;
+
bmbits = OPENSSL_malloc(size);
if (bmbits) {
/* Now go through the whole screen, repeatedly grabbing n lines */
@@ -729,11 +736,9 @@ static void readscreen(void)
{
unsigned char md[MD_DIGEST_LENGTH];
- /* Bitblt screen DC to memory DC */
- BitBlt(hMemDC, 0, 0, w, n, hScrDC, 0, y, SRCCOPY);
-
- /* Copy bitmap bits from memory DC to bmbits */
- GetBitmapBits(hBitmap, size, bmbits);
+ /* Copy the bits of the
Re: Slow crypto initialization.
On Wed, Jun 30, 2010 at 9:12 PM, Brian Makin ma...@vivisimo.com wrote: Thank you... this is mostly what I expected. In our case we having a problem with a CGI program so the response time is important and initialization happens many times. We may just have to hope no other boxes display this behavior :) I hadn't thought about the Win7 screen issue mentioned by Dr. Henson as you said you had several machines (of, and I assume this, similar make, OS wise) and only one playing up, which is a symptom I have learned to associate with the Rand_poll() heap walking issue. Which doesn't say I'm right, so checking makes sure here. Since, in your case, the timeout cost is significant (as it's happening in a CGI app), it's worth checking out which is it on your box. I'd be interested to hear whether it's the heapwalk loop or the (IIRC) read_screen() itself causing the delay. (I bet on the former as Win7 ~~ Server2008 in this and you mentioned you're running on 2003) [OT here] just a thought but since you're init-ing and exit-ing OPenSSL repeatedly due to starting and exiting the CGI exe, you may consider 'improving your random pool over time' by adding code in the CGI to dump the random pool to file (open for write and exclusive access, just shrug and don't write at all when the OS says another instance is already /writing/, this isn't about keeping everything, best effort is what we're after) at the end of the CGI run, while RAND_add()ing the file content at CGI start. Note that I say RAND_add() so this loading some 'unknown' amount of previously gathered entropy from a file doesn't replace the 'regular' entropy gathering that happens which each start! The thought here is that you can alleviate any suspected reduction in entropy gathering 'quality' - as sources are removed from the gathering - by accumulating the gathered entropy over an extended time, surpassing the CGI run-time lifetime boundaries by 'persisting' entropy gathered so far. The whole file I/O thing is best effort based so for multiple CGI instances running in parallel only one gets to 'win' and the collection in the other instances are 'lost', but that's okay, in a way, as we're considering longer term here, where a CGI instance I(t+n) now gets to have a /chance/ at obtaining more entropy than it would on its own, thanks to the successful persisting action by previous instance I(t) (instance 'I' at time 't'). [An alternative to classic fopen/fwrite/fclose might be memory mapped I/O which shared write access; no interprocess locking needed as we don't care who gets to write his stuff in there, just as long as it's happening fast and we don't run the risk of a completely zeroed file content or some such nastiness.] It's not ideal, but it at least helps cover your tracks when you cut out the offending source in OpenSSL itself. -- Met vriendelijke groeten / Best regards, Ger Hobbelt -- web:http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 --
Re: Slow crypto initialization.
Ger Hobbelt wrote: a symptom I have learned to associate with the Rand_poll() heap walking issue. AFAIR some time ago there was a problem that *just the first call* to the heap walking function would, under 64 bits Windows, take second in some circumstances. That's clearly a bug, and only Microsoft can do something about it. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Slow crypto initialization.
I am seeing a very slow initialization on a single Windows 2003 box with openssl-0.9.8l. During initialization the function RAND_screen gets called. This effectively hashes the frame buffer to generate entropy. In our case we are running as an IIS user and I'm not even sure what screen it's getting. This function takes on the order of 3 seconds. We have other identical boxes which are behaving correctly and a single box which is very slow. Two questions. 1. It appears that this is deprecated so would it be reasonable to simply remove it? 2. Does anyone have any idea why this function is misbehaving? -- BRIAN MAKIN Senior Software Engineer ma...@vivisimo.com Vivisimo [Search Done Right™] 1710 Murray Avenue Pittsburgh, PA 15217 USA tel: +1.412.422.2499 vivisimo.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Slow crypto initialization.
:-( I hope I recall correctly that what I mention next is indeed stuff happening in RAND_screen()... IIRC RAND_screen() isn't 'only' reading the screen but also doing a system-level heap traversal and a few other things and it was exactly that system-level heap traversal that slowed a few spurious Win boxes down to a snail's pace, so my take is it doing that to yours too. Has featured a few times here; there's a a known but quite unpredictable issue in the Windows specific heap walking code in there (I'd have to check the code to see again which calls it were, exactly); there's been a patch to at least limit the scan to an upper bound in time and as with anything entropy related, there's always the question 'is it really random?' or better: 'is it good enough random?' The technical (software) part of the issue is that the problem occurs only on some machines and is quite unpredictable in where it might pop up and when; since OpenSSL accesses some Win-internal structures there, which have been documented to some degree, the problem is 'known' in that we know it can happen, and a few fixes have been added to the code to at least limit the bother to an upper bound, but the issue of 'slow' isn't exactly /fixable/: turns out the machine is spending all that time inside the Windows OS itself and OpenSSL has no control over that, once it's called that one Win API. Some boxes just take ages in there for unknown reasons. Depending on what your servers do, the 'making certain' move re entropy is to connect a hardware entropy source to the box, but that's probably off-topic here (unless it's an IIS webserver working in a military/banking setting). Anyway, removing [semi-]entropy sources /is/ an option, but it's dangerous as removing them one by one in the end delivers zero entropy and we've to thank a Debian fellow for [accidentally, but /quite/ noticably] showing everyone what happens when you like cleaning up so much you lose a suddenly-after-the-fact significant chunk of entropy gathering while your streetcred is in the can, permanently. Personally, I wouldn't even bother about those 3 secs and let it do what it wants doing, as they [the 3 secs] only happen at library /init/ time, i.e. server [re]start. Of course, there'll be plenty who say 'just remove the code', but it gets quite inconclusive if you only count the 'votes' from security/cryptography knowledgable folks. And, no, that heap walk in RAND_screen() isn't a big source of entropy, probably small, rather, but you grab what you can, when you don't go the hardware entropy source route: you have to realize that you're 'faking' the whole entropy thing right there, all the way, so the game isn't about entropy-as-is but about making it bloody dang hard for any hacker to predict what your 'random' pool looks like at time t. There are no hard and fast answers to the question 'when have I done enough gathering?' And RAND_Screen() does add several chunks of unpredictability to that game. Now how many bits of /entropy/ it's delivering, I won't (and can't) say (OpenSSL takes a guess, but that's all); it's checking several sources and eliminating sources [one at a time] because they bother you is a plenty dangerous game if you don't /exactly/ know what you're doing. Hence my basic answer: 'let it be'; maybe not what you'd like to hear, but it saves losts of $$$ in discussion / security review / calamities down the line. [For the monetarily inclined, this subject has been discussed a lot in the ML before and when you count those emails @ some hourly rate and see what the result (or rather: the amount of change) is, then calc that cost sum and compare with X times a slower restart of N servers and the $-quantified cost, material and immaterial, of that... yeah. Let it be.] And when you go about 'removing it' anyway, be very very careful WHAT you remove, because I don't think it's the screen sampling that'll turn out to eat the cycles on that one box of yours but the heap traversal sys calls which are part of RAND_poll()/RAND_screen() and they are only a part of the whole RAND_whatever entropy collecting thing. Bottom line: commenting out the call(s) to RAND_screen() would quite definitely turn you out as 'the IIS guy who's related to that Debian guy y'all heard about before' several months down the line. A slightly 'smarter' removal would take out that heap walk loop if it /really/ hurts, but remember... Cave canem! (And this one has a /serious/ bite to it!) On Wed, Jun 30, 2010 at 4:11 PM, Brian Makin ma...@vivisimo.com wrote: I am seeing a very slow initialization on a single Windows 2003 box with openssl-0.9.8l. During initialization the function RAND_screen gets called. This effectively hashes the frame buffer to generate entropy. In our case we are running as an IIS user and I'm not even sure what screen it's getting. This function takes on the order of 3 seconds. We have other identical boxes which are behaving correctly and a single
Re: Slow crypto initialization.
On Wed, Jun 30, 2010, Ger Hobbelt wrote: :-( I hope I recall correctly that what I mention next is indeed stuff happening in RAND_screen()... IIRC RAND_screen() isn't 'only' reading the screen but also doing a system-level heap traversal and a few other things and it was exactly that system-level heap traversal that slowed a few spurious Win boxes down to a snail's pace, so my take is it doing that to yours too. Just a correction. RAND_screen() doesn't perform those other activities such as heap walking, those happen during the automatic entropy gather on Windows. There are known issues with Windows 7 and some 64 bit versions of Windows two. I asked about this and the actual bug is the previous quick behaviour. The functions apparently need to do a lot of time consuming things which previous versions of windows didn't handle correctly. I'd first suggest trying a newer version of OpenSSL such as 0.9.8o which does include some timing code that halts heap walking if it is taking too long. It isn't the only source of entropy, there are several others including the CryptoAPI PRNG. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Slow crypto initialization.
On Wed, Jun 30, 2010, Dr. Stephen Henson wrote: On Wed, Jun 30, 2010, Ger Hobbelt wrote: :-( I hope I recall correctly that what I mention next is indeed stuff happening in RAND_screen()... IIRC RAND_screen() isn't 'only' reading the screen but also doing a system-level heap traversal and a few other things and it was exactly that system-level heap traversal that slowed a few spurious Win boxes down to a snail's pace, so my take is it doing that to yours too. Just a correction. RAND_screen() doesn't perform those other activities such as heap walking, those happen during the automatic entropy gather on Windows. There are known issues with Windows 7 and some 64 bit versions of Windows two. Ooops, I should check the code before making statements like that... bugger. RAND_screen() used to just add the screen. It now also does the auto PRNG seeding via RAND_poll() as well, though that also happens automatically too. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Slow crypto initialization.
Thank you... this is mostly what I expected. In our case we having a problem with a CGI program so the response time is important and initialization happens many times. We may just have to hope no other boxes display this behavior :) On Wed, 2010-06-30 at 19:19 +0200, Ger Hobbelt wrote: :-( I hope I recall correctly that what I mention next is indeed stuff happening in RAND_screen()... IIRC RAND_screen() isn't 'only' reading the screen but also doing a system-level heap traversal and a few other things and it was exactly that system-level heap traversal that slowed a few spurious Win boxes down to a snail's pace, so my take is it doing that to yours too. Has featured a few times here; there's a a known but quite unpredictable issue in the Windows specific heap walking code in there (I'd have to check the code to see again which calls it were, exactly); there's been a patch to at least limit the scan to an upper bound in time and as with anything entropy related, there's always the question 'is it really random?' or better: 'is it good enough random?' The technical (software) part of the issue is that the problem occurs only on some machines and is quite unpredictable in where it might pop up and when; since OpenSSL accesses some Win-internal structures there, which have been documented to some degree, the problem is 'known' in that we know it can happen, and a few fixes have been added to the code to at least limit the bother to an upper bound, but the issue of 'slow' isn't exactly /fixable/: turns out the machine is spending all that time inside the Windows OS itself and OpenSSL has no control over that, once it's called that one Win API. Some boxes just take ages in there for unknown reasons. Depending on what your servers do, the 'making certain' move re entropy is to connect a hardware entropy source to the box, but that's probably off-topic here (unless it's an IIS webserver working in a military/banking setting). Anyway, removing [semi-]entropy sources /is/ an option, but it's dangerous as removing them one by one in the end delivers zero entropy and we've to thank a Debian fellow for [accidentally, but /quite/ noticably] showing everyone what happens when you like cleaning up so much you lose a suddenly-after-the-fact significant chunk of entropy gathering while your streetcred is in the can, permanently. Personally, I wouldn't even bother about those 3 secs and let it do what it wants doing, as they [the 3 secs] only happen at library /init/ time, i.e. server [re]start. Of course, there'll be plenty who say 'just remove the code', but it gets quite inconclusive if you only count the 'votes' from security/cryptography knowledgable folks. And, no, that heap walk in RAND_screen() isn't a big source of entropy, probably small, rather, but you grab what you can, when you don't go the hardware entropy source route: you have to realize that you're 'faking' the whole entropy thing right there, all the way, so the game isn't about entropy-as-is but about making it bloody dang hard for any hacker to predict what your 'random' pool looks like at time t. There are no hard and fast answers to the question 'when have I done enough gathering?' And RAND_Screen() does add several chunks of unpredictability to that game. Now how many bits of /entropy/ it's delivering, I won't (and can't) say (OpenSSL takes a guess, but that's all); it's checking several sources and eliminating sources [one at a time] because they bother you is a plenty dangerous game if you don't /exactly/ know what you're doing. Hence my basic answer: 'let it be'; maybe not what you'd like to hear, but it saves losts of $$$ in discussion / security review / calamities down the line. [For the monetarily inclined, this subject has been discussed a lot in the ML before and when you count those emails @ some hourly rate and see what the result (or rather: the amount of change) is, then calc that cost sum and compare with X times a slower restart of N servers and the $-quantified cost, material and immaterial, of that... yeah. Let it be.] And when you go about 'removing it' anyway, be very very careful WHAT you remove, because I don't think it's the screen sampling that'll turn out to eat the cycles on that one box of yours but the heap traversal sys calls which are part of RAND_poll()/RAND_screen() and they are only a part of the whole RAND_whatever entropy collecting thing. Bottom line: commenting out the call(s) to RAND_screen() would quite definitely turn you out as 'the IIS guy who's related to that Debian guy y'all heard about before' several months down the line. A slightly 'smarter' removal would take out that heap walk loop if it /really/ hurts, but remember... Cave canem! (And this one has a /serious/ bite to it!) On Wed, Jun 30, 2010 at 4:11 PM, Brian Makin ma...@vivisimo.com wrote: I am seeing a very slow initialization on a single
Re: Slow crypto initialization.
This is Windows 2003, 64 bit, and it's definitely in RAND_screen. I'm trying to move things to 1.0.0a now. On Wed, 2010-06-30 at 20:47 +0200, Dr. Stephen Henson wrote: On Wed, Jun 30, 2010, Ger Hobbelt wrote: :-( I hope I recall correctly that what I mention next is indeed stuff happening in RAND_screen()... IIRC RAND_screen() isn't 'only' reading the screen but also doing a system-level heap traversal and a few other things and it was exactly that system-level heap traversal that slowed a few spurious Win boxes down to a snail's pace, so my take is it doing that to yours too. Just a correction. RAND_screen() doesn't perform those other activities such as heap walking, those happen during the automatic entropy gather on Windows. There are known issues with Windows 7 and some 64 bit versions of Windows two. I asked about this and the actual bug is the previous quick behaviour. The functions apparently need to do a lot of time consuming things which previous versions of windows didn't handle correctly. I'd first suggest trying a newer version of OpenSSL such as 0.9.8o which does include some timing code that halts heap walking if it is taking too long. It isn't the only source of entropy, there are several others including the CryptoAPI PRNG. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
