Pozorujete kombinaci zvláštního chování dd se zvláštním chováním linuxového /dev/random . Obojí je mimochodem jen zřídka tím správným nástrojem pro tuto práci.
Linux /dev/random vrací data střídmě. Vychází z předpokladu, že entropie v generátoru pseudonáhodných čísel velmi rychle uhasíná. Protože shromažďování nové entropie je pomalé, /dev/random obvykle se vzdává pouze několika bajtů najednou.
dd je starý, výstřední program původně určený k provozu na páskových zařízeních. Když mu řeknete, aby přečetl jeden blok o velikosti 1 kB, pokusí se přečíst jeden blok. Pokud čtení vrátí méně než 1024 bajtů, těžké, to je vše, co dostanete. Takže dd if=/dev/random bs=1K count=2 vytvoří dvě read(2) hovory. Protože se čte z /dev/random , dvě read volání obvykle vracejí pouze několik bajtů, v různém počtu v závislosti na dostupné entropii. Viz také Kdy je dd vhodné pro kopírování dat? (nebo, když jsou read() a write() částečné)
Pokud nenavrhujete instalační program nebo klonovač OS, nikdy byste neměli používat /dev/random pod Linuxem vždy /dev/urandom . urandom manuálová stránka je poněkud zavádějící; /dev/urandom je ve skutečnosti vhodný pro kryptografii, dokonce i pro generování klíčů s dlouhou životností. Jediné omezení s /dev/urandom je, že musí mít dostatečnou entropii; Linuxové distribuce obvykle šetří entropii mezi restarty, takže jediný případ, kdy možná nebudete mít dostatek entropie, je nová instalace. Entropie se prakticky nevytrácí. Další informace najdete v článku Je rand z /dev/urandom bezpečný pro přihlašovací klíč? and Feeding /dev/random entropy pool?.
Většina použití dd jsou lépe vyjádřeny nástroji jako head nebo tail . Pokud chcete 2 kB náhodných bytů, spusťte
head -c 2k </dev/urandom >rand
Se staršími linuxovými jádry byste si mohli vystačit s
dd if=/dev/urandom of=rand bs=1k count=2
protože /dev/urandom šťastně vrátil tolik bajtů, kolik bylo požadováno. Ale to už od jádra 3.16 neplatí, nyní je to omezeno na 32 MB.
Obecně, když potřebujete použít dd Chcete-li extrahovat pevný počet bajtů a jeho vstup nepochází z běžného souborového nebo blokového zařízení, musíte číst bajt po bajtu:dd bs=1 count=2048 .
Od man 4 random na krabici RHEL 5:
Při čtení zařízení /dev/random vrátí pouze náhodné bajty v rámci odhadovaného počtu bitů šumu ve fondu entropie.
Na tomto počítači dostávám soubory o velikosti 213 bajtů. Zpět k muži 4 náhodně:
Při čtení /dev/urandom zařízení vrátí tolik bajtů, kolik je požadováno.
Dostanu 2048 bajtů z každého vyvolání dd if=/dev/urandom of=rand bs=1K count=2
Došel jsem k závěru, že rozdíl je způsoben tím, kolik entropie váš počítač generuje mezi vyvoláním dd if=/dev/random ...
Proč dd vypustit data? ... Gilles položil tuto zajímavou otázku o dd :
Kdy je dd vhodné pro kopírování dat? (nebo, když jsou read() a write() částečné)
Zde je úryvek z této otázky:
*...není těžké dát na vinu dd; zkuste například tento kód:**
yes | dd of=out bs=1024k count=10
a zkontrolujte velikost výstupního souboru (pravděpodobně bude výrazně pod 10 MB).
Kromě mého komentáře (na konci vaší otázky) je zajímavé něco takového sledovat... Zachycuje vaše bajty v souboru $trnd . Pololibovolně jsem zvolil bs=8
Pohybujte myší a sledujte, jak se zrychluje.
Při nečinnosti počítače (AFK a žádná síťová aktivita) a po vyčerpání fondu entropie to trvalo 2 hodiny 12 minut nasbírat pouze 1192 bajtů, v tu chvíli jsem to zrušil.
Když jsem pak neustále pohyboval myší, trvalo to relativně mnohem kratší 1 minutu 15 sekund shromáždit stejný počet bajtů.
To docela jasně ukazuje, že shromažďování entropie není založeno na rychlosti CPU, ale spíše jde o náhodné události založené a že můj systém Ubuntu používá myš jako jednu ze svých významných náhodné faktory.
get=2048
trnd=/tmp/$USER.rnd; >"$trnd"
while (( $(wc -c <"$trnd") < $get )) ;do
dd if=/dev/random bs=8 count=1 2>/dev/null >>"$trnd"
echo -n "itt: $((i+=1)) ct: "; wc -c <"$trnd"
done
truncate -s $get "$trnd"
echo -e "\nfinal count: "; wc -c <"$trnd"