Je vais essayer de répondre à toutes les critiques ou questions dans les commentaires.
Effectivement, il y a globalement deux usages des générateurs de nombres pseudo-aléatoires : les simulations et la sécurité. Je ne connais pas trop les besoins en simulation, je dirai que l'algorithme doit être rapide. Tandis qu'en sécurité, on recherche un générateur le plus fidèle possible à un générateur réellement aléatoire, tant pis s'il est lent (ex: /dev/urandom vs /dev/random).
OpenSSL et libgcrypt ont d'excellents générateur pour la sécurité, mais n'utilisent pas de base commune de code. C'est dommage car un bug impactant les deux bibliothèques ne sera pas forcément corrigé dans les deux. De même niveau fonctionnalité, si on rajoute une nouvelle source d'entropie dans l'une, l'autre ne saura pas l'exploiter.
Mon idée serait donc de concentrer les efforts pour factoriser le code et donc avoir un maximum de sources d'entropie, beaucoup d'algorithme, et surtout un code bien testé. Pourquoi ne pas réutiliser GSL (ou autre) ? Je pense que le problème est qu' « on » n'a pas envie de tirer une grosse dépendance juste pour un sous-ensemble d'une bibliothèque. Maintenant si Hasard devient aussi gros qu'OpenSSL ou GSL, retour à la case départ :-) La licence BSD et un code écrit en C avec de nombreux bindings pourrait aider à l'intégration dans les autres projets.
Au sujet de ma phrase « Je pense donc récupérer les meilleurs morceaux d'OpenSSL, libgcrypt, et autres (ex: GSL) pour faire une bibliothèque dédiée. Puis en suite, propose à ces projets de réutiliser mon code. », je me suis mal exprimé. Le but est de permettre à OpenSSL d'utiliser les meilleurs bouts de libgcrypt, et inversement !
Bien sûr, il y a des problèmes de licence. J'ai contacté l'auteur de Mersenne Twister pour savoir si je peux utiliser la licence BSD et il m'a dit pas de problème. ISAAC est aussi compatible BSD (c'est dans le domaine public !). Pour RANDU, Park-Miller et drand48, je n'ai finalement réutiliser que des constantes, et je pense qu'elles sont dans le domaine public vu combien elles sont répendues.
Niveau sécurité, Hasard n'est pas prêt pour générer des clés SSH ou certificat X.509. Les algorithmes implémentés ne sont pas sûrs et le code n'est pas assez testé. J'ai implémenté les algorithmes libres trouvés sur Internet. D'autres viendront plus tard. C'était un peu une preuve de concept pour savoir si ça peut intéresser du monde. J'aimerai -si possible- réunir le meilleur des deux mondes, simulation et sécurité, pour factoriser les efforts.
[^] # Re: initialisation
Posté par Victor STINNER (site web personnel) . En réponse au journal Sortie de la bibliothèque Hasard version 0.2. Évalué à 4.
Effectivement, il y a globalement deux usages des générateurs de nombres pseudo-aléatoires : les simulations et la sécurité. Je ne connais pas trop les besoins en simulation, je dirai que l'algorithme doit être rapide. Tandis qu'en sécurité, on recherche un générateur le plus fidèle possible à un générateur réellement aléatoire, tant pis s'il est lent (ex: /dev/urandom vs /dev/random).
OpenSSL et libgcrypt ont d'excellents générateur pour la sécurité, mais n'utilisent pas de base commune de code. C'est dommage car un bug impactant les deux bibliothèques ne sera pas forcément corrigé dans les deux. De même niveau fonctionnalité, si on rajoute une nouvelle source d'entropie dans l'une, l'autre ne saura pas l'exploiter.
Mon idée serait donc de concentrer les efforts pour factoriser le code et donc avoir un maximum de sources d'entropie, beaucoup d'algorithme, et surtout un code bien testé. Pourquoi ne pas réutiliser GSL (ou autre) ? Je pense que le problème est qu' « on » n'a pas envie de tirer une grosse dépendance juste pour un sous-ensemble d'une bibliothèque. Maintenant si Hasard devient aussi gros qu'OpenSSL ou GSL, retour à la case départ :-) La licence BSD et un code écrit en C avec de nombreux bindings pourrait aider à l'intégration dans les autres projets.
Au sujet de ma phrase « Je pense donc récupérer les meilleurs morceaux d'OpenSSL, libgcrypt, et autres (ex: GSL) pour faire une bibliothèque dédiée. Puis en suite, propose à ces projets de réutiliser mon code. », je me suis mal exprimé. Le but est de permettre à OpenSSL d'utiliser les meilleurs bouts de libgcrypt, et inversement !
Bien sûr, il y a des problèmes de licence. J'ai contacté l'auteur de Mersenne Twister pour savoir si je peux utiliser la licence BSD et il m'a dit pas de problème. ISAAC est aussi compatible BSD (c'est dans le domaine public !). Pour RANDU, Park-Miller et drand48, je n'ai finalement réutiliser que des constantes, et je pense qu'elles sont dans le domaine public vu combien elles sont répendues.
Niveau sécurité, Hasard n'est pas prêt pour générer des clés SSH ou certificat X.509. Les algorithmes implémentés ne sont pas sûrs et le code n'est pas assez testé. J'ai implémenté les algorithmes libres trouvés sur Internet. D'autres viendront plus tard. C'était un peu une preuve de concept pour savoir si ça peut intéresser du monde. J'aimerai -si possible- réunir le meilleur des deux mondes, simulation et sécurité, pour factoriser les efforts.