Les nombres aléatoires générés par les fonctions typiques de la plupart des langages de programmation ne sont pas des nombres purement aléatoires. Ce sont des nombres pseudo-aléatoires. Comme ils ne sont pas purement aléatoires, ils peuvent être devinés avec suffisamment d'informations sur les nombres générés précédemment. Il s'agira donc d'un désastre pour la sécurité en cryptographie .
À titre d'exemple, la fonction suivante de générateur de nombres aléatoires est utilisée dans l'application glibc
ne génère pas de nombre purement aléatoire. Le numéro pseudo-aléatoire généré par ce système peut être deviné. C'est une erreur pour les questions de sécurité. Il est déjà arrivé que cela devienne désastreux. Il ne devrait pas être utilisé en cryptographie.
glibc random():
r[i] ( r[i-3] + r[i-31] ) % (2^32)
output r[i] >> 1
Ce type de générateur de nombres pseudo-aléatoires ne devrait jamais être utilisé dans des endroits sensibles sur le plan de la sécurité, même s'il est statistiquement très significatif.
Une des attaques les plus connues sur les clés pseudo-aléatoires est l'attaque sur 802.11b WEP . WEP a une clé à long terme de 104 bits, concaténée avec un IV (compteur) de 24 bits pour obtenir une clé de 128 bits, qui est à son tour appliquée à Algorithme RC4 pour générer une clé pseudo-aléatoire.
( RC4( IV + Key ) ) XOR (message)
Les clés étaient étroitement liées les unes aux autres. Ici, seule IV a augmenté de 1 à chaque étape et toutes les autres sont restées identiques. Comme ce n'était pas purement aléatoire, c'était désastreux et facilement décomposable. La clé pouvait être récupérée en analysant environ 40000 trames, ce qui est l'affaire de quelques minutes. Si le WEP utilisait un IV de 24 bits purement aléatoire, il pouvait être sûr jusqu'à environ 2^24 (près de 16,8 millions) trames.
Il est donc préférable d'utiliser un générateur de nombres aléatoires purs pour les questions de sécurité lorsque cela est possible.