Existe-t-il une alternative à / dev / urandom?

Existe-t-il un moyen plus rapide que / dev / [u] random? Parfois, je dois faire des choses comme

cat / dev / urandom> / dev / sdb

Les appareils aléatoires sont "trop" sécurisés et malheureusement trop lents pour cela. Je sais qu'il existe wipedes outils similaires pour la suppression sécurisée, mais je suppose qu'il existe également des moyens intégrés à cela sous Linux.

Si vous cherchez à faire un effacement "sécurisé" d'un disque dur (ou d'un fichier), vous devriez regarder l'utilitaire shred.

Comme le soulignent les affiches précédentes, les dispositifs aléatoires / dev / * sont destinés à être utilisés comme source de petits morceaux de données aléatoires.

Malheureusement, Linux a une mauvaise implémentation d'urandom. Vous pouvez utiliser aes256-ctr avec une clé aléatoire et obtenir plusieurs centaines de mégaoctets de pseudo-aléatoire par seconde, si votre CPU prend en charge AES-NI (accélération matérielle). Je suis impatient de passer également à une approche moderne.

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

Ce chiot fait 1,0 Go / s sur ma boîte (contre 14 Mo / s de / dev / urandom). Il utilise urandom uniquement pour créer un mot de passe aléatoire, puis effectue un cryptage très rapide de / dev / zero à l'aide de cette clé. Cela devrait être un PRNG cryptographiquement sécurisé mais je ne ferai aucune garantie.

Dans un test rapide sous Ubuntu 8.04 sur un Thinkpad T60p avec processeur T2500, 1 Go de données aléatoires openssl randétait 3-4 fois plus rapide que /dev/urandom. C'est,

time cat /dev/urandom | head -c 1000000000 > /dev/null

... était d'environ 4 minutes alors que ...

time openssl rand 1000000000 | head -c 1000000000 > /dev/null

... était un peu plus d'une minute.

Je ne sais pas s'il y a une différence de qualité aléatoire, mais l'un ou l'autre convient probablement pour l'essuyage HD.

Je vois beaucoup de réponses disant que l'utilisation de données aléatoires n'est pas importante. C'est à peu près vrai si tout ce que vous essayez de faire est d'essuyer le lecteur, mais pas tellement si vous l'essuyez en vue du chiffrement du disque.

Si vous remplissez un appareil avec des données non aléatoires, puis placez une partition chiffrée dessus, vous pourriez rencontrer un problème. La partie du lecteur qui stocke les données cryptées se démarquera du reste du lecteur, car les données cryptées seront aléatoires et les autres non. Cela peut être utilisé pour déterminer les informations sur le disque cryptographique qui pourraient être utilisées pour le casser. Le lien ci-dessous explique la théorie derrière le fonctionnement de certaines des attaques les plus courantes et comment les défendre (sous Linux, en tout cas).

Paramètres de chiffrement du disque dur Linux

Si vous avez besoin de nettoyer en toute sécurité un disque dur, il existe un outil très puissant: DBAN

Si vous souhaitez effacer un énorme périphérique bloc, je l'ai trouvé plus robuste à utiliser ddet le mappeur de périphériques au lieu de la redirection de sortie des données aléatoires. Les éléments suivants mapperont /dev/sdbpour le /dev/mapper/deviceToBeErasedcryptage et le décryptage de manière transparente entre les deux. Pour remplir le périphérique à l'extrémité chiffrée, les zéros sont copiés sur le côté texte brut du mappeur ( /dev/mapper/deviceToBeErased).

cryptsetup --cipher aes-xts-plain64 --key-file /dev/random --keyfile-size 32 create deviceToBeErased /dev/sdb
dd if=/dev/zero of=/dev/mapper/deviceToBeErased bs=1M

