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
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
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)
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
24 matches
Mail list logo
