linux-kernel - Re: Why does reading from /dev/urandom deplete entropy so much?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <475599D6.4030008@cosmosbay.com>
Date:	Tue, 04 Dec 2007 19:17:58 +0100
From:	Eric Dumazet <dada1@...mosbay.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Adrian Bunk <bunk@...nel.org>,
	Marc Haber <mh+linux-kernel@...schlus.de>,
	linux-kernel@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: Why does reading from /dev/urandom deplete entropy so much?

Alan Cox a écrit :
>> No matter what you consider as being better, changing a 12 years old and 
>> widely used userspace interface like /dev/urandom is simply not an 
>> option.
>>     
>
> Fixing it to be more efficient in its use of entropy and also fixing the
> fact its not actually a good random number source would be worth looking
> at however.
>   
Yes, since current behavior on network irq is very pessimistic.

If you have some trafic, (ie more than HZ/2  interrupts per second), 
then add_timer_randomness() feeds
 some entropy but gives no credit (calling credit_entropy_store() with 
nbits=0)

This is because we take into account only the jiffies difference, and 
not the get_cycles() that should give
 us more entropy on most plaforms.

In this patch, I suggest that we feed only one u32 word of entropy, 
combination of the previous distinct
words (with some of them being constant or so), so that the nbits 
estimation is less pessimistic, but also to
avoid injecting false entropy.

Signed-off-by: Eric Dumazet <dada1@...mosbay.com>



View attachment "random.patch" of type "text/plain" (1809 bytes)