Re: The perils of security tools

2008-06-03 Thread Philipp Gühring
Hi, It is not an implementaion issue but a requirement of the C standard. To avoid buffering use setvbuf (fp, NULL, _IONBF, 0); right after the fopen. Ah! Thanks a lot! Ok, I think that should be written into the man-pages of /dev/random and fgetc/fread and other related howtos. Best

Re: The perils of security tools

2008-05-31 Thread Nate Lawson
On Sun, May 18, 2008 at 4:55 PM, Hal Finney [EMAIL PROTECTED] wrote: A simple trick can be used to help immunize DSA signatures against these kinds of failures. I first learned of this idea many years ago from Phil Zimmermann, and a varient has been used for a long time in PGP and probably

Re: The perils of security tools

2008-05-30 Thread Werner Koch
On Wed, 28 May 2008 10:34, [EMAIL PROTECTED] said: Yes. Still, some people are using fopen/fread to access /dev/random, which does pre-fetching on most implementations I saw, so using open/read is preferred for using /dev/random. It is not an implementaion issue but a requirement of the C

Re: The perils of security tools

2008-05-28 Thread Philipp Gühring
Hi, (it doesn't just slow down a lot). Since /dev/random use depletes the pool directly, it is imperative that wasteful reads of this pseudo-device be avoided at all costs. Yes. Still, some people are using fopen/fread to access /dev/random, which does pre-fetching on most implementations I

Re: The perils of security tools

2008-05-28 Thread The Fungi
On Wed, May 28, 2008 at 10:34:53AM +0200, Philipp Gühring wrote: it is imperative that wasteful reads of this pseudo-device be avoided at all costs. Yes. Still, some people are using fopen/fread to access /dev/random, which does pre-fetching on most implementations I saw, so using

Re: The perils of security tools

2008-05-27 Thread Taral
On 5/26/08, Simon Josefsson [EMAIL PROTECTED] wrote: For example, reading a lot of data from linux's /dev/urandom will deplete the entropy pool in the kernel, which effectively makes reads from /dev/random stall. The two devices uses the same entropy pool. That's a bug in the way the

Re: The perils of security tools

2008-05-27 Thread Bodo Moeller
On Sun, May 18, 2008 at 4:55 PM, Hal Finney [EMAIL PROTECTED] wrote: A simple trick can be used to help immunize DSA signatures against these kinds of failures. I first learned of this idea many years ago from Phil Zimmermann, and a varient has been used for a long time in PGP and probably

Re: The perils of security tools

2008-05-27 Thread Simon Josefsson
Taral [EMAIL PROTECTED] writes: On 5/26/08, Simon Josefsson [EMAIL PROTECTED] wrote: For example, reading a lot of data from linux's /dev/urandom will deplete the entropy pool in the kernel, which effectively makes reads from /dev/random stall. The two devices uses the same entropy pool.

Re: The perils of security tools

2008-05-27 Thread Chad Perrin
On Mon, May 26, 2008 at 11:22:18AM +0200, Simon Josefsson wrote: For example, reading a lot of data from linux's /dev/urandom will deplete the entropy pool in the kernel, which effectively makes reads from /dev/random stall. The two devices uses the same entropy pool. I believe a much

Re: The perils of security tools

2008-05-26 Thread Simon Josefsson
Ben Laurie [EMAIL PROTECTED] writes: Steven M. Bellovin wrote: On Sat, 24 May 2008 20:29:51 +0100 Ben Laurie [EMAIL PROTECTED] wrote: Of course, we have now persuaded even the most stubborn OS that randomness matters, and most of them make it available, so perhaps this concern is moot.

Re: The perils of security tools

2008-05-26 Thread IanG
Steven M. Bellovin wrote: On Sat, 24 May 2008 20:29:51 +0100 Ben Laurie [EMAIL PROTECTED] wrote: Of course, we have now persuaded even the most stubborn OS that randomness matters, and most of them make it available, so perhaps this concern is moot. Though I would be interested to know how

Re: The perils of security tools

2008-05-26 Thread zooko
On May 24, 2008, at 9:18 PM, Steven M. Bellovin wrote: I believe that all open source Unix-like systems have /dev/random and /dev/urandom; Solaris does as well. By the way, Solaris is an open source Unix-like system nowadays. ;-) Regards, Zooko

Re: The perils of security tools

