urandom est non bloquant mais il est lent et utilise (et réutilise) l'entropie du système. Ça peut être ennuyeux de se retrouver à court d'entropie pour d'autres applications.
L'auteur du patch écrit : It seems the random number generator of libcrypto++ reads lots of bytes from /dev/urandom. I can't say that I understand how the donkey protocol works, but I doubt that's there any need for real strong encryption, and so rand() should do fine for random numbers.
En fait, urandom n'est même pas fait pour le chiffrement fort (voir la page de man). L'efficacité de /dev/random (en quantité) et /dev/urandom (en qualité) est toute relative. Le projet HLFS (Hardened Linux From Scratch) utilise d'ailleurs frandom et erandom : http://billauer.co.il/frandom.html
Est-ce que le changement baisse la sécurité ?
X917RNG est de bonne qualité couplé avec du Triple DES. Malheureusement, le problème provient toujours de l'initialisation de l'algorithme. Si on n'utilise pas de source entropique, il peut être possible de prévoir la valeur du seed et donc de casser tout le système.
[^] # Re: Pas d'entropie en trop
Posté par Jérôme Pinot (site web personnel) . En réponse à la dépêche Sortie d'aMule 2.2.1. Évalué à 5.
L'auteur du patch écrit :
It seems the random number generator of libcrypto++ reads lots of bytes from /dev/urandom. I can't say that I understand how the donkey protocol works, but I doubt that's there any need for real strong encryption, and so rand() should do fine for random numbers.
En fait, urandom n'est même pas fait pour le chiffrement fort (voir la page de man). L'efficacité de /dev/random (en quantité) et /dev/urandom (en qualité) est toute relative. Le projet HLFS (Hardened Linux From Scratch) utilise d'ailleurs frandom et erandom :
http://billauer.co.il/frandom.html
Est-ce que le changement baisse la sécurité ?
X917RNG est de bonne qualité couplé avec du Triple DES. Malheureusement, le problème provient toujours de l'initialisation de l'algorithme. Si on n'utilise pas de source entropique, il peut être possible de prévoir la valeur du seed et donc de casser tout le système.
C'est ce qui s'est passé avec Netscape que David Wagner a cassé en 1995 :
http://www.cs.berkeley.edu/~daw/my-posts/netscape-cracked-0
Ici, il semble que AutoSeededX917RNG construit un seed à partir de rand(), qui n'est pas vraiment imprévisible...
Bref, l'entropie, c'est bon, mais je crois que décidément, ça ne plait pas aux debianistes.