Quelle est la graine la plus sûre pour la génération de nombres aléatoires?
Quelles sont les sources d'entropie les plus sûres pour amorcer un générateur de nombres aléatoires? Cette question est indépendante de la langue et de la plate-forme et s'applique à n'importe quelle machine sur un réseau. Idéalement, je recherche des sources disponibles pour une machine dans un environnement cloud ou un serveur fourni par une société d'hébergement.
Il y a deux faiblesses importantes à garder à l'esprit. L'utilisation du temps pour envoyer un générateur de nombres aléatoires est une violation de CWE-337 . L'utilisation d'un petit espace de départ serait une violation de CWE-339 .
Voici quelques réflexions. Si vous êtes impatient, passez à la conclusion, à la fin.
1. Qu'est-ce qu'une graine sécurisée?
La sécurité n'est définie que relativement à un modèle d'attaque. Nous voulons ici une séquence de n bits, qui a n bits d'entropie par rapport à l'attaquant: en clair, que l'un des possibles 2n les valeurs de cette séquence sont également probables du point de vue de l'attaquant.
Il s'agit d'un modèle qui se rapporte aux informations disponibles pour l'attaquant. L'application qui génère et utilise la graine (normalement dans un PRNG) connaît la graine exacte; le fait que la graine soit "sûre" n'est pas une propriété absolue de la graine ni même du processus de génération de la graine. Ce qui compte, c'est la quantité d'informations dont dispose l'attaquant sur le processus de génération. Ce niveau d'information varie considérablement selon la situation; par exemple. sur un système multi-utilisateur (par exemple de type Unix, avec une séparation des applications imposée par le matériel), un timing précis des accès à la mémoire peut révéler des informations sur la façon dont un processus nominalement protégé lit la mémoire. Même un attaquant distant peut obtenir de telles informations; cela a été démontré (dans des conditions de laboratoire) sur le chiffrement AES (les implémentations AES typiques utilisent des tables internes, avec des modèles d'accès qui dépendent de la clé; l'attaquant force les échecs de cache et les détecte via timing précis des réponses du serveur).
La durée de vie des graines doit être prise en compte. La graine est en sécurité tant qu'elle reste inconnue de l'attaquant; cette propriété doit rester vraie par la suite. En particulier, il ne doit pas être possible de récupérer la graine à partir d'extraits de la sortie PRNG suivante. Idéalement, même l'obtention de l'état PRNG complet à un moment donné ne devrait fournir aucune indication quant aux bits que le PRNG a produits au préalable.
Le point que je veux souligner ici est qu'une graine n'est "sécurisée" que si elle est utilisée dans un contexte où elle peut rester sécurisée, ce qui implique plus ou moins un PRNG cryptographiquement sécurisé et un stockage inviolable . Si un tel stockage est disponible, alors la graine la plus sécurisée est celle qui a été générée once , il y a longtemps, et utilisée dans un PRNG _ sécurisé hébergé par matériel inviolable.
Malheureusement, un tel matériel est cher (il s'appelle un HSM et coûte quelques centaines ou milliers de dollars), et ce coût s'avère généralement difficile à justifier (une mauvaise graine n'empêchera pas un système de fonctionner; c'est le problème habituel de non-testabilité de sécurité). Il est donc habituel d'opter pour des solutions "principalement logicielles". Étant donné que le logiciel n'est pas bon pour fournir un stockage confidentiel à long terme, la durée de vie de la graine est arbitrairement raccourcie: une nouvelle graine est périodiquement obtenue. Dans Fortuna , un tel réamorçage est censé se produire au moins une fois par mégaoctet de données pseudo-aléatoires générées.
Pour résumer, dans une configuration sans HSM, une graine sécurisée est une graine qui peut être obtenue relativement facilement (puisque nous le ferons assez souvent) en utilisant des données qui ne peuvent pas être collectées par l'attaquant.
2. Mélange
Les sources de données aléatoires ne produisent pas de bons bits uniformes (chaque bit ayant la valeur 1 avec une probabilité exactement 0,5 , et les valeurs de bits sont indépendantes les unes des autres). Au lieu de cela, les sources aléatoires produisent des valeurs dans des ensembles spécifiques à la source. Ces valeurs peuvent être encodées sous forme de séquences de bits, mais vous n'en avez pas pour votre argent: pour avoir n bits d'entropie, vous devez avoir des valeurs qui, une fois encodées, utilisent beaucoup plus que n bits.
L'outil cryptographique à utiliser ici est un [~ # ~] prf [~ # ~] qui accepte une entrée de longueur arbitraire et produit un n - sortie bit. Un PRF cryptographiquement sécurisé de ce type est modélisé comme un Oracle aléatoire : en termes courts, il n'est pas possible de calculer quoi que ce soit au sujet de la sortie Oracle sur une entrée donnée sans l'essayer.
À l'heure actuelle, nous avons des fonctions de hachage . Les fonctions de hachage doivent remplir quelques propriétés de sécurité, à savoir la résistance aux pré-images, aux secondes pré-images et aux collisions. Nous analysons généralement les fonctions de hachage en essayant de voir comment elles s'écartent du modèle Oracle aléatoire. Il y a un point important ici: un PRF qui suit le modèle Oracle aléatoire sera une bonne fonction de hachage, mais il peut y avoir de bonnes fonctions de hachage (dans le sens de la résistance aux préimages et aux collisions) qui sont néanmoins faciles à distinguer d'un Oracle aléatoire . En particulier, les fonctions SHA-2 (SHA-256, SHA-512 ...) sont considérées comme sécurisées, mais s'écartent du modèle Oracle aléatoire en raison de la "longueur extension extension "(étant donné h (m) , il est possible de calculer h (m || m ') pour une partie message contraint m ' sans connaître m ). L'attaque d'extension de longueur ne semble pas fournir de raccourci vers la création de préimages ou de collisions, mais elle montre que ces fonctions de hachage ne sont pas des oracles aléatoires. Pour le concours SHA-3 , le NIST a déclaré que les candidats ne devraient pas autoriser une telle "extension de longueur".
Par conséquent, l'étape de mélange n'est pas facile. Votre meilleur pari est toujours, en ce moment, d'utiliser SHA-256 ou SHA-512, et de passer à SHA-3 quand il sera choisi (cela devrait arriver vers la mi-2012).
. Sources
Un ordinateur est une machine déterministe. Pour obtenir un caractère aléatoire, vous devez mélanger le résultat de certaines mesures du monde physique.
Une note philosophique: à un moment donné, vous devez faire confiance à des gars intelligents, du genre à porter des blouses de laboratoire ou à être payés pour faire de la recherche fondamentale. Lorsque vous utilisez une fonction de hachage telle que SHA-256, vous faites réellement confiance à un tas de cryptographes quand ils vous le disent: nous avons recherché des défauts, très dur, et pendant plusieurs années, et nous n'en avons trouvé aucun. Lorsque vous utilisez un peu de matière radioactive en décomposition avec un compteur Geiger, vous faites confiance à certains physiciens qui disent: nous avons cherché très fort les moyens de prédire quand le prochain noyau [atom va s'éteindre, mais nous n'en avons trouvé aucun. Notez que, dans ce cas spécifique, les "physiciens" incluent des gens comme Becquerel, Rutherford, Bohr ou Einstein, et "vraiment dur" signifie "plus d'un siècle de recherche accumulée", vous n'êtes donc pas exactement en territoire vierge ici. Pourtant, il y a encore un peu de confiance dans la sécurité.
Certains ordinateurs incluent déjà du matériel qui génère des données aléatoires (c'est-à-dire qui utilise et mesure un processus physique qui, pour autant que le physicien puisse le dire, est suffisamment aléatoire). Le VIA C3 (une ligne de CPU compatible x86) possède un tel matériel. Curieusement, le Commodore 64, ordinateur personnel d'il y a 30 ans, avait également un RNG matériel (ou du moins dit Wikipedia , au moins).
À moins de matériel spécial, vous devez utiliser tous les événements physiques que vous pourriez obtenir. En règle générale, vous utiliseriez les frappes au clavier, les paquets Ethernet entrants, les mouvements de la souris, les accès au disque dur ... chaque événement est accompagné de certaines données et se produit à un instant mesurable (les processeurs modernes ont des horloges très précises, grâce aux compteurs de cycles). Ces instants et le contenu des données d'événement peuvent être accumulés en tant que sources d'entropie. C'est beaucoup plus facile pour le système d'exploitation lui-même (qui a un accès direct au matériel) que pour les applications, donc la façon normale de collecter une graine est de demander au système d'exploitation (sous Linux, cela s'appelle /dev/random Ou /dev/urandom [Les deux ont des avantages et des problèmes, choisissez votre poison]; sous Windows, appelez CryptGenRandom()).
Un cas extrême est la pré-1.2 Java applets, avant l'ajout de Java.security.SecureRandom; étant donné que Java est très efficace pour isoler le code d'application du matériel, l'obtention d'une graine aléatoire était un défi difficile. La solution habituelle était d'avoir deux ou trois threads s'exécutant simultanément et de changer de thread follement, de sorte que le nombre de commutateurs de threads par seconde était quelque peu aléatoire (en fait, cela essaie d'extraire le hasard à travers le timing des actions du planificateur du système d'exploitation, qui dépendent sur ce qui se produit également sur la machine, y compris les événements liés au matériel). C'était assez insatisfaisant.
Un problème avec les mesures liées au temps est que l'attaquant sait également quelle heure il est. Si l'attaquant a un accès applicatif à la machine, il peut également lire le compteur de cycles.
Certaines personnes ont proposé d'utiliser des cartes audio comme sources de "bruit blanc" en réglant l'amplificateur à son maximum (même les serveurs ont de l'audio de nos jours). D'autres plaident pour la mise sous tension des webcams (nous savons que les vidéos webcam sont "bruyantes" et c'est bon pour le hasard, même si la webcam fait face à un mur); mais les serveurs avec webcams ne sont pas courants. Vous pouvez également envoyer une requête ping à un serveur réseau externe (par exemple www.google.com) Et voir combien de temps il faut pour revenir (mais cela pourrait être observé par un attaquant espionnant le réseau).
La beauté de l'étape de mélange, avec une fonction de hachage, est que l'entropie ne peut que s'accumuler; il n'y a aucun mal à ajouter des données, même si ces données ne sont pas si aléatoires. Remplissez le plus possible la fonction de hachage. Les fonctions de hachage sont assez rapides (une bonne implémentation SHA-512 traitera plus de 150 Mo/s sur un PC typique, en utilisant un seul cœur) et l'amorçage ne se produit pas souvent.
4. Conclusion
Utilisez un [~ # ~] hsm [~ # ~] . Ils coûtent quelques centaines ou milliers de dollars, mais vos secrets ne valent-ils pas beaucoup plus que cela? Un HSM comprend du matériel RNG, exécute l'algorithme PRNG et stocke la graine avec une résistance à la falsification. De plus, la plupart des HSM sont déjà certifiés en ce qui concerne diverses réglementations nationales (par exemple FIPS 140 aux États-Unis et les niveaux EAL en Europe).
Si vous êtes si bon marché que vous n'achèterez pas de HSM, ou si vous voulez protéger des données qui ne valent pas vraiment la peine, alors construisez un PRNG cryptographiquement sécurisé en utilisant une graine obtenue en hachant lots de mesures physiques. Tout ce qui provient d'un matériel doit être haché, ainsi que l'instant (lire "compteur de cycles") auquel ces données ont été obtenues. Vous devez hacher les données par mégaoctet ici. Ou, mieux encore, faites pas faites-le: utilisez simplement les fonctionnalités offertes par votre système d'exploitation, qui inclut déjà un tel code.
La graine la plus sûre est celle qui a le plus haut niveau d'entropie (ou le plus grand nombre de bits qui ne peuvent pas être prédits). Le temps est une mauvaise graine en général parce qu'il a une petite entropie (c.-à-d. Si vous savez quand la transaction a eu lieu, vous pouvez deviner l'horodatage à quelques bits près). Les sources d'entropie matérielle (par exemple des processus de désintégration) sont très bonnes car elles produisent un bit d'entropie pour chaque bit de graine.
Habituellement, une source matérielle n'est pas pratique pour la plupart des besoins, ce qui vous amène à compter sur le mélange d'un certain nombre de sources d'entropie de faible qualité pour en produire une plus élevée. En règle générale, cela se fait en estimant le nombre de bits d'entropie pour chaque échantillon, puis en rassemblant suffisamment d'échantillons pour que l'espace de recherche de la source d'entropie soit suffisamment grand pour qu'il soit impossible pour un attaquant de rechercher (128 bits est une bonne règle de base). ).
Certaines sources que vous pouvez utiliser sont: l'heure actuelle en microsecondes (généralement une entropie très faible de 1/2 un peu selon la résolution et la facilité avec laquelle un attaquant peut le deviner), l'heure interarrivale des événements d'interface utilisateur, etc.
Les sources de système d'exploitation telles que/dev/random et le générateur de nombres aléatoires Windows CAPI fournissent souvent une source pré-mélangée de ces sources à faible entropie, par exemple le générateur Windows CryptGenRandom comprend:
- ID de processus actuel (GetCurrentProcessID).
- L'ID de thread actuel (GetCurrentThreadID).
- Le nombre de ticks depuis le démarrage (GetTickCount).
- L'heure actuelle (GetLocalTime).
- Divers compteurs de performance de haute précision (QueryPerformanceCounter) .-
- Un hachage MD4 du bloc d'environnement de l'utilisateur, qui comprend le nom d'utilisateur, le nom de l'ordinateur et le chemin de recherche. [...] -
- Compteurs CPU internes de haute précision, tels que RDTSC, RDMSR, RDPMC
Certains PRNG ont des stratégies intégrées pour permettre le mélange de l'entropie à partir de sources de faible qualité pour produire des résultats de haute qualité. Un très bon générateur est le générateur Fortuna . Il utilise spécifiquement des stratégies qui limitent le risque si l'une des sources d'entropie est compromise.
La graine la plus sécurisée est une graine vraiment aléatoire, que vous pouvez approximer dans les systèmes informatiques pratiques d'aujourd'hui en utilisant, répertoriés en degrés de confiance décroissants:
- Matériel spécial
- Installations fournies par votre système d'exploitation qui tentent de capturer des événements chaotiques comme les lectures de disque et les mouvements de souris (/ dev/random). Une autre option sur cette ligne de "capture d'événements imprévisibles" consiste à utiliser un processus ou une machine indépendante qui capture ce qui lui arrive en tant que pool d'entropie, au lieu du générateur de nombres aléatoires "sécurisé" fourni par le système d'exploitation, par exemple, voir EntropyPool
- Utiliser une mauvaise graine (c'est-à-dire l'heure) et la combiner avec d'autres données que vous ne connaissez que (par exemple, hacher l'heure avec un secret et d'autres critères tels que les PID ou l'état interne de l'application/du système d'exploitation, de sorte qu'il ne le fait pas nécessairement augmenter et diminuer selon le temps)
En tant qu'interprétation intéressante des tampons à usage unique, chaque fois que je suis engagé dans l'espionnage, j'ai un système par lequel je n'ai besoin que de communiquer quelques lettres. Par exemple, la dernière fois que je vendais des plans secrets pour construire des grille-pain au duché de Grand Fenwick, je n'avais qu'à chuchoter:
enonH
à mon confédéré. Elle savait pour obtenir http://is.Gd/enonH- (il s'agit d'une URL d'extension "sûre" qui vous amène à la page d'extension is.Gd qui, à son tour, pointe vers une image complètement SFW de une grenouille). Cela nous a donné 409k bits de pad unique ou - si je fais un clin d'œil en chuchotant "enonH" - elle sait prendre le hachage de l'image et l'utiliser comme clé de décodage pour ma prochaine transmission.
En raison de la compression des images JPEG, elles ont tendance à être des sources d’entropie relativement bonnes, comme indiqué par ent :
$ ent frog.jpg
Entropie = 7,955028 bits par octet.Une compression optimale réduirait la taille de ce fichier 51092 octets de 0%.
La distribution du chi carré pour 51092 échantillons est de 4409,15 et dépasserait au hasard cette valeur 0,01 pour cent du temps.
La valeur arithmétique moyenne des octets de données est de 129,0884 (127,5 = aléatoire).
La valeur de Monte Carlo pour Pi est de 3,053435115 (erreur 2,81%).
Le coefficient de corrélation série est de 0,052738 (totalement non corrélé = 0,0). Non corrélé = 0,0).
Combinez cela avec l'image presque impossible à deviner vers laquelle je l'ai dirigée et mes plans de grille-pain secrets sont à l'abri de The Man.
La réponse est /dev/random Sur une machine Linux. Ceci est très proche d'un "vrai" générateur de nombres aléatoires, où comme /dev/urandom peut être généré par un PRNG si la piscine d'entropie est sèche. La citation suivante est tirée du random.c du noyau Linux Ce fichier entier est une belle lecture, plein de commentaires. Le code lui-même a été adopté à partir de PGP. Sa beauté n'est pas limitée par les contraintes de C, qui est marqué par des structures globales enveloppées par des accesseurs. C'est un design tout simplement impressionnant.
Cette routine collecte le bruit environnemental des pilotes de périphériques, etc., et renvoie de bons nombres aléatoires, adaptés à une utilisation cryptographique. Outre les utilisations cryptographiques évidentes, ces nombres sont également bons pour semer des numéros de séquence TCP et d'autres endroits où il est souhaitable d'avoir des nombres qui sont non seulement aléatoires, mais difficiles à prédire par un attaquant.
Théorie de fonctionnement
Les ordinateurs sont des appareils très prévisibles. Il est donc extrêmement difficile
pour produire des nombres vraiment aléatoires sur un ordinateur --- par opposition à
nombres pseudo-aléatoires, qui peuvent facilement être générés à l'aide d'un
algorithme. Malheureusement, il est très facile pour les attaquants de deviner la séquence des générateurs de nombres pseudo-aléatoires, et pour certains
applications ceci n'est pas acceptable. Donc, à la place, nous devons essayer de recueillir le "bruit environnemental" de l'environnement de l'ordinateur, qui doit être difficile à observer par les attaquants extérieurs, et l'utiliser pour générer des nombres aléatoires. Dans un environnement Unix, il est préférable de le faire depuis l'intérieur du noyau.Les sources d'aléatoire de l'environnement incluent l'inter-clavier
temporisations, temporisations d'interruption de certaines interruptions et autres événements qui sont à la fois (a) non déterministes et (b) difficiles à mesurer pour un observateur extérieur. L'aléatoire de ces sources est ajouté à un "pool d'entropie", qui est mélangé à l'aide d'une fonction de type CRC. Ce n'est pas cryptographiquement solide, mais c'est suffisant en supposant que le caractère aléatoire n'est pas choisi de manière malveillante, et c'est assez rapide pour que la surcharge de le faire à chaque interruption soit très raisonnable. Comme les octets aléatoires sont mélangés dans le pool d'entropie, les routines gardent une estimation du nombre de bits de caractère aléatoire qui ont été stockés dans l'état interne du générateur de nombres aléatoires.Lorsque des octets aléatoires sont souhaités, ils sont obtenus en prenant le SHA
hachage du contenu du "pool d'entropie". Le hachage SHA évite d'exposer l'état interne du pool d'entropie. On pense qu'il est impossible sur le plan informatique de dériver toute information utile sur l'entrée de SHA de sa sortie. Même s'il est possible d'analyser SHA de manière intelligente, tant que la quantité de données renvoyées par le générateur est inférieure à l'entropie inhérente à
le pool, les données de sortie sont totalement imprévisibles. Pour cette raison, le sous-programme diminue son estimation interne du nombre de bits de "vrai caractère aléatoire" contenus dans le pool d'entropie lorsqu'il génère des nombres aléatoires. Si cette estimation passe à zéro, la routine peut toujours générer des nombres aléatoires; cependant, un attaquant peut (au moins en théorie) être en mesure de déduire la sortie future du générateur des sorties précédentes. Cela nécessite une cryptanalyse réussie de SHA, qui n'est pas considérée comme faisable, mais il existe une possibilité à distance. Néanmoins, ces chiffres devraient être utiles dans la grande majorité des cas....
Écrivez un client de radio Internet, utilisez un échantillon aléatoire de la diffusion. Avoir un pool de plusieurs stations parmi lesquelles choisir et/ou se replier.
Si vous lisez dans la crypto-théorie, il devient évident que la graine la plus sûre serait celle générée par un événement chaotique. Tout au long de l'histoire récente, les opérations secrètes ont utilisé ce qui est connu sous le nom de "One-time pad" , qui s'est révélé impossible à casser. Normalement, ceux-ci sont générés par un assortiment de postes d'écoute atmosphérique dispersés au milieu de nulle part. Le bruit atmosphérique est suffisamment chaotique pour être considéré comme aléatoire. Le principal problème avec cette méthode est que la logistique pour un bloc ponctuel est considérable.
Ma suggestion est de trouver un événement suffisamment chaotique pour en extraire les données.
James a raison. De plus, vous pouvez acheter du matériel qui vous fournira des données aléatoires. Je ne sais pas où je l'ai vu, mais je pense avoir lu que certaines cartes son sont livrées avec un tel matériel.
Vous pouvez également utiliser un site comme http://www.random.org/
4 - choisi par un lancer de dés très aléatoire. :-)
Random.org offre un véritable générateur de nombres aléatoires service Web , "semé" par le bruit atmosphérique.
Vous obtenez 200 000 bits aléatoires gratuitement chaque jour, jusqu'à la limite de 1 million de bits aléatoires, après quoi vous devez recharger votre compte, cela devient aussi bon marché que 4 millions de bits par dollar.
OK, en supposant que le client a besoin d'une graine solide, et que vous utilisez le cloud computing, voici une solution, pour certains générateurs de nombres aléatoires matériels, vous pouvez regarder ici:
http://en.wikipedia.org/wiki/Hardware_random_number_generator
Ainsi, cela suppose que chaque client possède une paire de clés publique/privée, où le serveur connaît la clé publique de chaque client. Pour générer une clé, vous pouvez utiliser quelque chose de similaire à ce qui a été fait avec PGP, au début, où vous prenez la différence de temps entre les frappes de touches pendant que quelqu'un tape, car cela ne sera pas devinable.
Ainsi, le client soumet une demande pour un nombre aléatoire. Le serveur utilise un générateur matériel, le chiffre avec la clé publique et le signe avec la clé privée du serveur. Le client peut alors vérifier d'où il vient, puis le déchiffrer.
Cela vous permettra de générer un nombre aléatoire et de le transmettre de manière sécurisée.
MISE À JOUR:
Votre meilleur pari est de regarder dans le Art of Programming Computer ou l'un des livres de méthodes numériques, ou regardez ce que Bruce Schneier a écrit, comme ces liens: http://www.schneier.com/blog/archives/2006/06/random_number_g.htmlhttp://www.cryptosys.net/rng_algorithms.htmlhttp: // www .schneier.com/blog/archives/2006/06/random_number_g.htmlhttp://www.schneier.com/blog/archives/2006/06/random_number_g.html Suggestions pour l'aléatoire Génération de nombres dans le logiciel, ftp://ftp.rsasecurity.com/pub/pdfs/bull-1.pdf
Vous pouvez également voir comment Crypto ++ fait la génération, ou au moins voir comment Wei Dai l'a fait, http://www.cryptopp.com/
Comme le consensus est cryptographiquement fort, les nombres aléatoires doivent être dérivés du matériel. Certains processeurs ont cette fonctionnalité (puces Intel parmi d'autres). Des cartes son peuvent également être utilisées pour cela en mesurant les fluctuations de faible bit dans le convertisseur analogique-numérique.
Mais en raison des besoins matériels, il n'y a pas de réponse indépendante de la langue et de la plate-forme. À peu près n'importe quel système d'exploitation plus grand prendra en charge les nombres aléatoires sécurisés. Il est également difficile d'implémenter un bon générateur de nombres aléatoires avec une bonne sortie, car vous devrez suivre l'entropie restante dans le pool.
La première étape consiste donc à déterminer la ou les langues que vous utiliserez. Certains ont une forte prise en charge des nombres aléatoires - si ce n'est pas le cas, vous devrez faire abstraction de la génération pour appeler des sources aléatoires dépendant de la plate-forme.
Selon vos besoins en matière de sécurité, lassez-vous des sources "en ligne", car un homme du milieu peut constituer une menace sérieuse pour les sources en ligne non authentifiées.
Utilisez random.org ils prétendent offrir de vrais nombres aléatoires à quiconque sur Internet et ils ont également une API HTTP que vous peut utiliser. Ils offrent des services gratuits et payants.
avertissement: je ne suis en aucun cas affilié à random.org
Vos méthodes les plus sûres proviendront de la nature. C'est-à-dire quelque chose qui se produit en dehors de votre système informatique et au-delà de notre capacité à prédire ses schémas.
Par exemple, de nombreux chercheurs sur PRNGs sécurisés cryptographiquement utiliseront la désintégration radioactive comme modèle, d'autres pourraient se pencher sur les fractales, etc. Il existe des moyens de créer de vrais RNG
L'une de mes façons préférées de mettre en œuvre un PRNG est à partir de l'interaction de l'utilisateur avec un ordinateur. Par exemple, ce message n'était pas quelque chose qui pouvait être prédéterminé par la rétro-ingénierie de ma série de messages précédente . Là où j'ai laissé ma souris sur mon écran est très aléatoire, la trace qu'il a fait est également aléatoire. Voir à partir des interactions avec les utilisateurs est. L'abus des moyens de fournir une entrée spécifique de telle sorte que des nombres spécifiques soient générés pourrait être atténué en utilisant un 'essaim "des entrées utilisateur et le calcul de son" vecteur ", tant que vous n'avez pas chaque utilisateur dans votre système en tant que Eve, ça devrait aller. Cela ne convient pas à de nombreuses applications, car votre pool de nombres est directement proportionnel à l'utilisateur La mise en œuvre de cette méthode peut avoir ses propres problèmes.
Les personnes intéressées par le RNG ont déjà fait des choses telles que:
- Utilisez une webcam, quels que soient les aléas aléatoires de l'écran, lorsque ce camion passe, ce sont toutes des données aléatoires.
- Comme déjà mentionné, le rayonnement
- Atmosphère
- Interaction avec l'utilisateur (comme mentionné)
- Qu'est-ce qui se passe dans le système EDG.
Les graines sécurisées proviennent de la nature.
edit: En fonction de ce que vous cherchez à faire, je pourrais suggérer d'utiliser une agrégation de l'EDG de votre serveur cloud.
Avec Linux, la réponse est/dev/random (sous Windows, je pense que l'équivalent s'appelle CryptGenRand).
Cependant, dans un environnement cloud/dev/random peut être gravement épuisé et peut ne pas avoir suffisamment d'entropie pour répondre à votre demande.
Pour résoudre ce problème, notre société développe un véritable appareil générateur de nombres aléatoires qui peut fournir de bons nombres aléatoires (d'origine quantique) à des milliers de serveurs et VM simultanément. Si l'appliance est installée dans le LAN de votre centre de données cloud, tout ce dont vous avez besoin est que notre démon s'exécute dans votre machine. Ce démon surveille/dev/le niveau d'entropie aléatoire et lorsque l'entropie est nécessaire fait une demande à l'appliance (sur le réseau) et place les données aléatoires reçues dans le pool d'entropie du noyau.
Si vous souhaitez en savoir plus sur notre solution, veuillez visiter notre site Web (www.sqrtech.com) ou contactez-nous à [email protected].
Julien
Vous pouvez gagner des nombres aléatoires générés par la désintégration radioactive. Cela semble un peu étrange au début, mais vous obtenez de vrais nombres aléatoires.
Vous devez d'abord définir l'utilisation/le but réel du générateur de nombres aléatoires et pourquoi pensez-vous qu'il doit passer une norme de sécurité aussi élevée? La raison pour laquelle je demande, c'est que vous avez mentionné le retirer de la boîte - si vous l'utilisez effectivement à des fins de sécurité, sécuriser la source et le canal pour l'envoyer est beaucoup plus important que la cueillette académique de quiconque.
Le deuxième élément est la taille des nombres aléatoires réels dont vous avez besoin - une grosse graine est bonne mais seulement si le nombre généré est également grand - sinon vous ne lirez que la petite partie du nombre généré et cela augmentera votre risque.
Examinez les chiffres reconfigurables, plutôt que des choses comme SHA ou AES. Voici 2 articles de recherche si vous souhaitez lire et vérifier comment et pourquoi ils fonctionnent:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.6594&rep=rep1&type=pdfhttp://www.springerlink.com/index/ q29t6v1p45515186.pdf
Ou prenez n'importe quel code source de chiffrement GOST reconfigurable que vous trouvez sur le net, puis vous pouvez le nourrir avec n'importe quelle graine de base (comme un "ticker" concaténé plus un ID de nœud de serveur Web (si c'est dans une ferme Web) plus une partie de la réponse sur n'importe quel site Internet d'actualités qui modifie constamment les actualités les plus importantes ou vous pouvez l'alimenter en graine initiale hautement contrôlée (que vous pouvez créer par vous-même) et utiliser une séquence pseudo-aléatoire légère pour sélectionner d'autres configurations de chiffrement. Même NSA je ne peux pas le casser :-) Puisqu'il s'agit toujours d'un chiffre différent. À des fins de cryptographie réelles, il faut pratiquement utiliser une graine initiale très contrôlée juste pour pouvoir répliquer la séquence pour la validation. C'est là que nous revenons au premier élément - sécuriser la source et la distribution.
Solution simple si aucun matériel aléatoire supplémentaire n'est disponible.
Utilisez des millisecondes, mouseX et mouseY pour générer une graine.
CECI IS A GUESS! Crypto geeks please correct if I got it incorrect
À ce stade, l'algorithme officiel pour UUID/GUID renvoie un résultat qui est exécuté via une fonction de hachage cryptographique - il prend des informations connues, telles que l'heure, l'adr mac et un compteur pour former un UUID/GUID, puis exécute cela via un cryptographique hachage pour garantir que l'adresse mac ne peut pas être extraite.
Je pense que vous pouvez XOR cela jusqu'au nombre de bits dont vous avez besoin pour une graine avec une garantie raisonnablement bonne que la valeur résultante est également répartie sur l'espace numérique défini par le nombre de bits souhaité. Remarque Je ne prétends pas que cela est sécurisé, seulement que cette action devrait produire une valeur qui se répartit uniformément sur l'espace binaire au fil du temps.
(((PI X ID de thread actuel) X ID de processus actuel)/nombre de graduations) x pi