Le projet vient avec des outils permettant de stocker la sortie d'un générateur dans un fichier, puis d'analyser les données. Il y a des outils pour générer une image ( c'est rigolo avec des générateurs tout pourri genre celui de PHP sous Windows, http://boallen.com/random-numbers.html ), test de la distribution avec les outils ENT et DieHarder, calcul d'entropie, calcul de la période, etc.
Hasard vient avec une suite de tests unitaires. Il choisit comme un grand le meilleur générateur et la meilleure source d'entropie (pour initialiser le générateur) selon le profil demandé (vitesse ou sécurité). Hasard réutilise les générateurs existants (API Windows, /dev/urandom, OpenSSL, gcrypt, etc.)
J'avais remarqué qu'OpenSSL n'injecte pas d'entropie (RAND_add) lors d'un fork. Du coup, deux processus fils ayant le même pid vont générer les même nombres. Ça peut arriver avec un serveur web qui traite plein de requêtes, et on m'a dit sur la liste de discussion OpenSSL que bah ouais, c'est à moi de me taper le boulot d'ajouter de l'entropie. Hasard détecte un fork et réinjecte lui-même de l'entropie.
Voir le dossier doc/ pour diverses notes sur les générateurs de nombres aléatoires et python/ pour les outils.
# Bibliothèque Hasard
Posté par Victor STINNER (site web personnel) . En réponse au journal Analyser la génération de nombre aléatoire du noyau. Évalué à 10.
Salut, j'ai codé une bibliothèque de génération de nombres aléatoires : https://bitbucket.org/haypo/hasard
Le projet vient avec des outils permettant de stocker la sortie d'un générateur dans un fichier, puis d'analyser les données. Il y a des outils pour générer une image ( c'est rigolo avec des générateurs tout pourri genre celui de PHP sous Windows, http://boallen.com/random-numbers.html ), test de la distribution avec les outils ENT et DieHarder, calcul d'entropie, calcul de la période, etc.
Hasard vient avec une suite de tests unitaires. Il choisit comme un grand le meilleur générateur et la meilleure source d'entropie (pour initialiser le générateur) selon le profil demandé (vitesse ou sécurité). Hasard réutilise les générateurs existants (API Windows, /dev/urandom, OpenSSL, gcrypt, etc.)
J'avais remarqué qu'OpenSSL n'injecte pas d'entropie (RAND_add) lors d'un fork. Du coup, deux processus fils ayant le même pid vont générer les même nombres. Ça peut arriver avec un serveur web qui traite plein de requêtes, et on m'a dit sur la liste de discussion OpenSSL que bah ouais, c'est à moi de me taper le boulot d'ajouter de l'entropie. Hasard détecte un fork et réinjecte lui-même de l'entropie.
Voir le dossier doc/ pour diverses notes sur les générateurs de nombres aléatoires et python/ pour les outils.
Vieux articles que j'avais écrit.
http://www.haypocalc.com/blog/index.php/2007/12/02/97-generateurs-nombres-pseudo-aleatoires
http://www.haypocalc.com/blog/index.php/2007/12/02/96-bugs-generateurs-de-nombres-pseudo-aleatoires
http://www.haypocalc.com/blog/index.php/2008/08/18/159-attaquer-un-gnrateur-de-nombres-pseudo-alatoires
http://www.haypocalc.com/blog/index.php/2008/06/09/149-developpement-bibliotheque-hasard
Voili voulou, bonne lecture.
PS : Il faudrait que je pense à faire une release d'ailleurs…