| |||||||||||||
|
| |||||||||||||
A long test aheadA long test aheadPosted May 21, 2008 23:58 UTC (Wed) by man_ls (subscriber, #15091)In reply to: The tests don't need to do that by man_ls Parent article: Open Source Security Report Uh... I should have read to the end of the comments first, sorry for that. I see that below you mention the birthday attack, and then discard it because the only entropy comes from the process ID which will not repeat itself until it rolls around. So the PRNG is fed with sequential data, and is not random enough even to create a birthday collision. The time to generate the compromised keys is just a couple of hours -- on a 31-processor cluster. It makes sense that on my lowly AMD64@2.0 GHz it takes about 36 hours. I just checked that generating a few thousand keys does not provide a collision. I will let it run for a while until PID wraps, and then check if there are indeed collisions. But you are right that it is hardly a unit test that which might take longer than a day.
(Log in to post comments)
A long test ahead Posted May 22, 2008 6:08 UTC (Thu) by man_ls (subscriber, #15091) [Link] After running overnight, my little script is already generating duplicate keys as expected. (PID wrapped around some hours ago.) This with libssl0.9.8 version 0.9.8g-1.One wonders if such a verification would really be useful for a distro, or if it is indeed "fighting yesterday's battle".
|
|
||||||||||||