Herramientas de desarrollo · Generador de UUID
Cómo crypto.getRandomValues convierte 16 bytes aleatorios en un UUID v4
· Cómo funciona
UUID criptografía apis del navegador
Un UUID versión 4 es 16 bytes de un generador criptográficamente seguro con seis bits sobrescritos. Esta publicación recorre los bytes desde la llamada Web Crypto hasta la conocida cadena de 36 caracteres.
La identificación que necesita antes de que responda el servidor: por qué la generación del lado del cliente aparece primero en formas sin conexión, interfaz de usuario optimista e importaciones por lotes
Un formulario fuera de línea puede necesitar un identificador antes de que responda un servidor, y una interfaz de usuario optimista puede crear varios objetos a la vez. Un UUIDv4 está diseñado para generarse de forma independiente sin un contador central. No es una prueba de identidad del usuario ni un secreto que pueda sustituir de forma segura la autenticación. Si su base de datos necesita valores que se ordenen por hora de creación, los ID aleatorios v4 no están ordenados; se trata de una decisión de esquema independiente y no de una razón para debilitar su aleatoriedad.
Lo que realmente hace crypto.getRandomValues: llenar una matriz escrita desde la fuente de entropía del sistema operativo, no desde una fórmula de JavaScript
crypto.getRandomValues llena un Uint8Array con 16 bytes del generador aleatorio criptográficamente seguro de la plataforma del navegador. No deriva los valores de Date.now() o Math.random(). El sistema operativo y el navegador implementan la fuente de entropía subyacente, por lo que el código JavaScript recibe bytes en lugar de implementar una fórmula de números aleatorios. ToolAcre se niega a generar un identificador si su fuente segura está ausente.
Sobrescritura de los bytes 6 y 8: cómo la versión nibble se convierte en 4 y los bits variantes se convierten en 10xx, y por qué solo se pierden seis bits
RFC 9562 describe una versión nibble y un campo variante. Comenzando con dieciséis bytes aleatorios, establezca los cuatro bits superiores del byte 6 en 0100 binario (versión 4) y establezca los dos bits superiores del byte 8 en 10 (la variante estándar). La implementación utiliza (byte6 y 0x0f) | 0x40 y (byte8 y 0x3f) | 0x80. Se sobrescriben seis bits, dejando 122 bits aleatorios según el esquema UUIDv4. Esos bits constantes no hacen que los bytes restantes sean menos aleatorios.
De bytes a 8-4-4-4-12: codificación hexadecimal, salida en minúsculas y colocación de guiones como los define el estándar
Codifique cada byte exactamente como dos caracteres hexadecimales con un cero a la izquierda cuando sea necesario. Inserte guiones después de 4, 6, 8 y 10 bytes, produciendo los familiares grupos de caracteres hexadecimales 8-4-4-4-12. Una cadena v4 válida tiene un 4 al comienzo de su tercer grupo y uno de 8, 9, aob al comienzo de su cuarto. El formateo no añade entropía; solo hace que el valor subyacente de 128 bits sea interoperable con herramientas que esperan el formato de texto UUID.
Ejemplo resuelto: un búfer de 16 bytes rastreado mediante enmascaramiento y formato hasta su cadena UUID final
Rastree los bytes ilustrativos 00 11 22 33 44 55 F6 77 38 99 AA BB CC DD EE FF. Enmascarar F6 en el byte 6 produce 46; enmascarar 38 en el byte 8 produce B8. Después del formato hexadecimal en minúsculas y guiones, el resultado es 00112233-4455-4677-b899-aabbccddeeff. Este es un ejemplo de enseñanza fijado deliberadamente, no un identificador para reutilizar en producción. Genere uno nuevo para cada objeto real y compare usted mismo la versión y las posiciones de las variantes.
crypto.randomUUID() como acceso directo de una sola llamada: qué hace el método más nuevo por usted y dónde no está disponible
En un origen seguro, crypto.randomUUID() realiza la generación v4 y el formateo en una sola llamada. ToolAcre lo usa cuando está disponible y, de lo contrario, recurre a getRandomValues con las operaciones de bits explícitas anteriores. La disponibilidad del navegador difiere según el contexto: randomUUID está restringido a contextos seguros, mientras que getRandomValues aún puede existir en una página LAN HTTP. Ninguna rama vuelve a Math.random simplemente para mantener un botón aparentemente funcionando.
Lo que esto no cubre: versiones basadas en tiempo (v1, v7) y basadas en nombres (v3, v5), que necesitan entradas diferentes a las de bytes aleatorios.
Este mecanismo no describe identificadores v1 o v7 basados en tiempo, identificadores v3/v5 basados en nombres ni diseños experimentales v8. Los UUID aleatorios tienen una probabilidad de colisión muy baja con una aleatoriedad sólida, no una imposibilidad matemática absoluta de colisión. Un UUID v4 por sí solo no debe usarse como verificación de control de acceso o token de restablecimiento de contraseña sin considerar el secreto, la vida útil y la autorización de forma independiente.
Conclusión: la aleatoriedad segura es todo el trabajo: el generador de UUID de ToolAcre extrae del mismo CSPRNG del navegador, por lo que lo que usted copia es lo que produciría su código
La aleatoriedad segura es el trabajo. El generador de UUID de ToolAcre utiliza el CSPRNG del navegador, aplica los bits de versión y variante y ofrece una verificación de buen formato de los valores copiados. Compare un resultado generado con el ejemplo de diseño de bytes y luego use el resultado nuevo y único solo para la función que su aplicación realmente le asignó.