Pour les deux variantes 1 et 2, cinq « versions » sont définies dans les normes, et chaque version peut être plus appropriée que les autres dans des cas d’utilisation spécifiques. La version est indiquée par M dans la représentation sous forme de chaîne.

Les UUID de version 1 sont générés à partir d’une heure et d’un identifiant de nœud (généralement l’adresse MAC) ; les UUID de version 2 sont générés à partir d’un identifiant (généralement un identifiant de groupe ou d’utilisateur), d’une heure et d’un identifiant de nœud ; les versions 3 et 5 produisent des UUID déterministes générés par hachage d’un identifiant; et les UUID de version 4 sont générés à l’aide d’un nombre aléatoire ou pseudo-aléatoire.

Nil UUIDEdit

L’UUID « nil », un cas particulier, est l’UUID 00000000-0000-0000-0000-000000000000 ; c’est-à-dire que tous les bits sont mis à zéro.

Version 1 (date-heure et adresse MAC)Edit

La version 1 concatène l’adresse MAC de 48 bits du « nœud » (c’est-à-dire l’ordinateur générant l’UUID), avec un horodatage de 60 bits, soit le nombre d’intervalles de 100 nanosecondes depuis le 15 octobre 1582 minuit Temps Universel Coordonné (UTC), date à laquelle le calendrier grégorien a été adopté pour la première fois. La RFC 4122 indique que la valeur temporelle tourne autour de 3400 AD,: 3 selon l’algorithme utilisé, ce qui implique que l’horodatage de 60 bits est une quantité signée. Cependant, certains logiciels, tels que la bibliothèque libuuid, traitent l’horodatage comme non signé, mettant le temps de roulement en 5236 AD. Le temps de retournement tel que défini par IT-T Rec. X.667 est 3603 après JC.:v

Une séquence d’horloge « uniquisante » de 13 ou 14 bits étend l’horodatage afin de gérer les cas où l’horloge du processeur n’avance pas assez vite, ou où il y a plusieurs processeurs et générateurs d’UUID par nœud. Lorsque les UUID sont générés plus rapidement que l’horloge système ne pourrait avancer, les bits inférieurs des champs d’horodatage peuvent être générés en l’incrémentant chaque fois qu’un UUID est généré, pour simuler un horodatage haute résolution. Chaque UUID de version 1 correspondant à un seul point dans l’espace (le nœud) et dans le temps (intervalles et séquence d’horloge), la chance que deux UUID de version 1 correctement générés soient involontairement les mêmes est pratiquement nulle. Étant donné que la séquence de temps et d’horloge totalise 74 bits, 274 (1.8×1022, ou 18 sextillions) les UUID version-1 peuvent être générés par ID de nœud, à un taux moyen maximal de 163 milliards par seconde par ID de nœud.

Contrairement aux autres versions d’UUID, les UUID version-1 et -2 basés sur des adresses MAC de cartes réseau reposent pour leur unicité en partie sur un identifiant délivré par une autorité centrale d’enregistrement, à savoir la partie Identifiant Unique Organisationnel (OUI) de l’adresse MAC, qui est délivrée par l’IEEE aux fabricants d’équipements réseau. L’unicité des UUID version-1 et version-2 basés sur des adresses MAC de carte réseau dépend également du fait que les fabricants de cartes réseau attribuent correctement des adresses MAC uniques à leurs cartes, ce qui, comme d’autres processus de fabrication, est sujet à des erreurs.

L’utilisation de l’adresse MAC de la carte réseau du nœud pour l’ID du nœud signifie qu’un UUID de version 1 peut être suivi jusqu’à l’ordinateur qui l’a créé. Les documents peuvent parfois être retracés jusqu’aux ordinateurs sur lesquels ils ont été créés ou édités grâce à des UUID intégrés par un logiciel de traitement de texte. Ce trou d’intimité a été utilisé pour localiser le créateur du virus Melissa.

La RFC 4122 permet de remplacer l’adresse MAC d’un UUID de version 1 (ou 2) par un ID de nœud aléatoire de 48 bits, soit parce que le nœud n’a pas d’adresse MAC, soit parce qu’il n’est pas souhaitable de l’exposer. Dans ce cas, la RFC exige que le bit le moins significatif du premier octet de l’ID de nœud soit défini sur 1. Cela correspond au bit de multidiffusion dans les adresses MAC, et sa définition sert à différencier les UUID où l’ID de nœud est généré aléatoirement à partir d’UUID en fonction des adresses MAC des cartes réseau, qui ont généralement des adresses MAC unicast.

Version 2 (date-heure et adresse MAC, version de sécurité DCE)Edit

