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 saw, so using open/read is 
preferred for using /dev/random.

Implementations can be rather easily checked with strace.

Best regards,
Philipp Gühring

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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 open/read is preferred for using /dev/random.
 
 Implementations can be rather easily checked with strace.

Oh, agreed wholeheartedly. I simply meant that *wasteful*
(gratuitous) reads of /dev/random should be avoided. Justifiable,
conservative reads of /dev/random are, of course, why it exists in
the first place!

And fopen/fread is definitely a bad idea in this case for the
reasons you point out. In general, anything which prefetches
potentially excess data in a read from /dev/random is destructive to
the entropy pool.
-- 
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]