Nombres rapides, au hasard sécurisé

Question

Je cherchais une alternative plus rapide à /dev/urandom quand je suis tombé sur this friandise intéressante:

Un bon truc pour générer de très bons bits non aléatoire, mais-presque-aléatoires est de utilisez l'entropie de/dev/random pour amorcer un chiffrement de flux rapide et symétrique (mon préféré est blowfish), et redirigez-le vers l'application qui en a besoin.

Ce n'est pas une technique pour les débutants, mais il est facile à configurer avec un script shell à deux ou trois lignes et des tuyaux créatifs.

D'autres recherches a abouti à ce commentaire de Schneier sur la sécurité:

Si vous allez « injecter entropie » il y a un certain nombre de façons de le faire, mais l'une des meilleures façons est de « répandre "Il traverse un chiffrement de flux à haute vitesse et le coupler avec un système d'échantillonnage non déterministe.

-moi si je me trompe, mais il semble que cette méthode de génération de bits aléatoires est simplement mieux que /dev/urandom en termes de vitesse et de sécurité.

Donc, voici mon avis sur le code actuel:

time dd if=/dev/zero bs=1M count=400 | openssl bf-ofb -pass pass:`cat /dev/urandom | tr -dc [:graph:] | head -c56` > /dev/null 

Ce test de vitesse prend 400Mo de zéros et encrypte en utilisant Blowfish avec 448 panneton en pseudo-aléatoire, les caractères imprimables. Voici la sortie sur mon netbook:

400 + 0 enregistrements 400 + 0 enregistrements sur 419430400 octets (419 Mo), copié 14.0068 s, 29,9 Mo/s

0m14.025s réel utilisateur 0m12.909s sys 0m2.004s

C'est génial! Mais comment est-ce aléatoire? Permet d'acheminer les résultats à ent:

Entropie = 8,000000 bits par octet.

La compression optimale réduirait de 0% la taille de ce fichier de 419430416 octets.

La distribution du carré du Chi pour 419430416 échantillons est de 250,92, et au hasard dépasserait cette valeur 50,00 pour cent des fois.

La valeur moyenne arithmétique des octets de données est 127,5091 (127,5 = aléatoire). La valeur Monte Carlo pour Pi est 3.141204882 (erreur 0.01%). Le coefficient de corrélation série est de -0,000005 (totalement décorrélé = 0,0).

Cela semble bon. Cependant, mon code a quelques défauts évidents:

1. Il utilise /dev/urandom pour la source d'entropie initiale.
2. La force de la clé n'est pas équivalente à 448 bits car seuls les caractères imprimables sont utilisés.
3. Le chiffre doit être ré-ensemencé périodiquement pour "étaler" l'entropie.

Donc, je me demandais si je suis sur la bonne voie. Et si quelqu'un sait comment corriger ces défauts, ce serait génial. En outre, pouvez-vous s'il vous plaît partager ce que vous utilisez pour effacer les disques en toute sécurité si elle est autre que /dev/urandom, sfill, badblocks, ou DBAN?

Merci!

Modifier: code mis à jour pour utiliser blowfish comme un chiffrement de flux.

Answer 1

Si vous cherchez simplement à effacer les disques en toute sécurité, vous n'avez pas vraiment à vous soucier du caractère aléatoire des données que vous écrivez. L'important est d'écrire tout ce que vous pouvez - peut-être une ou deux fois. Quelque chose de plus que cela est exagéré, sauf si votre «adversaire» est une grande organisation gouvernementale avec les ressources nécessaires pour se livrer à la récupération de données (et il n'est pas clair qu'ils peuvent le lire même pas ces jours avec les densités de disque maintenant utilisé). J'ai utilisé le programme GNU 'shred' - mais je ne m'inquiète que par hasard. Quand je l'ai fait, j'ai formaté un système de disque sur le lecteur de disque, puis l'ai rempli avec un seul fichier contenant des données quasi-aléatoires, puis broyé cela. Je pense que c'était surtout exagéré.

Peut-être devriez-vous lire le livre 'Cryptography Engineering' de Schneier?