Outils de développement · Générateur UUID
Math.random vs crypto.getRandomValues : comment fonctionne chaque générateur
· Comment ça marche
uuid cryptographie API du navigateur
Les deux renvoient des nombres qui semblent aléatoires, mais l'un est une petite machine à états déterministe et l'autre est alimenté par le système d'exploitation. Voici ce que chacun fait sous le capot et pourquoi les UUID doivent utiliser le second.
L'extrait de forum qui crée un UUID à partir de Math.random - pourquoi il a l'air bien et réussit tous les tests occasionnels
Une réponse du forum propose une usine UUID rapide en huit lignes : lancez les valeurs de Math.random et formatez-les dans la mise en page 8-4-4-4-12. Le code semble correct et réussit tous les tests occasionnels. Chaque identifiant apparaît différent et un court échantillon ne montre aucun motif visuel évident. Ce n’est pas la propriété dont un identifiant sensible à la sécurité a besoin. JavaScript spécifie Math.random comme source pseudo-aléatoire mais ne nécessite pas de résistance cryptographique à la prédiction. Ses tâches appropriées incluent les simulations, les jeux et le brassage. Dès lors qu’un identifiant peut influencer l’accès, la découverte d’un objet ou une autre décision contradictoire, l’apparence n’est plus une preuve. Le contrat documenté du générateur compte plus qu’une page de résultat plausible.
Inside Math.random — un algorithme pseudo-aléatoire prédéfini avec un état interne fixe, conçu pour la vitesse et la diffusion statistique, et non pour le secret
Étant donné que Math.random n'est pas spécifié comme générateur cryptographique, ses sorties ne doivent pas être traitées comme une preuve que les valeurs futures sont cachées à un observateur. crypto.getRandomValues a un contrat de plateforme différent : il remplit un tableau typé entier avec des valeurs cryptographiquement fortes. La spécification Web Crypto laisse le générateur exact à l'agent utilisateur, de sorte que le code d'application ne doit pas revendiquer un algorithme, une taille de graine ou un dispositif d'entropie particulier. ToolAcre n'a besoin que de la limite prise en charge : le navigateur fournit des octets aléatoires sécurisés, JavaScript reçoit le Uint8Array rempli et le code UUID définit les champs de version et de variante. Cette instruction est à la fois utile et portable sur les navigateurs dont les implémentations internes diffèrent.
Pourquoi l'observation des résultats peut révéler l'état – comment un petit état signifie qu'une série de valeurs peut permettre à quelqu'un de prédire les suivantes
Le code d'application reçoit des valeurs cryptographiquement fortes de getRandomValues plutôt que d'implémenter ou d'exposer un état JavaScript PRNG. La différence de sécurité apparaît dans les systèmes réels. Un identifiant construit à partir de Math.random ne convient pas partout où la prédiction aurait des conséquences, car un attaquant ayant la capacité de lire le réseau (ou tout système où les UUID précédents sont visibles) peut prédire le suivant. Un v4 UUID de crypto.getRandomValues n'est pas en soi un jeton d'authentification (vous avez toujours besoin d'expiration, de hachage, de limitation de débit), mais le générateur est conçu pour résister à la prédiction. ToolAcre refuse de générer un identifiant si sa source sécurisée est absente, plutôt que de revenir silencieusement à une formule prévisible. Math.random est livré avec des bugs de distribution subtils dans les principaux moteurs. Une séquence de sortie peut paraître variée sans offrir l’imprévisibilité contradictoire requise pour les rôles porteurs de secrets.
À l'intérieur de crypto.getRandomValues — le navigateur demande au CSPRNG du système d'exploitation, qui mélange l'entropie matérielle et système et est conçu pour être imprévisible.
Les algorithmes spécifiques au moteur et leur comportement statistique peuvent changer ; ni une inspection visuelle ni un test de distribution occasionnel ne font de Math.random une source cryptographique. Les calculs de collision supposent également des sorties indépendantes de l'espace indiqué. Si un générateur répète l'état, est mal amorcé ou est remplacé par un élément déterministe, cette hypothèse a échoué et la formule ne décrit plus l'implémentation. Les deux API peuvent produire des chaînes tout aussi irrégulières. Le modèle de menace les sépare : les valeurs qui doivent résister à la prédiction utilisent crypto.getRandomValues, tandis que les simulations et les mélanges non contradictoires peuvent utiliser Math.random. Le choix découle de la conséquence de la prédiction, et non de la ponctuation ou de la variété apparente d'un échantillon.
Exemple concret : générer le même nombre d'identifiants avec chaque méthode et comparer ce qu'un observateur pourrait déduire
Le générateur ToolAcre UUID utilise exclusivement crypto.getRandomValues ; il n'utilise jamais Math.random car le coût d'un UUID prévisible est toujours supérieur au coût d'un générateur légèrement plus lent. La différence cryptographique est mesurable grâce à un modèle de menace. Un attaquant qui souhaite falsifier des UUID doit soit deviner directement l'identifiant, soit casser le générateur de nombres aléatoires. La supposition directe n’est pas la comparaison quantifiée par cet article ; la conclusion étayée est que Web Crypto est destiné au hasard cryptographique alors que Math.random ne l'est pas. A CSPRNG et Math.random exposent différents contrats : le premier est conçu pour le caractère aléatoire sensible à la sécurité, tandis que le second ne comporte aucune promesse de ce type. Un système qui utilise Math.random pour les identifiants a perdu la propriété cryptographique ; la sécurité dépend désormais du maintien secret de la séquence des UUID générés. Si ne serait-ce qu’un seul UUID fuit, toute la génération future est compromise.
Bogues de distribution historiques — un rappel que les moteurs ont livré des implémentations Math.random avec une sortie visiblement inégale, décrite qualitativement
Si l'application stocke les UUID dans un journal, une base de données ou un historique de contrôle de version, la fuite est presque inévitable. La bibliothèque ToolAcre impose l'utilisation de crypto.getRandomValues et refuse de générer un UUID si le contexte sécurisé (HTTPS ou localhost) n'est pas disponible. Cette décision de conception évite le recours silencieux à Math.random qui a tourmenté de nombreuses implémentations manuelles. Dans Node.js, la bibliothèque utilise le module crypto ; dans les navigateurs, il utilise l'API Web Crypto. Les deux chemins pris en charge demandent un caractère aléatoire cryptographiquement fort à la plate-forme. L'implémentation ne fait aucune réclamation en matière de performances, car le moteur, le périphérique et la charge de travail déterminent le timing ; le contrat de sécurité est la propriété déterminante des identifiants. La raison pour laquelle la norme de l'industrie a opté pour crypto.getRandomValues est un bref historique de l'utilisation abusive de UUID. Les premiers systèmes utilisaient l'heure système, les interfaces réseau et les horloges matérielles pour générer des identifiants.
Ce que cela ne couvre pas : la qualité statistique de l'un ou l'autre générateur de simulation, ce qui est une question différente de l'imprévisibilité Les versions
basées sur le temps, les nœuds et aléatoires UUID résolvent différents problèmes d'allocation ; il ne faut pas le présenter comme une réparation linéaire pour chaque conception antérieure. Pour la version 4, la RFC 9562 définit les champs aléatoires et discute séparément du caractère impossible à deviner. Une migration hors de Math.random modifie donc la qualité des valeurs nouvellement générées sans modifier la forme textuelle UUID. Les identifiants existants restent des clés de base de données ; les régénérer briserait les références. Les nouvelles valeurs peuvent utiliser Web Crypto immédiatement, tandis que l'autorisation doit continuer à traiter chaque ancien ou nouveau UUID comme un identifiant plutôt que comme une preuve d'autorisation. Documentez le seuil afin que les intervenants en cas d'incident sachent quel générateur a produit chaque population.
À retenir : choisissez le générateur par menace, pas par apparence — le générateur ToolAcre UUID utilise exclusivement le CSPRNG, jamais Math.random()
La validation doit faire la distinction entre les anciens identifiants (non adaptés au secret) et les nouveaux identifiants (soutenus par CSPRNG). La documentation doit noter la transition. Le générateur ToolAcre produit uniquement des UUID crypto.getRandomValues ; il ne tente pas de valider ou de régénérer les identifiants à partir d’autres sources. Le générateur ToolAcre démontre les meilleures pratiques en refusant de rétrograder vers une source aléatoire plus faible. Si crypto.getRandomValues n'est pas disponible, l'outil signale une erreur au lieu d'utiliser silencieusement Math.random. Ce principe de conception s'applique à tout système critique pour la sécurité : échouer bruyamment plutôt que réussir tranquillement avec une faible garantie de sécurité. Un développeur qui voit « Échec de la génération UUID : API de chiffrement non disponible » doit résoudre le problème sous-jacent (mettre à niveau vers HTTPS, corriger le contexte sécurisé ou fournir une solution de secours appropriée). Un développeur qui reçoit silencieusement les UUID créés à partir de Math.random n'a aucune indication que le système est compromis. La bibliothèque ToolAcre donne la priorité à l'honnêteté plutôt qu'à la commodité.