Pourquoi dd copie-t-il seulement 128 octets de / dev / random quand j'en demande plus?


10

J'essaie de comprendre la sortie de la ddcommande. j'ai essayé

dd if=/dev/zero of=/dev/null bs=512 count=1

et a obtenu (comme prévu):

 1+0 records in
 1+0 records out
 512 bytes (512 B) copied, 2e-05 seconds, 26 MB/s

Mais quand j'ai essayé

dd if=/dev/random of=/dev/null bs=512 count=1

j'ai eu

 0+1 records in
 0+1 records out
 128 bytes (128 B) copied, 0.00012 seconds, 1.1 MB/s

Pourquoi ne copie-t-il que 128 octets?


Voir superuser.com/questions/359599/… pour une discussion plus complète de / dev / random et urandom
BobT

Réponses:


8

Vous devez utiliser /dev/urandom, ou la source aléatoire de "déblocage".

/dev/randomutilise une sorte de pool d'entropie pour augmenter le caractère aléatoire de la source de bits. Cette méthode renvoie uniquement autant de bits / octets aléatoires que possible en fonction de l'état du pool d'entropie à ce moment-là, donc si un générateur de nombres aléatoires matériel est utilisé, cela peut parfois être une constante. Depuis la page de manuel Linux :

Le générateur conserve également une estimation du nombre de bits de bruit dans le pool d'entropie. À partir de ce pool d'entropie, des nombres aléatoires sont créés.

Le /dev/urandomfichier continue de réutiliser le pool interne tel quel pour générer un nombre aussi longtemps que vous en avez besoin. L'effet secondaire de ceci est: ne pas utiliser /dev/urandomà des fins cryptographiques , car il est moins aléatoire que les bits produits par /dev/random. Voir le lien de la page de manuel ci-dessus pour plus de détails.



3

Étant donné que la lecture /dev/randomne renvoie que la quantité d'octets disponibles, vous devez spécifier la taille de bloc 1 . Dans votre exemple, vous définissez la taille de bloc sur 512 qui échoue après la première lecture.

Par conséquent, les arguments corrects qui lisent exactement 512 octets sont les suivants:

dd if=/dev/random of=filename bs=1 count=512

Notez que la commande se bloquera jusqu'à ce qu'il y ait suffisamment d'entropie dans le système pour générer toutes les données. Voilà comment ça /dev/randommarche. Si vous ne voulez pas attendre et que vous allez bien avec moins d'entropie, utilisez /dev/urandomplutôt. Dans la grande majorité des cas, l'utilisation /dev/urandomest préférée.


+1 pour l'explication, mais il faut dire qu'avec un nombre d'octets aussi élevé que 512, l'utilisation /dev/randomdevient pratiquement inutilisable, car la commande peut prendre plusieurs minutes. De plus, même avec bs=512 count=1il semble que l'appel bloque toujours s'il n'y a pas d' octets du tout, n'est- ce pas ? Une alternative à la commutation bset aux countvaleurs est d'utiliser iflag=fullblock; à savoir bs=512 count=1 iflag=fullblock.
mklement0

À mon humble avis, cette réponse devrait être fusionnée avec celle de @ Breakthrough. (C'était la réponse à mon problème alors que Breakthrough ne l'était pas).
superbob
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.