Un moyen rapide de randomiser la HD?

J'ai lu comment sécuriser les disques durs pour le cryptage, et l'une des étapes consiste à écrire des bits aléatoires sur le lecteur, afin de rendre les données cryptées indiscernables du reste des données sur le disque dur.

Cependant, quand j'ai essayé d'utiliser dd if=/dev/urandom of=/dev/sdadans le passé, l'ETA cherchait à être de l'ordre des jours. J'ai vu quelque chose à propos de l'utilisation badblocksà la place de l'andandom, mais cela ne m'a pas beaucoup aidé. Je voudrais juste savoir s'il existe des moyens qui pourraient m'aider à accélérer cela, comme des options pour ddou autre chose qui pourrait me manquer, ou si la vitesse n'est qu'une limitation de la HD.

dd if=/dev/urandom of=/dev/sda, ou tout simplement cat /dev/urandom >/dev/sda , n'est pas le moyen le plus rapide de remplir un disque avec des données aléatoires. Linux /dev/urandomn'est pas le RNG cryptographique le plus rapide du marché. Existe-t-il une alternative à / dev / urandom? a quelques suggestions. En particulier, OpenSSL contient un PRNG cryptographique plus rapide:

openssl rand $(</proc/partitions awk '$4=="sda" {print $3*1024}') >/dev/sda

Notez qu'en fin de compte, qu'il y ait une amélioration ou non dépend de quelle partie est le goulot d'étranglement: le CPU ou le disque.

La bonne nouvelle est que le remplissage du disque avec des données aléatoires est pratiquement inutile. Tout d'abord, pour dissiper un mythe commun, essuyer avec des zéros est tout aussi bon sur le matériel d'aujourd'hui . Avec la technologie du disque dur des années 80, l'écrasement d'un disque dur avec des zéros a laissé une petite charge résiduelle qui pourrait être récupérée avec du matériel un peu cher; plusieurs passages d'écrasement avec des données aléatoires (le «chiffon de Gutmann») ont été nécessaires. Aujourd'hui, même une seule passe d'écrasement avec des zéros laisse des données qui ne peuvent pas être récupérées de manière réaliste même dans des conditions de laboratoire.

Lorsque vous chiffrez une partition, il n'est pas nécessaire de remplir le disque avec des données aléatoires pour la confidentialité des données chiffrées. Il n'est utile que si vous avez besoin de rendre l'espace utilisé par les données chiffrées indiscernable de l'espace inutilisé. La création d'un volume chiffré au-dessus d'un conteneur non aléatoire révèle quels blocs de disque ont déjà été utilisés par le volume chiffré. Cela donne une bonne indication de la taille maximale du système de fichiers (bien qu'avec le temps, cela deviendra une approximation de pire en pire), et un peu plus.

L'opensl ne semblait pas fonctionner pour moi. J'ai obtenu des «options inconnues» et d'autres problèmes avec les solutions fournies. J'ai donc fini par suivre le programme fio.

fio -name="fill" -ioengine=libaio -direct=1 -bs=512m -rw=write -iodepth=4 -size=100% -filename=/dev/md0

Ce qui semble prendre 3 heures pour faire 19 To sur 24 disques durs. Donc, environ 1800 Mo / s

smp-016:~ # fdisk -l /dev/md0
Disk /dev/md0: 18890.1 GB, 18890060464128 bytes

smp-016:~ # fio -name="fill" -ioengine=libaio -direct=1 -bs=512m -rw=write -iodepth=4 -size=100% -filename=/dev/md0
fill: (g=0): rw=write, bs=512M-512M/512M-512M/512M-512M, ioengine=libaio, iodepth=4
fio-2.2.10
Starting 1 process
Jobs: 1 (f=1): [W(1)] [2.7% done] [0KB/1536MB/0KB /s] [0/3/0 iops] [eta 03h:01m:11s]

J'espère que ce sont en fait des données aléatoires. La page de manuel indique fio "Par défaut: remplir les tampons avec des données aléatoires." http://linux.die.net/man/1/fio

Je ne le fais pas à des fins de sécurité / cryptage, j'essaie simplement de m'assurer que mes tests de lecture ultérieurs sont des données réelles et pas seulement des 0. Cette même commande fio peut être utilisée pour le préconditionnement SSD / NVMe. Comme l'utilisation de / dev / zero peut conduire à une compression au niveau du disque "tricher" combien est réellement écrit. Bien que j'ajouterais un -loops=2indicateur, s'il s'agit d'un nouveau SSD pour l'analyse comparative.

Si vous vouliez qu'il soit sécurisé, vous pourrez peut-être utiliser l' -randrepeat=bool option, car cela basculera "Amorcer le générateur de nombres aléatoires de manière prévisible afin que les résultats soient reproductibles d'une exécution à l'autre. Par défaut: vrai.", Mais je ne le suis toujours pas certain que ce serait sûr.

De plus, certains disques durs de classe entreprise sont équipés de disques SED (Self Encrypting Drives) et vous permettront de faire tourner la clé de cryptage pour effacer instantanément et en toute sécurité toutes les données écrites.

Enfin, j'ai utilisé dans le passé DBAN (alias Darik's Boot et Nuke), qui a des options de démarrage CD et USB et "est un projet open source hébergé sur SourceForge. Le programme est conçu pour effacer en toute sécurité un disque dur jusqu'à ce que ses données soient définitivement supprimé et non récupérable "