La RFC 4122 réserve la version 2 aux UUID « DCE security » ; mais elle ne fournit aucun détail. Pour cette raison, de nombreuses implémentations UUID omettent la version 2. Cependant, la spécification des UUID de la version 2 est fournie par la spécification des Services d’authentification et de sécurité DCE 1.1.

Les UUID Version-2 sont similaires à la version 1, sauf que les 8 bits les moins significatifs de la séquence d’horloge sont remplacés par un numéro de « domaine local », et les 32 bits les moins significatifs de l’horodatage sont remplacés par un identifiant entier significatif dans le domaine local spécifié. Sur les systèmes POSIX, les numéros de domaine local 0 et 1 correspondent respectivement aux ID utilisateur (UID) et aux ID de groupe (GID), et les autres numéros de domaine local sont définis sur site. Sur les systèmes non POSIX, tous les numéros de domaine locaux sont définis par site.

La possibilité d’inclure un domaine/identifiant 40 bits dans l’UUID s’accompagne d’un compromis. D’une part, 40 bits permettent environ 1 billion de valeurs de domaine /identifiant par ID de nœud. En revanche, avec la valeur d’horloge tronquée aux 28 bits de poids fort, contre 60 bits dans la version 1, l’horloge d’un UUID de version 2 ne  » tiquera  » qu’une fois toutes les 429,49 secondes, soit un peu plus de 7 minutes, contre toutes les 100 nanosecondes pour la version 1. Et avec une séquence d’horloge de seulement 6 bits, contre 14 bits dans la version 1, seuls 64 UUID uniques par nœud/domaine /identifiant peuvent être générés par tick d’horloge de 7 minutes, contre 16 384 valeurs de séquence d’horloge pour la version 1. Ainsi, la version 2 peut ne pas convenir aux cas où des UUID sont nécessaires, par nœud/domaine/identifiant, à un rythme supérieur à environ un toutes les sept secondes.

Les UUID des versions 3 et 5 (basées sur le nom de l’espace de noms)

Les UUID des versions 3 et 5 sont générés en hachant un identifiant et un nom d’espace de noms. La version 3 utilise MD5 comme algorithme de hachage et la version 5 utilise SHA-1.

L’identifiant de l’espace de noms est lui-même un UUID. La spécification fournit des UUID pour représenter les espaces de noms pour les URL, les noms de domaine complets, les identifiants d’objets et les noms distingués X.500 ; mais tout UUID souhaité peut être utilisé comme désignateur d’espace de noms.

Pour déterminer l’UUID de version 3 correspondant à un espace de noms et un nom donnés, l’UUID de l’espace de noms est transformé en une chaîne d’octets, concaténée avec le nom d’entrée, puis hachée avec MD5, ce qui donne 128 bits. Ensuite, 6 ou 7 bits sont remplacés par des valeurs fixes, la version 4 bits (par ex. 00112 pour la version 3), et la  » variante » UUID 2 ou 3 bits (par exemple, 102 indiquant un UUID RFC 4122, ou 1102 indiquant un GUID Microsoft hérité). Comme 6 ou 7 bits sont ainsi prédéterminés, seuls 121 ou 122 bits contribuent à l’unicité de l’UUID.

Les UUID Version-5 sont similaires, mais SHA-1 est utilisé à la place de MD5. Puisque SHA-1 génère des résumés de 160 bits, le résumé est tronqué à 128 bits avant que les bits de version et de variante ne soient remplacés.

Les UUID Version-3 et version-5 ont la propriété que le même espace de noms et le même nom seront mappés sur le même UUID. Cependant, ni l’espace de noms ni le nom ne peuvent être déterminés à partir de l’UUID, même si l’un d’eux est spécifié, sauf par recherche par force brute. La RFC 4122 recommande la version 5 (SHA-1) par rapport à la version 3 (MD5) et met en garde contre l’utilisation d’UUID de l’une ou l’autre version comme informations d’identification de sécurité.

Édition de la version 4 (aléatoire)

Un UUID de la version 4 est généré aléatoirement. Comme dans les autres UUID, 4 bits sont utilisés pour indiquer la version 4, et 2 ou 3 bits pour indiquer la variante (102 ou 1102 pour les variantes 1 et 2 respectivement). Ainsi, pour la variante 1 (c’est-à-dire la plupart des UUID), un UUID de version-4 aléatoire aura 6 bits de variante et de version prédéterminés, laissant 122 bits pour la partie générée aléatoirement, pour un total de 2122, soit 5,3×1036 (5,3 undecillion) UUID de version-4 variant-1 possible. Il y a deux fois moins d’UUID version-4 variant-2 possibles (GUID hérités) car il y a un bit aléatoire de moins disponible, 3 bits étant consommés pour la variante.