Outils de développement · Générateur d'UUID
Comment crypto.getRandomValues transforme 16 octets aléatoires en un UUID v4
· Comment ça marche
uuide cryptographie API du navigateur
Un UUID version 4 est 16 bytes provenant d'un générateur cryptographiquement sécurisé avec six bits écrasés. Cet article parcourt les octets de l'appel Web Crypto jusqu'à la chaîne familière de 36 caractères.
L'ID dont vous avez besoin avant que le serveur ne réponde - pourquoi la génération côté client apparaît dans des formulaires hors ligne, une interface utilisateur optimiste et des importations par lots
Un formulaire hors ligne peut avoir besoin d'un identifiant avant qu'un serveur ne réponde, et une interface utilisateur optimiste peut créer plusieurs objets à la fois. Un UUIDv4 est conçu pour être généré indépendamment sans compteur central. Il ne s'agit pas d'une preuve de l'identité de l'utilisateur ni d'un secret que vous pouvez mettre en place en toute sécurité à la place de l'authentification. Si votre base de données a besoin de valeurs triées par heure de création, les ID v4 aléatoires ne sont pas classés ; il s’agit d’une décision de schéma distincte plutôt que d’une raison pour affaiblir leur caractère aléatoire.
Ce que fait réellement crypto.getRandomValues : remplir un tableau typé à partir de la source d'entropie du système d'exploitation, et non à partir d'une formule JavaScript
crypto.getRandomValues remplit un Uint8Array avec 16 bytes à partir du générateur aléatoire cryptographiquement sécurisé de la plate-forme de navigateur. Il ne dérive pas les valeurs de Date.now() ou Math.random(). Le système d'exploitation et le navigateur implémentent la source d'entropie sous-jacente, de sorte que le code JavaScript reçoit des octets plutôt que d'implémenter lui-même une formule de nombres aléatoires. ToolAcre refuse de générer un identifiant si sa source sécurisée est absente.
Écrasement de l'octet 6 et de l'octet 8 - comment le quartet de version devient 4 et les bits de variante deviennent 10xx, et pourquoi seuls six bits sont perdus
La RFC 9562 décrit un quartet de version et un champ de variante. En commençant par seize octets aléatoires, définissez les quatre bits de poids fort de l'octet 6 sur le binaire 0100 (version 4) et définissez les deux premiers bits de l'octet 8 sur 10 (la variante standard). L'implémentation utilise (byte6 & 0x0f) | 0x40 et (octet8 & 0x3f) | 0x80. Six bits sont écrasés, laissant 122 bits aléatoires selon le schéma UUIDv4. Ces bits constants ne rendent pas les octets restants moins aléatoires.
Des octets à 8-4-4-4-12 — codage hexadécimal, sortie en minuscules et placement des traits d'union tels que les définit la norme
Encodez chaque octet sous forme d'exactement deux caractères hexadécimaux avec un zéro non significatif si nécessaire. Insérez des tirets après 4, 6, 8 et 10 bytes, produisant les groupes de caractères hexadécimaux familiers 8-4-4-4-12. Une chaîne v4 valide a un 4 au début de son troisième groupe et un parmi 8, 9, a ou b au début de son quatrième. Le formatage n'ajoute pas d'entropie ; cela rend uniquement la valeur sous-jacente de 128 bits interopérable avec les outils qui attendent la forme texte UUID.
Exemple concret : un tampon de 16 octets tracé via le masquage et le formatage jusqu'à sa chaîne UUID finale
Tracez les octets illustratifs 00 11 22 33 44 55 F6 77 38 99 AA BB CC DD EE FF. Le masquage de F6 à l'octet 6 produit 46 ; le masquage 38 à l'octet 8 produit B8. Après le formatage hexadécimal minuscule et les tirets, le résultat est 00112233-4455-4677-b899-aabbccddeeff. Il s’agit d’un exemple pédagogique volontairement figé, et non d’un identifiant à réutiliser en production. Générez-en un nouveau pour chaque objet réel et comparez vous-même les positions de la version et des variantes.
crypto.randomUUID() comme raccourci d'appel unique : ce que la méthode la plus récente fait pour vous et où elle n'est pas disponible
Sur une origine sécurisée, crypto.randomUUID() effectue la génération et le formatage v4 en un seul appel. ToolAcre l'utilise lorsqu'il est disponible et revient sinon à getRandomValues avec les opérations binaires explicites ci-dessus. La disponibilité du navigateur diffère selon le contexte : randomUUID est limité aux contextes sécurisés, tandis que getRandomValues peut toujours exister sur une page LAN HTTP. Aucune des deux branches ne revient à Math.random simplement pour qu'un bouton continue de fonctionner apparemment.
Ce que cela ne couvre pas : les versions basées sur le temps (v1, v7) et basées sur le nom (v3, v5), qui nécessitent des entrées différentes de celles des octets aléatoires.
Ce mécanisme ne décrit pas les identifiants v1 ou v7 basés sur le temps, les identifiants v3/v5 basés sur le nom ou les mises en page expérimentales v8. Les UUID aléatoires ont une très faible probabilité de collision avec un caractère aléatoire sonore, et non une impossibilité mathématique absolue de collision. Un UUID v4 en lui-même ne doit pas être utilisé comme un contrôle de contrôle d'accès ou un jeton de réinitialisation de mot de passe sans tenir compte indépendamment du secret, de la durée de vie et de l'autorisation.
À retenir : le caractère aléatoire sécurisé est tout le travail – le générateur d'UUID ToolAcre s'appuie sur le même navigateur CSPRNG, donc ce que vous copiez est ce que votre code produirait
Le hasard sécurisé est le travail. Le générateur ToolAcre UUID utilise le CSPRNG du navigateur, applique les bits de version et de variante et propose une vérification de la bonne forme des valeurs copiées. Comparez un résultat généré avec l'exemple de disposition d'octets, puis utilisez la nouvelle sortie unique uniquement pour le rôle que votre application lui a réellement attribué.