Jason A Donenfeld, auteur de VPN WireGuard dévoilé il y a quelques jours une nouvelle implémentation mis à jour à partir d'un générateur de nombres aléatoires RDRAND, qui est responsable du fonctionnement des périphériques /dev/random et /dev/urandom dans le noyau Linux.
Fin novembre, Jason a été inclus dans la liste des mainteneurs du contrôleur aléatoire et vient de publier les premiers résultats de son travail de refonte.
Il est mentionné dans l'annonce que la nouvelle implémentation se distingue par le passage à l'utilisation de la fonction de hachage BLAKE2s au lieu de SHA1 pour les opérations de mélange entropique.
BLAKE2s lui-même a la belle propriété d'être basé en interne sur le
Permutation ChaCha, que le RNG utilise déjà pour l'expansion, donc
il ne devrait y avoir aucun problème avec la nouveauté, l'originalité ou un processeur incroyable
comportement car il est basé sur quelque chose qui est déjà utilisé.
En plus de cela, il est souligné que le changement a également amélioré la sécurité du générateur de nombres pseudo-aléatoires en se débarrassant de l'algorithme SHA1 gênant et en évitant d'écraser le vecteur d'initialisation RNG. Étant donné que l'algorithme BLAKE2s est en avance sur SHA1 en termes de performances, son utilisation a également eu un effet positif sur les performances du générateur de nombres pseudo-aléatoires (des tests sur un système avec un processeur Intel i7-11850H ont montré une augmentation de 131% de la vitesse).
Un autre avantage qui ressort est celui de transférer le mélange d'entropie vers BLAKE2 est l'unification des algorithmes utilisés : BLAKE2 est utilisé dans le cryptage ChaCha, qui est déjà utilisé pour extraire des séquences aléatoires.
BLAKE2s est généralement plus rapide et certainement plus sécurisé, ça a été vraiment très cassé. En plus, le La version actuelle du RNG n'utilise pas la fonction SHA1 complète, car spécifie, et permet d'écraser l'IV avec la sortie RDRAND donc non documenté, même si RDRAND n'est pas défini comme « de confiance », il qui représente les options IV malveillantes possibles.
Et sa courte longueur signifie pour ne garder qu'un demi-secret lors du retour au mélangeur nous donne seulement 2 ^ 80 bits de secret de transmission. En d'autres termes, non seulement le choix de la fonction de hachage est obsolète mais son utilisation n'est pas vraiment bonne non plus.
De plus, des améliorations ont été apportées au générateur de nombres pseudo-aléatoires crypto-sécurisés CRNG utilisé dans l'appel getrandom.
Il est également mentionné que les améliorations sont réduites à la limitation de l'appel au générateur RDRAND lente lors de l'extraction de l'entropie, ce qui Il peut améliorer les performances d'un facteur de 3,7. Jason a démontré que l'appel à RDRAND Cela n'a de sens que dans une situation où CRNG n'a pas encore été complètement initialisé, mais si l'initialisation de CRNG est terminée, sa valeur n'affecte pas la qualité du flux généré et dans ce cas il est possible de le faire sans appeler RDRAND.
Cet engagement vise à résoudre ces deux problèmes et, en même temps, à maintenir la structure générale et sémantique aussi proches que possible de l'original.
Spécifiquement:a) Au lieu d'écraser le hachage IV avec RDRAND, il nous avons mis dans les champs "sel" et "personnel" documentés de BLAKE2, qui sont créé spécifiquement pour ce type d'utilisation.
b) Étant donné que cette fonction renvoie le résultat du hachage complet au collecteur d'entropie, on ne retourne que la moitié de la longueur du hachage, comme c'était le cas avant. Cela augmente le avance de construction secret de 2^80 a 2 ^ 128 beaucoup plus confortable.
c) Au lieu d'utiliser simplement la fonction brute "sha1_transform", à la place, nous utilisons la fonction BLAKE2s complète et appropriée, avec la complétion.
Des modifications sont prévues pour être incluses dans le noyau 5.17 et ont déjà été revus par les développeurs Ted Ts'o (le deuxième responsable de la maintenance du contrôleur aléatoire), Greg Kroah-Hartman (responsable de la stabilité du noyau Linux) et Jean-Philippe Aumasson (auteur des algorithmes BLAKE2/3).
Enfin, si vous souhaitez en savoir plus, vous pouvez consulter les détails dans la lien suivant