The perils of security tools

Paul Hoffman paul.hoffman at
Thu May 15 10:33:02 EDT 2008

At 10:25 AM +0100 5/15/08, Ben Laurie wrote:
>Paul Hoffman wrote:
>>I'm confused about two statements here:
>>At 2:10 PM +0100 5/13/08, Ben Laurie wrote:
>>>The result of this is that for the last two years (from Debian's 
>>>"Edgy" release until now), anyone doing pretty much any crypto on 
>>>Debian (and hence Ubuntu) has been using easily guessable keys. 
>>>This includes SSH keys, SSL keys and OpenVPN keys.
>>. . .
>>>[2] Valgrind tracks the use of uninitialised memory. Usually it is 
>>>bad to have any kind of dependency on uninitialised memory, but 
>>>OpenSSL happens to include a rare case when its OK, or even a good 
>>>idea: its randomness pool. Adding uninitialised memory to it can 
>>>do no harm and might do some good, which is why we do it. It does 
>>>cause irritating errors from some kinds of debugging tools, 
>>>though, including valgrind and Purify. For that reason, we do have 
>>>a flag (PURIFY) that removes the offending code. However, the 
>>>Debian maintainers, instead of tracking down the source of the 
>>>uninitialised memory instead chose to remove any possibility of 
>>>adding memory to the pool at all. Clearly they had not understood 
>>>the bug before fixing it.
>>The second bit makes it sound like the stuff that the Debian folks 
>>blindly removed was one, possibly-useful addition to the entropy 
>>pool. The first bit makes it sound like the stuff was absolutely 
>>critical to the entropy of produced keys. Which one is correct?
>They removed _all_ entropy addition to the pool, with the exception 
>of the PID, which is mixed in at a lower level.

I take it that these are not 128-bit, non-monotonic PIDs. :-)

The bigger picture is that distributions who are doing local mods 
should really have an ongoing conversation with the software's 
developers. Even if the developers don't want to talk to you, a 
one-way conversation of "we're doing this, we're doing that" could be 

--Paul Hoffman, Director
--VPN Consortium

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at

More information about the cryptography mailing list