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
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
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
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
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
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
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
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.
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
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.
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
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
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:
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
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
#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
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
* 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.
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
* 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
* 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
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,
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
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
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.
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
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.
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
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
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)
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;
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
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
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
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
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
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
[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
38 matches
Mail list logo