[Linux] /dev/random entropy bijmaken

[rollebol]

Ik heb redelijk veel random data nodig op mijn headless servertje, en er is dus ook geen muis die entropy data maakt voor de /dev/random device. Er komt nog wel wat in af en toe maar dat gaat echt met enkele bytes per minuut, terwijl ik echt megabytes per seconde nodig heb. Ik kon met google niet echt vinden welke bronnen hij gebruikt, ik verwacht iets van context switches, of interrupts, of zo. Dus als iemand weet hoe ik die kan stimuleren is dat natuurlijk ook goed.

Als ik cat /proc/sys/kernel/random/entropy_avail doe dan zegt hij dus als ik de random device aan het leegtrekken ben de hele tijd 0, omdat hij niet genoeg bronnen voor entropy heeft.

Is er een manier om 'nep-random-data' aan te maken? Het hoeft niet eens zo heel erg random te zijn, het mag best een slechte random-bron zijn, als ik maar quasi-willekeurige bytes in een beetje rap tempo kan lezen.

[Ronald]

Er is een patch die randomness van de netwerk kaarten invoegt aan de entropie pool

http://www.tech9.net/rml/linux/

Probeer dat eens?

Ik heb er zelf geen ervaring mee, maar je wil het vast wel proberen

[rollebol]

Dat klinkt precies als wat ik zoek. Bedankt! Ik ga direct kijken. Nee, eerst even slapen.

Om dit topic voor de search nog nuttig te maken hierbij nog even de blurb van de link zelf. (Er staan nog meer nuttige dingen trouwens)

This patch lets the user configure whether interrupt timings from network devices contribute to the kernel entropy pool (/dev/random). Currently, block devices and some other drivers feed the pool, although very few network devices do. This patch makes a user configurable policy out of the issue: either allow or disallow them all. Some users are on a headless or diskless system that generates very little entropy -- this patch provides a needed source. Other users fear that entropy from an open network is a security problem -- this patch will then make sure no devices contribute to the pool. Note without this some network devices currently do feed the pool.

Een 3com 3c90x levert in de standaard 2.4.19 kernel niets aan de entropy pool.

[ Voor 0% gewijzigd door rollebol op 02-10-2002 00:32 . Reden: nog wat nuttige dingen toegevoegd ]

[deadinspace]

Ho!
Als je niet zo heel random data zoekt, dan moet je /dev/random niet gebruiken. /dev/random is namelijk inefficient en levert maar een hele beperkte hoeveelheid random waardes. Wel zijn de waardes uit /dev/random heel onvoorspelbaar random (bijna true random), wat heel belangrijk is voor het maken van passwords en encrypting salts enzo (en dat is ook waar /dev/random voor bedoeld is).

Als je ongeveer- of semi-random data nodig hebt, is /dev/urandom misschien een betere oplossing, maar nog verstandiger (om de kernel entropy pool niet teveel te pesten) is het waarschijnlijk om een C-proggeltje met rand() en srand() te schrijven.

[XTerm]

Wat je ook kan doen als je net wat meer random wil dan urandom heeft, is een megabyte uit urandom lezen, deze lekker hashen met een paar bytes uit random... (xor, wat optellen, delen etc...)

Verder vermoed ik deadinspace, dat gebruik maken van rand en srand net zo nefast is voor de entropy pool als data uit urandom lezen

[Verwijderd]

als het kwasie random moet zij?
zoek even wat wiskunde op.
met de sin functie en wat logaritmies enzo kun je best leuke random dingen maken.
die constant andere waardes uitspugen.

umm en dat dan scripten of een c progie in elkaar douwen.
(uptime is trouwens altijd een leuke random seed)

(weet niet 100% of dit is wat je nodig hebt, maar denk ik vermeld het maar even)

[odysseus]

Stratos: om van een sinus een random getal te maken moet je er wel een random getal instoppen . Die getallen zullen ergens vandaan moeten komen, uit /dev/(u)random om precies te zijn. Die pool raakt alleen vrij snel leeg als je weinig entropy genereert en veel entropy verbruikt. Je uptime lijkt me niet echt een goede bron voor entropy, aangezien deze nogal voorspelbaar oploopt. Gebruiken in combinatie met andere bronnen om zo een extra hoeveelheid te creeëren lijkt me geen probleem zolang het niet om erg belangrijke data gaat. In dat laatste geval is overigens ook de netwerk-oplossing niet aan te raden: theoretisch kan een attacker de netwerkactiviteit bekijken of zelfs beïnvloeden en zo je 'random' getallen een bepaalde draai geven, waardoor ze minder random zijn dan ze lijken. Dit probleem is overigens vooral theoretisch en alleen van toepassing als je bijna volledig op netwerk-entropy draait.

* odysseus vraagt zich af waar mensen megabytes per seconde aan random getallen voor nodig hebben...bij de toepassingen die ik verzin moet je toch al eens gaan kijken naar de randomizer-kaarten die bij banken en dergelijke gebruikt worden ...