2008-05-26 Thread Ivan Krstić
On May 25, 2008, at 6:02 AM, Ben Laurie wrote: I meant: how good are the PRNGs underneath them? Not a direct answer to your question, but somewhat relevant as context is Michal Zalewski's analysis of TCP/IP sequence number predictability across operating systems:

Re: The perils of security tools

2008-05-25 Thread Steven M. Bellovin
On Sat, 24 May 2008 20:29:51 +0100 Ben Laurie [EMAIL PROTECTED] wrote: Of course, we have now persuaded even the most stubborn OS that randomness matters, and most of them make it available, so perhaps this concern is moot. Though I would be interested to know how well they do it! I did

Re: The perils of security tools

2008-05-25 Thread Ben Laurie
Steven M. Bellovin wrote: On Sat, 24 May 2008 20:29:51 +0100 Ben Laurie [EMAIL PROTECTED] wrote: Of course, we have now persuaded even the most stubborn OS that randomness matters, and most of them make it available, so perhaps this concern is moot. Though I would be interested to know how

Re: The perils of security tools

2008-05-24 Thread Eric Young
#ifndef PURIFY MD_Update(m,buf,j); /* purify complains */ #endif I just re-checked, this code was from SSLeay, so it pre-dates OpenSSL taking over from me (about 10 years ago, after I was assimilated by RSA Security). So in some ways I'm the one at fault for not

Re: The perils of security tools

2008-05-24 Thread Ben Laurie
Eric Young wrote: #ifndef PURIFY MD_Update(m,buf,j); /* purify complains */ #endif I just re-checked, this code was from SSLeay, so it pre-dates OpenSSL taking over from me (about 10 years ago, after I was assimilated by RSA Security). So in some ways I'm the one at

Re: [ROS] The perils of security tools

2008-05-23 Thread Florian Weimer
* Peter Gutmann: Debian seem to be particularly bad for not reporting changes to maintainers, This shouldn't be the case. There's a clear policy that non-packaging changes (basically, anything beyond trivial build fixes and pathname changes for FHS compliance) should be submitted upstream.

Re: [ROS] The perils of security tools

