sslug-teknik team mailing list archive

[donald_j_axel <donax@xxxxxxxxxx>]

On Thu, 14 Jul 2005 13:59:38 +0200
Jacob wrote:

> donald_j_axel <donax@xxxxxxxxxx> writes:
> 
> > Man burde have en "yes" device og en random, som var i stand til
> > at levere data i passende mængder.
> 
> Hvad er der galt med /dev/urandom til at læse pseudotilfældige data?


Tak for det spørgsmål! Jeg er bange for et problem med at læse
mange data (giga-vis) fra den device, idet jeg synes at jeg har
været ude for at den stoppede, i overført forstand "løb tør for
randomity" -- men det var måske kun i "gamle dage" (for 3 år
siden) på kerne 2.0.39?

Nu bruger jeg lige 2 min. på at Google:-)

http://linux.about.com/library/cmd/blcmdl4_urandom.htm
When read, /dev/urandom device will return as many bytes as are
requested. As a result, if there is not sufficient entropy in the
entropy pool, the returned values are theoretically vulnerable to
a cryptographic attack on the algorithms used by the driver.
Knowledge of how to do this is not available in the current
non-classified literature, but it is theoretically possible that
such an attack may exist. If this is a concern in your
application, use /dev/random instead.  


Nå, der står ikke at den bliver langsom når den ikke har entropi
nok -- så det er da en første indikation.

Dernæst er jeg i tvivl om CPU overhead (belastning) er godt når
man skal stresse IO-systemet. Husk at denne tråd handler om at
stresse kernens IO interrupt system med en eller flere
dd-kommandoer, som skriver vildt mange (dumme) data til disk, og
at det med ikke bare at skrive nuller skyldes faren for specielle
hardware fejl (tror jeg nok).


Beklager den blev så lang denne posting:-)


Hilsen
-- 
donald_j_axel donax snabela get2net.dk -- http://d-axel.dk/