Herramientas de desarrollo · UUID generador
¿Cuántos bits aleatorios tiene una versión 4 UUID? 122, no 128
· Cómo funciona
uuid criptografía APIS del navegador
Seis de los 128 bits en un UUID aleatorio están fijados por el estándar, dejando 122 para la aleatoriedad. Esta publicación muestra cómo estimar honestamente las probabilidades de colisión y por qué las colisiones reales provienen de generadores averiados, no de las matemáticas.
La pregunta del arquitecto: ¿alguna vez obtendremos un duplicado? — de dónde viene la preocupación y por qué la respuesta depende del generador
El arquitecto pregunta: si generamos 10 millones de UUID por día durante diez años, ¿alguna vez obtendremos un duplicado? La respuesta honesta es: casi con seguridad que no, si el generador es criptográficamente seguro; Es casi seguro que sí, si el generador está roto. Las matemáticas del RFC 9562 son sólidas: una v4 UUID con 122 bits aleatorios tiene una probabilidad de colisión de aproximadamente n² / 2 elevado a la 123ª potencia, donde n es el número de identificadores generados. Para la mayoría de los sistemas reales, esta probabilidad es insignificante. El problema es que esta fórmula supone que todo es verdaderamente aleatorio. Si el generador tiene fugas, se repite o se sembró de manera predecible, la fórmula es incorrecta y los duplicados se vuelven inevitables. El diseño de 128 bits incluye cuatro bits de versión (0100 para v4) y dos bits de variante (10 para RFC 9562), que son fijos y establecidos por el estándar.
De qué seis bits se habla: los cuatro bits de versión y los dos bits de variante, y por qué están configurados en lugar de ser aleatorios
Eso deja 122 bits para la aleatoriedad. La formulación a veces se denomina 2 a los 122 bits aleatorios, lo que produce valores únicos. Usando la aproximación de la paradoja del cumpleaños, la probabilidad de al menos una colisión entre n valores generados aleatoriamente es aproximadamente n² / 2 elevado a 123. Para n = 1 millones, esto es (10^6)² / 2^123 = 10^12 / 9. 3 × 10^36, que es aproximadamente 10^-25. Para n = 10 mil millones, todavía se trata de 10^-16. Estos no son "efectivamente cero"; son "nunca observarás esto". La aproximación del cumpleaños brinda una forma concreta de calcular el riesgo: cuente los UUID que planea generar, eleve ese número al cuadrado, divídalo por 2 a la potencia 123. Si el generador es el crypto.getRandomValues del navegador, cada bit está respaldado por la entropía del sistema operativo. Si es Matemática.
La aproximación del cumpleaños en términos simples: la probabilidad de al menos una colisión entre n identificadores es aproximadamente n al cuadrado dividido por 2 al 123
Para un UUID producido por un generador de estados repetidos o inadecuado, el modelo matemático falla porque su supuesto de independencia es falso. Una semilla de prueba fija, un dispositivo copiado o una instantánea del proceso pueden reproducir valores aunque el texto todavía lleve la versión-4 nibble. Esos son defectos de implementación, no evidencia de que el cálculo del campo 122 haya sido incorrecto. Otra fuente mundana es copiar el mismo identificador literal en varios dispositivos y luego fusionar sus datos. Al investigar un duplicado, conserve el generador, la política de semillas, el ciclo de vida del proceso y el historial de importación. No salte de un valor repetido a una afirmación de que la salida CSPRNG independiente agotó el espacio UUID.
Ejemplo resuelto: ingresando una tasa de generación y un período de tiempo establecidos en la aproximación, con cada paso mostrado para que pueda sustituir sus propias cifras
Proceso de bifurcación sin resincronización de estado aleatorio. Un error por el que se usaba Math.random en lugar de crypto.getRandomValues. Un dispositivo de prueba que se fabricó a mano con el mismo UUID en varias filas y se utilizó accidentalmente en producción. Una versión antigua de una biblioteca UUID que tenía una limitación de rango o un error de estado. Ninguno de estos escenarios involucra las matemáticas de aproximación del cumpleaños; implican una implementación fallida o errores operativos. Calcule honestamente el riesgo de colisión para su sistema: cuente la tasa de generación UUID (por segundo, por día, por año), proyéctela durante el tiempo que funcionará el sistema e introduzca el total en la fórmula de cumpleaños. Si su sistema genera 100,000 UUID por día durante cinco años (182 millones en total), la probabilidad de colisión es (1. 82 × 10^8)² / 2^123 ≈ 3. 3 × 10^-22, que es insignificante.
De dónde provienen realmente los duplicados: semillas Math.random, máquinas virtuales clonadas, procesos bifurcados con estado copiado y copiar y pegar en accesorios
Si genera 10 millones por segundo durante un año (315 billones en total), la probabilidad es (3. 15 × 10^14)² / 2^123 ≈ 10^-10, que todavía es extremadamente pequeño. Estas estimaciones suponen que cada bit es independiente y aleatorio. El generador ToolAcre utiliza crypto.getRandomValues, que le brinda aleatoriedad respaldada por CSPRNG; la operación es la única parte en la que debe confiar. Nunca confíe en la probabilidad de colisión como excusa para saltarse las verificaciones de autorización adecuadas. Un UUID no es una contraseña, ni un token de acceso, ni un secreto, incluso si se trata de 122 bits aleatorios. La singularidad es el beneficio; la imprevisibilidad es una propiedad separada (y más importante) que impide adivinar. Las matemáticas del cumpleaños manejan la unicidad; no aborda la vida útil (¿debería caducar este UUID?), el secreto (¿es necesario aplicar un hash antes del almacenamiento?) o la autorización (¿poseer este UUID prueba algo sobre la persona que llama?). El generador ToolAcre le proporciona UUID respaldados por CSPRNG con 122 bits aleatorios, lo que significa que la unicidad matemática se mantiene y la imprevisibilidad es sólida. Todo lo demás (validación de token, caducidad, control de acceso) es responsabilidad de su aplicación. La fórmula de probabilidad asume la independencia de cada UUID generado de las generaciones anteriores. Si su sistema genera identificadores a partir de una única instancia de CSPRNG y cada llamada genera nueva aleatoriedad del sistema operativo, se cumple el supuesto de independencia. Si su sistema utiliza un estado CSPRNG en caché o un generador inicializado sin reinicialización del sistema operativo, la suposición se rompe. El riesgo de colisión aumenta drásticamente si la fuente de entropía se agota (ocurre en algunos sistemas integrados o máquinas virtuales bajo carga) o si el estado aleatorio nunca se restablece entre procesos (proceso que se bifurca sin volver a generar el CSPRNG).
Lo que esto no cubre: unicidad v1 y v7, que se basa en marcas de tiempo y secuencias de reloj en lugar de solo en la aleatoriedad
El respaldo de ToolAcre llama a crypto.getRandomValues para cada matriz de bytes y no mantiene ningún estado PRNG a nivel de aplicación. Los elementos internos de la plataforma siguen siendo responsabilidad del navegador y del sistema operativo. La simulación de colisiones con generadores reales muestra la diferencia entre la teoría y la práctica fallida. Un generador construido con Math.random a partir de la misma semilla producirá secuencias idénticas; Verá la primera colisión UUID dentro de unos pocos cientos a unos miles de valores generados, no después de los valores 2^60 (la raíz cuadrada de 2^122) como lo predice la aproximación del cumpleaños. Un generador que utiliza crypto.getRandomValues de la entropía sólida del sistema operativo producirá colisiones solo cuando la probabilidad teórica se vuelva inevitable (alrededor de 2^60 UUID), un número tan grande que nunca lo alcanzará. Un generador que utiliza una fuente de entropía débil o reutilizada (común en bibliotecas o marcos de prueba UUID mal implementados) producirá colisiones en algún punto intermedio.
Conclusión: confíe en las matemáticas, audite el generador: el generador ToolAcre utiliza el CSPRNG del navegador, que es la parte que no debe falsificarse
Una prueba por lotes puede detectar una implementación que devuelve una constante o reproduce una secuencia obvia, pero una muestra aprobada no puede demostrar la unicidad futura. Los sistemas de producción aún deberían imponer una restricción única siempre que los identificadores duplicados corrompieran los datos. Las importaciones merecen especial atención porque es posible que dos sistemas fuente válidos ya contengan el mismo identificador literal y los dispositivos se pueden copiar entre entornos. Las pruebas de ToolAcre verifican que un lote de 500 contenga 500 valores distintos; Esa es una verificación de regresión para esta implementación, no una garantía estadística. Si aparece un duplicado, conserve la evidencia e inspeccione las rutas de generación, importación, fijación y almacenamiento antes de atribuir una causa.