2008-05-23 Thread Ben Laurie
Florian Weimer wrote: * Ben Laurie: I must confess that I said that because I did not have the energy to figure out the other routes to adding entropy, such as adding an int (e.g. a PID, which I'm told still makes it in there). The PID dependency is there because of the need for fork

Re: [ROS] The perils of security tools

2008-05-23 Thread Florian Weimer
* Ben Laurie: Jonathan S. Shapiro wrote: Ben: I'm idly curious. Was this exceptionally unusual case where use of uninitialized memory was valid properly commented in the code? It's mentioned in the manpage for a function that eventually calls the function that was (correctly) patched--through

Re: [ROS] The perils of security tools

2008-05-23 Thread Florian Weimer
* Ben Laurie: I must confess that I said that because I did not have the energy to figure out the other routes to adding entropy, such as adding an int (e.g. a PID, which I'm told still makes it in there). The PID dependency is there because of the need for fork support--obviously, the PRNG

Re: The perils of security tools

2008-05-22 Thread Paul Hoffman
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

Re: [ROS] The perils of security tools

2008-05-22 Thread Steven M. Bellovin
On Tue, 13 May 2008 12:10:16 -0400 Jonathan S. Shapiro [EMAIL PROTECTED] wrote: Ben's points are well taken, but there is one *small* piece of this where I have some sympathy for the Debian folks: What can we learn from this? Firstly, vendors should not be fixing problems (or, really,

Re: The perils of security tools

2008-05-22 Thread Victor Duchovni
On Tue, May 13, 2008 at 02:10:45PM +0100, Ben Laurie wrote: [Moderator's note: A quick reminder: please use ASCII except if you need Unicode to spell your name right. Microsoft's proprietary quote marks are not a standard and don't look right on non-Microsoft displays. I edited them out of

Re: [ROS] The perils of security tools

2008-05-22 Thread Ben Laurie
Steven M. Bellovin wrote: On Tue, 13 May 2008 14:10:45 +0100 Ben Laurie [EMAIL PROTECTED] wrote: Debian have a stunning example of how blindly fixing problems pointed out by security tools can be disastrous. I've blogged about it here: http://www.links.org/?p=327 Vendors Are Bad For Security

Re: [ROS] The perils of security tools

2008-05-22 Thread Steven M. Bellovin
On Tue, 13 May 2008 23:00:57 +0100 Ben Laurie [EMAIL PROTECTED] wrote: Steven M. Bellovin wrote: On Tue, 13 May 2008 14:10:45 +0100 Ben Laurie [EMAIL PROTECTED] wrote: Debian have a stunning example of how blindly fixing problems pointed out by security tools can be disastrous.

Re: [ROS] The perils of security tools

2008-05-22 Thread Ben Laurie
Steven M. Bellovin wrote: On Tue, 13 May 2008 23:00:57 +0100 Ben Laurie [EMAIL PROTECTED] wrote: Steven M. Bellovin wrote: On Tue, 13 May 2008 14:10:45 +0100 Ben Laurie [EMAIL PROTECTED] wrote: Debian have a stunning example of how blindly fixing problems pointed out by security tools can

Re: [ROS] The perils of security tools

2008-05-22 Thread Ben Laurie
Steven M. Bellovin wrote: On Tue, 13 May 2008 23:27:52 +0100 Ben Laurie [EMAIL PROTECTED] wrote: Ben: I haven't looked at the actual code in question -- are you saying that the *only* way to add more entropy is via this pool of uninitialized memory? No. That would be fantastically stupid.

Re: [ROS] The perils of security tools

2008-05-22 Thread Peter Gutmann
Ben Laurie [EMAIL PROTECTED] writes: I must confess that I said that because I did not have the energy to figure out the other routes to adding entropy, such as adding an int (e.g. a PID, which I'm told still makes it in there). So just to clarify, does the Debian patch only remove the ability

Re: [ROS] The perils of security tools

2008-05-22 Thread Ben Laurie
Peter Gutmann wrote: Ben Laurie [EMAIL PROTECTED] writes: I must confess that I said that because I did not have the energy to figure out the other routes to adding entropy, such as adding an int (e.g. a PID, which I'm told still makes it in there). So just to clarify, does the Debian patch

Re: The perils of security tools

2008-05-22 Thread Alexander Klimov
On Tue, 13 May 2008, Ben Laurie wrote: Had Debian done this in this case, we (the OpenSSL Team) would have fallen about laughing I think we all should not miss this ROTFL experience: Original code (see ssleay_rand_add)

Re: [ROS] The perils of security tools

2008-05-22 Thread Ben Laurie
Jonathan S. Shapiro wrote: Ben: I'm idly curious. Was this exceptionally unusual case where use of uninitialized memory was valid properly commented in the code? Well. Kinda. It didn't really explain why: i=fread(buf,1,n,in); if (i = 0) break;

Re: [ROS] The perils of security tools

2008-05-22 Thread Ben Laurie
Jonathan S. Shapiro wrote: On Wed, 2008-05-14 at 10:34 +0100, Ben Laurie wrote: Jonathan S. Shapiro wrote: Ben: I'm idly curious. Was this exceptionally unusual case where use of uninitialized memory was valid properly commented in the code? Well. Kinda. It didn't really explain why... Then

Re: The perils of security tools

2008-05-22 Thread Ben Laurie
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

Re: The perils of security tools

2008-05-22 Thread Paul Hoffman
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

Re: The perils of security tools

2008-05-22 Thread Ben Laurie
Paul Hoffman wrote: 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

Re: The perils of security tools

2008-05-22 Thread Hal Finney
Ben Laurie alerts us to the recent bug in Debian distributions of OpenSSL which caused the RNG to have almost no entropy. The distribution mistakenly commented out the call that added seeding and most other sources of entropy to the RNG state. This is requiring many keys to be re-issued. One of

Re: The perils of security tools

2008-05-22 Thread Paul Hoffman
More interesting threadage about the issue here: http://taint.org/2008/05/13/153959a.html, particularly in the comments. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending

Re: The perils of security tools

2008-05-22 Thread Alexander Klimov
On Thu, 15 May 2008, Paul Hoffman wrote: 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

The perils of security tools

2008-05-13 Thread Ben Laurie
[Moderator's note: A quick reminder: please use ASCII except if you need Unicode to spell your name right. Microsoft's proprietary quote marks are not a standard and don't look right on non-Microsoft displays. I edited them out of this by hand. --Perry] Debian have a stunning example of how