Comment fonctionne le noyau d'entropie de travail?

Je suis en utilisant /dev/urandom pour générer des données aléatoires pour mes programmes. J'ai appris que /dev/random peut être vide parce que, contrairement à /dev/urandom, il n'utilise pas de SHA quand il n'y a pas assez d'octets générés. /dev/random utilise "entropie du noyau". Apparemment, il s'appuie sur le clavier timings, les mouvements de la souris, IDE et les horaires.

Mais comment cela fonctionne?

Et ne serait-il pas possible de "nourrir" le pool d'entropie faire le /dev/random sortie prévisible?

  • À mon humble avis, vous devriez remplacer l'un des balises de mentionner que cette question est spécifique à linux, et de toute façon, sur la 2ème partie -- non, seul root peut le faire, les utilisateurs normaux ne peuvent mélanger dans de nouvelles données, ce qui est inoffensif.
InformationsquelleAutor Antoninarto | 2013-11-14
  1. 23

    Ce que vous dites est sur place, oui, théoriquement, il est possible de nourrir l'entropie dans /dev/random, mais vous avez besoin de contrôler un grand nombre du noyau du "bruit" des sources pour qu'il soit significatif. Vous pouvez regarder le source pour aléatoire.c, pour voir où /dev/random ramasse bruit. En gros, si vous contrôlez un nombre important de sources de bruits, alors vous pouvez deviner ce que les autres contribuent à la source d'entropie.

    Depuis /dev/urandom est un Hachage de la chaîne d' graines de /dev/random, alors vous pouvez réellement prédire les prochains numéros, si vous saviez la graine. Si vous avez suffisamment de contrôle sur le pool d'entropie, puis à partir de la sortie de /dev/urandom vous pourriez être en mesure de deviner que cette graine, qui vous permettrait de prédire tous les prochains numéros de /dev/urandom, mais uniquement si vous gardez /dev/random épuisé, sinon /dev/urandom seront replantés.

    Cela étant dit, je n'ai pas vu quelqu'un le faire, pas même dans un environnement contrôlé. Bien sûr, ce n'est pas une garantie, mais je ne m'inquiéterais pas.

    Donc, je préfère utiliser /dev/urandom et de garantir que mon programme ne bloque pas lors de l'attente pour l'entropie, au lieu d'utiliser /dev/random et demandant à l'utilisateur de faire des choses stupides, comme le déplacement de la souris ou frapper sur le clavier.

    Je pense que vous devriez lire Sur l'entropie et de l'aléatoire de LWN, j'espère que ça va calmer vos inquiétudes :-).

    Vous devriez toujours être inquiets, puis vous obtenez une HRNG.

    Modifier
    Voici une petite note sur l'entropie:

    Je pense que le concept de l'entropie est généralement difficile à saisir. Il y a un article avec plus d'informations sur Wikipédia. Mais, fondamentalement, dans ce cas, vous pouvez lire l'entropie comme aléatoire.

    Donc comment je le vois, c'est que vous avez un gros sac de billes de couleurs, plus l'entropie dans ce sac plus il est difficile de prédire la prochaine couleur tiré du sac.

    Dans ce contexte, votre pool d'entropie est juste un tas d'octets aléatoires, où l'on ne peut pas être dérivée de la précédente, ou à l'un des autres. Ce qui signifie que vous avez un haut niveau d'entropie.

    • Merci pour cette réponse vraiment bonne. Comme un non anglophone, le mot "entropie" est un peu difficile à obtenir pour moi. Je suis en imaginant l'entropie comme un bloc mémoire qui, quand est rempli avec 8/16 bits, imprime le symbole correspondant, ai-je le droit?
    • J'ai ajouté une petite note sur l'entropie. J'espère que cela rend les choses un peu plus clair pour vous.
    • Chose la plus cool que j'ai lu toute la journée 🙂
    InformationsquelleAutor jbr
  2. 3

    J'apprécie la profondeur de jbr réponse.

    L'ajout d'une pratique de mise à jour pour toute personne actuellement à regarder un ipsec pki commande ou quelque chose de similaire blocage sur vide d'entropie:

    Je viens d'installer rng-tools dans une autre fenêtre et mon pki commande terminée.

    apt-get install rng-tools
    InformationsquelleAutor jorfus
  3. 1

    Je suis dans le milieu de la lecture d'un papier à
    factorable
    et pris note de la section où il est dit:

    "Pour la bibliothèque de développeurs:
    Par défaut la configuration la plus sécurisée. Les deux OpenSSL
    et Dropbear par défaut à l'aide de /dev/urandom au lieu de
    /dev/random, et Dropbear par défaut à l'aide d'un moins sûr
    De signature DSA caractère aléatoire de la technique, même si
    plus de sécurité technique est disponible comme une option."

    L'adresse des auteurs la contre-partie d'un retrait de l'application lors de l'attente pour l'entropie de construire /dev/random pour obtenir une meilleure sécurité par rapport à un rapide, mais moins sûr, le résultat de /dev/urandom.

    • Se pourrait-il qu'il existe la moindre erreur dans votre dernière phrase, car il y a deux fois /dev/random.
    • Bonne prise, Kevin. La seconde occurence devrait être /dev/urandom. /dev/urandom renvoie des résultats immédiatement quel que soit le niveau de l'entropie présent. /dev/random va attendre/accrocher un niveau adéquat de l'entropie avant de fournir les résultats.
    • Puisqu'ils ne sont pas sur le bloc en cours d'exécution hors de l'entropie, ne pourriez-vous pas théoriquement "aspirer" l'entropie en l'utilisant vous-même (sans root), et en laissant beaucoup moins d'entropie (ou aucun, à l'exception pseudo) pour les programmes?
    InformationsquelleAutor Mike