Il /dev/sdbest garanti que les données chiffrées ne peuvent être distinguées des données aléatoires s'il n'y a pas de faiblesse sérieuse dans AES. La clé utilisée est récupérée /dev/random(ne vous inquiétez pas - elle n'utilise que 32 octets).

vérifier frandom

http://billauer.co.il/frandom.html

selon mon test c'est le plus rapide

Plus votre outil est rapide, moins le résultat sera sûr. Générer un bon hasard prend du temps.

Quoi qu'il en soit, vous pouvez utiliser quelque chose comme dd si = / dev / zero of = / dev / sdb , mais évidemment cela ne va pas être aléatoire, il effacera juste beaucoup plus rapidement.

Une autre option pourrait être d'utiliser cette méthode / sbin / badblocks -c 10240 -s -w -t random -v / dev / sdb c'est plus rapide qu'urandom, mais les badblocks PRNG sont moins aléatoires.

/dev/random utilise beaucoup d'entropie système et ne produit donc qu'un flux de données lent.

/dev/urandom est moins sécurisé et plus rapide, mais il est toujours orienté vers de plus petits morceaux de données - il n'est pas destiné à fournir un flux continu de nombres aléatoires à grande vitesse.

Vous devez créer un PRNG de votre propre conception et le semer avec quelque chose de /dev/randomou /dev/urandom. Si vous en avez besoin un peu plus au hasard, semez-le périodiquement - tous les quelques Mo (ou quelle que soit la longueur de votre prng). Obtenir 4 octets (valeur 32 bits) d'urandom ou aléatoire est suffisamment rapide pour que vous puissiez le faire tous les 1k de données (réamorcer votre prng tous les 1k) et obtenir des résultats très aléatoires, tout en allant très, très, rapidement.

-Adam

Si vous souhaitez effacer rapidement un disque dur, écrivez-y des données non aléatoires. Ce n'est pas moins sûr que d'utiliser des données aléatoires. Quoi qu'il en soit, lorsqu'ils sont connectés à un ordinateur, les données d'origine ne peuvent pas être lues. Écrasement des données du disque dur: la grande controverse d'essuyage montre que les données d'origine ne peuvent pas non plus être lues à l'aide d'un microscope.

Formatez avec LUKS et dd sur le volume chiffré. Utilisez ensuite / dev / urandom pour effacer l'en-tête LUKS.

Si vous avez un support matériel AES, c'est une solution très rapide.

Brièvement:

cryptsetup luksFormat /dev/sdX
cryptsetup luksOpen /dev/sdX cryptodev
dd if=/dev/zero bs=1M of=/dev/mapper/cryptodev
cryptsetup luksClose cryptodev
# wipe the luks header.  Yes, it uses /dev/urandom but only for 2MB of data:
dd if=/dev/urandom bs=1M count=2 of=/dev/sdX

terminé!

Voir mon blog: Remplissez rapidement un disque avec des bits aléatoires (sans / dev / urandom)

Si vous souhaitez effacer un disque dur, dd ne supprime pas le contenu des secteurs réalloués et est très lent si le disque dur est en train de mourir. Au lieu de cela, vous pouvez utiliser la fonction d'effacement intégré des lecteurs, qui a été normalisée depuis longtemps.

Dans cet exemple, j'efface un disque dur mécanique de 500 Go en seulement 102 minutes. Même lorsqu'il est plein de secteurs réaffectés:

root@ubuntu:~# hdparm --security-set-pass Eins /dev/sdaj
security_password="Eins"

/dev/sdaj:
 Issuing SECURITY_SET_PASS command, password="Eins", user=user, mode=high
root@ubuntu:~# time hdparm --security-erase-enhanced Eins /dev/sdaj
security_password="Eins"

/dev/sdaj:
 Issuing SECURITY_ERASE command, password="Eins", user=user

real    102m22.395s
user    0m0.001s
sys     0m0.010s

root@ubuntu:~# smartctl --all /dev/sdaj | grep Reallocated
  5 Reallocated_Sector_Ct   0x0033   036   036   036    Pre-fail Always   FAILING_NOW 1327 

Vous pouvez voir plus de détails sur ata.wiki.kernel.org , mais leur exemple n'utilise pas --security-erase-Enhanced, qui est nécessaire pour supprimer les secteurs réaffectés avant la mention.

En pratique, il n'est probablement pas nécessaire d'amorcer le disque entier à partir d'un flux aléatoire continu.

Vous pouvez créer un bloc de données aléatoires de taille modeste, puis simplement le répéter encore et encore sur le disque.

Assurez-vous simplement que ce bloc de données n'est pas un multiple de la taille de bloc normale du disque, afin de ne pas écraser des blocs de données corrélés avec exactement le même bit de données aléatoires. Une taille de bloc qui est un nombre premier dans la plage ~ 1 Mo devrait faire l'affaire.

Pour plus de sécurité, faites-le quelques fois de plus, en utilisant à chaque fois une taille de bloc différente.

L'utilitaire 'shred' est simple et rapide. Si les attributs SMART du lecteur indiquent zéro secteur réaffecté, «shred» est probablement suffisamment sécurisé.

Cependant, si le lecteur a des secteurs réaffectés, les données sur les secteurs endommagés ne seront pas écrasées. Si les emplacements endommagés contenaient des données sensibles avant leur réallocation, «déchiqueter» peut ne pas être suffisant. Les «mauvais» secteurs peuvent être lus en réinitialisant la carte d'allocation du lecteur et en les lisant (à plusieurs reprises).

La possibilité de réinitialiser la carte d'allocation des secteurs défectueux varie selon le fabricant et le modèle de lecteur.

Si tout ce que vous voulez faire est d'écraser le disque, peu importe ce que vous utilisez, car quoi que ce soit va battre quoi que ce soit à court d'un laboratoire de médecine légale et je ne ferais pas confiance à quoi que ce soit de scorifier le lecteur pour arrêter ce niveau de ressources .

Utilisez simplement une source non aléatoire comme tous les zéros ou uns ou un motif répétitif comme (je pense que cela fonctionnera)

(head -c 4096 /dev/urandom; cat /dev/sdb/) > /dev/sdb