| |||||||||||||
|
| |||||||||||||
TestingTestingPosted May 21, 2008 13:47 UTC (Wed) by ajb44 (guest, #12133)In reply to: Testing by eru Parent article: Open Source Security Report
You're talking about different things. A random number generator is required to generate a random *sequence*. In this case, we only want to generate one number, and be sure that our procedure is choosing it from a large set. This bug reduced the size of the set to 2^24, IIRC. Because of the birthday paradox we could detect this in about 2^12 tests. This is not sufficient (because we want a much bigger set than 2^24) but it's probably worth doing.
(Log in to post comments)
Not really a unit test Posted May 21, 2008 14:18 UTC (Wed) by tialaramex (subscriber, #21167) [Link] The information I've seen suggested there were at about 2^31 possible initial values for the entropy pool because it was seeded from PID which is usually in the range of a few hundred to 32767 or so on Linux systems. In that case you'd have to run an OpenSSL key generator at least of the order of 100 000 times to get duplicate keys and reject the null hypothesis that the generator produces a random key each time. You must restart OpenSSL each time (most likely by doing this work in a separate process) in order to ensure that it isn't able to keep the entropy pool between keys, since if it does that you will just be testing the PRNG which we already know is strong. A unit test which produces 100 000 distinct keys using OpenSSL would be a real pain. On systems with no dedicated entropy generating hardware it'd almost surely empty the entropy pool, so this "Unit test" suddenly requires either dedicated hardware or a human to go shake things up, otherwise it will hang for long periods waiting for more entropy. This is sounding less and less like a unit test and more and more like an exercise which would be useful in a formal review of the system's security, of the sort which OpenSSL but not Debian has passed previously...
Not really a unit test Posted May 21, 2008 14:36 UTC (Wed) by tialaramex (subscriber, #21167) [Link] Huh, ignore the above particulars since (as any school boy should know), 32767 is a long way short of 2^31 However unfortunately the birthday paradox actually doesn't help you in this case because the "random" factor isn't - you will likely run your unit test on a single machine where PID (the main source of "entropy" left after the disastrous Debian patch) is happily incrementing slowly for each key generator process you run, so you won't get a collision until your PID actually wraps.
Not really a unit test Posted May 22, 2008 3:12 UTC (Thu) by bvdm (guest, #42755) [Link] This bug literally had a global impact. The principle at stake is whether enough control mechanisms exist at present to eliminate future problems. It is well worth considering. Individuals compiling OpenSSL and other FOSS cryptographic packages may choose not to run tests that requires days of processing, but distributions that make modifications are obligated to do so in my opinion.
|
|
||||||||||||