web-dev-qa-db-fra.com

différences entre aléatoire et urandom

J'essaie de découvrir les différences entre /dev/random et /dev/urandom des dossiers

  1. Quelles sont les différences entre /dev/random et /dev/urandom?
  2. Quand dois-je les utiliser?
  3. quand ne dois-je pas les utiliser?
randomprng
46
fernandohur

En utilisant /dev/random peut nécessiter d'attendre le résultat car il utilise ce qu'on appelle pool d'entropie, où des données aléatoires peuvent ne pas être disponibles pour le moment.

/dev/urandom renvoie autant d'octets que demandé par l'utilisateur et est donc moins aléatoire que /dev/random.

Comme on peut le lire sur la page de manuel:

aléatoire

Une fois lu, le /dev/random le périphérique ne renverra que des octets aléatoires dans le nombre estimé de bits de bruit dans le pool d'entropie. /dev/random devrait convenir à des utilisations nécessitant un caractère aléatoire de très haute qualité, comme un pad unique ou la génération de clés. Lorsque le pool d'entropie est vide, lit à partir de /dev/random se bloquera jusqu'à ce que des bruits environnementaux supplémentaires soient collectés.

urandom

Une lecture du /dev/urandom le périphérique ne bloquera pas l'attente d'une entropie supplémentaire. Par conséquent, s'il n'y a pas suffisamment d'entropie dans le pool d'entropie, les valeurs renvoyées sont théoriquement vulnérables à une attaque cryptographique sur les algorithmes utilisés par le pilote. La connaissance de la façon de procéder n'est pas disponible dans la littérature non classifiée actuelle, mais il est théoriquement possible qu'une telle attaque puisse exister. Si cela pose problème dans votre application, utilisez /dev/random au lieu.

À des fins de chiffrement, vous devez vraiment utiliser /dev/random en raison de la nature des données qu'elle renvoie. L'attente éventuelle devrait être considérée comme un compromis acceptable pour des raisons de sécurité, OMI.

Lorsque vous avez besoin de données aléatoires rapidement , vous devez utiliser /dev/urandom bien sûr.

Source: Wikipedia page, man page

40
Alexey Malev

Utilisez toujours/dev/urandom.

/ dev/urandom et/dev/random utilisent le même générateur de nombres aléatoires. Ils sont tous deux ensemencés par le même pool d'entropie. Les deux donneront un nombre également aléatoire d'une taille arbitraire. Ils peuvent tous deux donner une quantité infinie de nombres aléatoires avec seulement une graine de 256 bits. Tant que la graine initiale a 256 bits d'entropie, vous pouvez avoir une offre infinie de nombres aléatoires arbitrairement longs. Vous ne gagnez rien en utilisant/dev/random. Le fait qu'il y ait deux périphériques est une faille dans l'API Linux.

Si vous êtes préoccupé par l'entropie, l'utilisation de/dev/random ne va pas résoudre ce problème. Mais cela ralentira votre application tout en ne générant pas de nombres plus aléatoires que/dev/urandom. Et si vous n'êtes pas préoccupé par l'entropie, pourquoi utilisez-vous/dev/random?

Voici une bien meilleure explication/approfondie sur pourquoi vous devriez toujours utiliser/dev/urandom: http://www.2uo.de/myths-about-urandom/

23
Ironlenny

Quelles sont les différences entre /dev/random et /dev/urandom?

/dev/random et /dev/urandom sont des interfaces avec le générateur de nombres aléatoires du noyau:

  • La lecture renvoie un flux d'octets aléatoires suffisamment fort pour être utilisé en cryptographie
  • Leur écrire fournira les données du noyau pour mettre à jour le pool d'entropie

En ce qui concerne les différences, cela dépend du système d'exploitation:

  • Sous Linux, lecture depuis /dev/random peut bloquer, ce qui limite considérablement son utilisation dans la pratique
  • Sur FreeBSD, il n'y en a pas. /dev/urandom n'est qu'un lien symbolique vers /dev/random.

Quand dois-je les utiliser? Quand ne devrais-je pas les utiliser?

Il est très difficile de trouver un cas d'utilisation dans lequel vous devez utiliser /dev/random plus de /dev/urandom.

Danger de blocage:

  • C'est un vrai problème auquel vous devrez faire face lorsque vous déciderez d'utiliser /dev/random. Pour des utilisations uniques comme ssh-keygen il devrait être correct d'attendre quelques secondes, mais pour la plupart des autres situations, ce ne sera pas une option.
  • Si tu utilises /dev/random, vous devez l'ouvrir en mode non bloquant et fournir une sorte de notification utilisateur si l'entropie souhaitée n'est pas immédiatement disponible.

Sécurité:

Le /dev/random l'interface est considérée comme une interface héritée, et /dev/urandom est préféré et suffisant dans tous les cas d'utilisation, à l'exception des applications qui nécessitent un caractère aléatoire au début du démarrage; pour ces applications, getrandom (2) doit être utilisé à la place, car il se bloquera jusqu'à ce que le pool d'entropie soit initialisé.

Si un fichier de départ est enregistré à travers les redémarrages comme recommandé ci-dessous (toutes les principales distributions Linux l'ont fait depuis 2000 au moins), la sortie est sécurisée cryptographiquement contre les attaquants sans accès root local dès qu'elle est rechargée dans la séquence de démarrage, et parfaitement adéquate pour les clés de session de cryptage réseau. Depuis lit de /dev/random peut se bloquer, les utilisateurs voudront généralement l'ouvrir en mode non bloquant (ou effectuer une lecture avec timeout), et fournir une sorte de notification utilisateur si l'entropie souhaitée n'est pas immédiatement disponible.

Recommandation

En règle générale, /dev/urandomdoit être utilisé pour tout sauf les clés GPG/SSL/SSH à longue durée de vie.

6
Philipp Claßen

Réponse courte

Utilisation /dev/urandom

Longue réponse

Ils sont tous deux alimentés par le même générateur de nombres pseudo-aléatoires (CSPRNG) cryptographiquement sécurisé. Le fait que /dev/random attend l'entropie (ou plus précisément, attend que l'estimation du système de son entropie atteigne un niveau approprié) ne fait une différence que lorsque vous utilisez un algorithme sécurisé sur le plan de l'information, par opposition à un algorithme sécurisé sur le plan du calcul. Le premier englobe des algorithmes que vous n'utilisez probablement pas, tels que le partage secret de Shamir et le pavé à usage unique. Ce dernier contient des algorithmes que vous utilisez et dont vous vous souciez réellement, tels que AES, RSA, Diffie-Hellman, OpenSSL, GnuTLS, etc.

Donc, peu importe si vous utilisez des chiffres de /dev/random puisqu'ils sont de toute façon expulsés d'un CSPRNG, et il est "théoriquement possible" de casser les algorithmes avec lesquels vous les utilisez de toute façon.

Enfin, ce bit "théoriquement possible" signifie exactement cela. Dans ce cas, cela signifie utiliser toute la puissance de calcul dans le monde, pendant la durée de l'existence de l'univers pour casser l'application.

Par conséquent, il est pratiquement inutile d'utiliser /dev/random

Utilisez donc /dev/urandom

Sources

12

3
Mitchell Tracy