[Verwijderd]

mwha hij zei qwasie random.
nou je uptime orgnieel verwerken met een sinus kan grapige dingen opleveren.
tis niet onvoorspelbaar random.
maar de getalen schieten wel van hot naar her.

dan denk ik b.v. aan SIN($uptime)*$uptime/SQRT(COS($uptime))=$qwasie_rand
geen flauw idee wat daar uit zou komen. maar het ziet er intresant uit, en daar gaat het om. (bij mij iig) (en vraag me niet welke taal die code is. das vast StratoS++ )

[deadinspace]

XTerm89D schreef op 02 oktober 2002 @ 13:44:
Verder vermoed ik deadinspace, dat gebruik maken van rand en srand net zo nefast is voor de entropy pool als data uit urandom lezen

Nope, beiden functions maken geen gebruik van de kernel entropy pool.

Met srand() stel je een random seed in, en met rand() krijg je dan een serie semi-random nummers, welke (op een niet logische of bijzonder voorspelbare manier) afhankelijk zijn van de random seed.
Maar rand() is gewoon een bepaalde functie op de random seed en het vorige getal dat rand() teruggaf. rand() gebruikt dus geen data uit de kernel entropy pool.
Dat heeft trouwens ook als gevolg dat rand() altijd dezelfde serie getallen voortbrengt als je srand( 1 ) doet.

Het beste kun je dus een getal uit /dev/urandom nemen, deze als random seed in srand() stoppen, en dan een stuk of 1,000,000 getallen uit rand() halen. Dan pak je weer een getal uit /dev/urandom, stopt het in srand(), en haalt de volgende 1,000,000 getallen uit rand().
Grote hoeveelheiden behoorlijk random getallen, met lage kernel entropy pool belasting.

Lees btw ook eens de urandom en srand() manpages.

[rollebol]

Bedankt voor jullie reacties allemaal. Ik zal het even kort toelichten, ik had gewoon eventjes snel een file nodig die niet goed te comprimeren was. Ik had inderdaad beter urandom kunnen gebruiken, dat doe ik de volgende keer.

Als ik het structureel nodig zou hebben dan zou ik inderdaad even een vlugge random-functie maken, maar het was incidenteel.

[PipoDeClown]

is het ook mogelijk om net als bij geluid een roze-ruis-random of witte-ruis-random te creeren? (waarin een reeks getallen meer voorkomt dan een andere reeks bijv.)

[rollebol]

Ik weet niet hoe je pink noise maakt, maar ik kwam wel net per ongeluk een goeie entropy-vuller tegen die de ruis op de microfoon/line in-ingang van je geluidskaart gebruikt als bron.

http://freshmeat.net/projects/audio-entropyd/?topic_id=44

Oh, over pink noise. Misschien heb je hier iets aan.

http://www.embedded.com/2000/0003/0003spectra.htm
http://www.firstpr.com.au/dsp/pink-noise/

[ Voor 0% gewijzigd door rollebol op 04-10-2002 18:44 . Reden: toch iets over roze ruis ]

[igmar]

rollebol schreef op 02 oktober 2002 @ 00:10:
Ik heb redelijk veel random data nodig op mijn headless servertje, en er is dus ook geen muis die entropy data maakt voor de /dev/random device.

Slecht idee, voor grote hoeveelheden semi-random data moet je /dev/urandom gebruiken.

Welke kernel draait dat systeem ? Bepaalde 2.4 kernels hebben een bug die verhinderd dat de entropy pool weer gevuld raakt.

[Thijsch]

code:

#include <stdio.h>

int main()
{
   int getal, x;
   srand(time(NULL));
   for(x=0;x<10;x++)
   {
      getal = rand();
      printf("%d\n",getal);
   }
}

opslaan als random.c en dan: gcc random.c -o random , starten met ./random

geeft:

code:

thijs@Thijs:~$ ./random
1308659822
1739485222
88533562
686892437
2147234694
1719754176
1011424689
511501905
1673204067
306369573

wil je een getal tussen de 0 en 10 bijvoorbeeld maakt je van getal = rand(); dit:
getal = 1+(int) (10.0*rand()/(RAND_MAX+1.0)); van 10.0 kan je ieder getal maken wat je wilt.

/edit: de for lus kan je weglaten natuurlijk, die is alleen om te laten zien dat de getallen verschillend zijn.

[rollebol]

igmar schreef op 04 oktober 2002 @ 19:19:
[...]
Slecht idee, voor grote hoeveelheden semi-random data moet je /dev/urandom gebruiken.

Welke kernel draait dat systeem ? Bepaalde 2.4 kernels hebben een bug die verhinderd dat de entropy pool weer gevuld raakt.

Het is natuurlijk ook een beetje slecht idee om te antwoorden op een openingsposting zonder te lezen of hetzelfde al 3 keer is gezegd, maar toch bedankt.

Het is kernel 2.4.19 en hij vult zichzelf weer (langzaam), dus dat is het probleem niet.