On Fri, Nov 13, 2009 at 6:34 PM, James Baker <j...@j-baker.org> wrote: [...] > Each and every call takes the same long amount of time. To me, this > indicates that the time spent is not actually spent *finding* the next > heap entry (as if we were traversing a linked list to get to our > destination), but in allocating (to the nearest 2^N) space for and/or > recording info about every heap entry in every heap list.
.............[censored] eh... Gosh! The only 'close to reasonable' cause for this I can come up with is someone leaving some 'scan all to verify everything on each invocation' diag code in there. May it's doing a full snapshot every time. Whatever. So, yes, cutting short the heaplist scan based on timing results obtained over one or a few API calls is the way to go IMO; yes, when your machine had been heaplist-treated like that, it effectively cuts out 99.9% of the (semi-)entropy that might have been waiting for us in the heaplist, so that's not very nice. I know the whole entropy gathering business there comes with some handwaving anyway as nothing is 'hard' - after all, all the 'entropy' gathered in the scan can be theorized to be deterministic in some /very/ complex way (if one assumes no external influences like humans and such touch the machine up to than, knowing all the context and innards, etc.etc.), but it's all about making it bloody hard for attackers to make it close to deterministic within the confines of a reasonable amount of effort spent. So every source of possible (semi)entropy counts. Hence there's never going to be hard numbers on 'minimum effective amount' of gathering effort or other detail of the scanning/gathering process -- unless someone includes provable random hardware sources with standard motherboards some day; maybe an on-board QRBG121, say. ;-) So my remark about please not stripping out gathering code sections should be read in that light: when a code section /can/ cause trouble for someone, it should not be discarded for /everybody/. That's the best we can do for now. Yep, it doesn't make the handwaving any less, but at least the impact is minimized to fringe cases (if I may call this huge-number heaplist thing a 'fringe case' ?). There /is/ another possible source of entropy available nowadays, at least for a lot of folks: with the existance of on-board analog audio and ubiquitous DirectSound support (which goes for Windows 7 as well) it would be a nice thing to take a few seconds of direct line and mic channel 'sound' and turn that into a few hashes to feed to the randomness collector. Input and mic lines can be 'noisy' due to noise in the open analog circuits and A/D when the volumes are not moved down to 0%: one can see this happen when recording mic line sound without a mic attached in sound editors like Adobe Audition: the VU bars show the very tiny line noise in the sampled signal and when you amplify such a sample (say, 'normalize' track), the actual analog hardware noise is clearly visible. It's not perfect white noise, but at least it's grey or pink and it's got entropy, yes sir. MIC line is favourable in this regard as it's 'signal-to-noise' ratio is less than for 'line', almost everywhere, mostly due to higher amplification ratios in the analog section there, to ensure the tiny microphone signal makes it through the A/D quantization with the least amount of quality loss. Wherever a sound engineer would curse the noise (analog and A/.D quantization ~), we want to be in on the show. Of course, there's squibles like the gatherer then temporarily 'occupying' the DirectSound I/O which other apps may not like all that much, so it's not a thing that's way easy in that context regard, but it'd be a nice addition to the gatherer. Hm, when there's some time available, I should have a look at that. Unless someone likes to beat me to it, that is. ;-)) (Note to self: see how we can grab DirectSound channels with 'share device with other applications' enabled, like some of the sound apps can do out there. Second note: traverse DirectSound devices and grab from each for extra noise yumminess.) (Note: the same trick applies to sampled analog video, but there's fewer folks with analog video-in, and analog video is becoming a bit of a rare species itself with video broadcasts becoming digital end-to-end nowadays. <sigh> ;-) ) > If we limited the inner loop to 1 second as we do the outer loop, we'd > effectively be cutting out (in this case) 79 of the usual 80 bytes of > entropy which, as you say, makes one trepidatious. > > RAND_poll appears to gather randomly varying amounts of entropy, > basically "what it can grab in a few seconds". Is there a minimum > effective amount of entropy that is known? The ideal thing is to add > another source of entropy to compensate, but that's not something > that's within my capabilities or time limits right now. For both parts, see above. (What's bad for one should not disappear for everyone + analog audio noise) -- 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 -------------------------------------------------- ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