Vous pouvez demander à OpenSSL de chiffrer /dev/zeroavec un mot de passe aléatoire, ce qui donne des données pseudo-aléatoires décentes très rapidement (si votre CPU prend en charge l'accélération).

openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero | dd of=/dev/sda

Vous pouvez passer par là pvpour obtenir des progrès / ETA. Les commandes que j'exécute en ce moment (dans un shell root) sont:

DISK="sda"
DISKSIZE=$(</proc/partitions awk '$4=="'"$DISK"'" {print sprintf("%.0f",$3*1024)}')
apt-get install pv
openssl enc -aes-256-ctr -nosalt \
  -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" \
  < /dev/zero |
  pv --progress --eta --rate --bytes --size "$DISKSIZE" |
  dd of=/dev/"$DISK" bs=2M

J'ai eu cette idée de cette réponse , après avoir eu le même problème que John irrationnel , qui a commenté la réponse de Gilles ci-dessus. Cela a augmenté ma vitesse de nettoyage de ma nouvelle matrice RAID de 11 Mo / s à environ 300 Mo / s, ce qui prenait une semaine à 10 heures.

J'ajouterai que vous devriez pouvoir utiliser plutôt que la déclaration plus compliquée ci-dessus, mais il y a un bogue qui ne permettra de produire que 16 Mo de sortie. (Ce bug a été déposé, janvier 2016.)openssl rand #of_bytesopenssl enc ...ssl

Et, selon la réponse à cette question , et en continuant à supposer que le CPU est le goulot d'étranglement, il peut être possible d'augmenter encore la vitesse en exécutant plusieurs opensslprocessus parallèles sur des cœurs séparés, en les combinant à l'aide d'un FIFO.

Pour compléter la réponse de Marco, vous avez besoin d'un générateur de nombres aléatoires plus rapide.

Vous utilisez un programme simple qui fait écho à des nombres aléatoires d'une bonne bibliothèque boost::randomet utilisez celui-ci dans dd.

Si vous choisissez boost, vous pouvez utiliser cet exemple en modifiant la experimentfonction selon vos besoins.

Le goulot d'étranglement si ni la taille du bloc ni le disque dur, mais la lente génération de nombres pseudo-aléatoires. /dev/urandomest en magnitude plus rapide que /dev/randomcar il ne bloque pas sur un pool à faible entropie.

Vous pouvez le confirmer en mesurant la sortie brute de vos nombres pseudo-aléatoires:

pv /dev/urandom >/dev/null

Ce taux sera beaucoup plus lent que le taux d'écriture de votre disque dur. Une solution correcte dépend totalement de votre niveau de sécurité requis. Si vous avez besoin d'une haute sécurité, utilisez un générateur aléatoire matériel rapide ou acceptez la vitesse lente. Si vos besoins de sécurité ne sont pas si élevés, vous pouvez capturer quelques dizaines de Mio de données et écrire cette chaîne à plusieurs reprises sur le lecteur. Ou peut-être même que l'écriture de zéros /dev/zeroest une option.

Sommaire

/dev/random - sécurisé, très lent
/dev/urandom- moins sécurisé¹,
RNG matériel lent - sécurisé, rapide, très cher
( /dev/zero - pas aléatoire du tout, très rapide)

¹ _{Selon Un rand de / dev / urandom est-il sécurisé pour une clé de connexion? /dev/urandomest aussi sûr que /dev/random. Merci à Gilles de l'avoir signalé.}

J'essayais de remplir un disque dur USB externe de 4 To avec dd if=/dev/urandom of=/dev/sdX status=progressbeaucoup trop de lenteur (quels que soient les bs=paramètres), et il semble que cela opensslait un plafond sur la quantité de données aléatoires qu'il produira (au moins pour la version 1.0.2p). La meilleure option que j'ai trouvée était le commentaire de frostschutz à utiliser shred, comme dans:

shred -v -n 1 /dev/sdX

Assurez-vous d'utiliser le -n 1sinon il sera écrit par défaut sur l'appareil 3 fois (plus le -vqui montre la progression). Je ne pense pas que la qualité des nombres pseudo-aléatoires soit si élevée, mais il me suffit de préparer un disque dur portable de grande capacité pour le chiffrement.