Herramientas de desarrollo · UUID generador
Math.random vs crypto.getRandomValues: cómo funciona cada generador
· Cómo funciona
uuid criptografía APIS del navegador
Ambos devuelven números que parecen aleatorios, pero uno es una pequeña máquina de estado determinista y el otro es alimentado por el sistema operativo. Esto es lo que cada uno hace bajo el capó y por qué los UUID deben usar el segundo.
El fragmento del foro que crea un UUID de Math.random: por qué se ve bien y pasa todas las pruebas casuales
Una respuesta del foro ofrece una fábrica UUID rápida en ocho líneas: extraiga valores de Math.random y formatéelos en el diseño 8-4-4-4-12. El código se ve bien y pasa todas las pruebas casuales. Cada identificador parece diferente y una muestra breve no muestra ningún patrón visual obvio. Esa no es la propiedad que necesita un identificador sensible a la seguridad. JavaScript especifica Math.random como fuente pseudoaleatoria pero no requiere resistencia criptográfica a la predicción. Sus trabajos apropiados incluyen simulaciones, juegos y barajado. Una vez que un identificador puede influir en el acceso, el descubrimiento de objetos u otra decisión adversa, la apariencia ya no es evidencia. El contrato documentado del generador importa más que una página de resultados aparentemente plausibles.
Inside Math.random: un algoritmo pseudoaleatorio con un estado interno fijo, diseñado para velocidad y difusión estadística, no secreto
Debido a que Math.random no se especifica como un generador criptográfico, sus resultados no deben tratarse como evidencia de que los valores futuros están ocultos para un observador. crypto.getRandomValues tiene un contrato de plataforma diferente: llena una matriz escrita con números enteros con valores criptográficamente fuertes. La especificación Web Crypto deja el generador exacto al agente de usuario, por lo que el código de la aplicación no debe reclamar un algoritmo, tamaño de semilla o dispositivo de entropía en particular. ToolAcre solo necesita el límite admitido: el navegador proporciona bytes aleatorios seguros, JavaScript recibe el Uint8Array completo y el código UUID establece los campos de versión y variante. Esa afirmación es útil y portátil en todos los navegadores cuyas implementaciones internas difieren.
Por qué observar los resultados puede revelar el estado: cómo un estado pequeño significa que una serie de valores puede permitir que alguien prediga los siguientes
El código de la aplicación recibe valores criptográficamente fuertes de getRandomValues en lugar de implementar o exponer un estado PRNG de JavaScript. La diferencia de seguridad aparece en los sistemas reales. Un identificador creado a partir de Math.random no es adecuado siempre que la predicción tenga consecuencias porque un atacante con la capacidad de leer la red (o cualquier sistema donde los UUID anteriores sean visibles) puede predecir el siguiente. Una versión 4 UUID de crypto.getRandomValues no es en sí misma un token de autenticación (aún necesita caducidad, hash y limitación de velocidad), pero el generador está diseñado para resistir la predicción. ToolAcre se niega a generar un identificador si su fuente segura está ausente, en lugar de degradarse silenciosamente a una fórmula predecible. Math.random se envía con sutiles errores de distribución en los principales motores. Una secuencia de salida puede parecer variada sin proporcionar la imprevisibilidad adversaria necesaria para los roles que guardan secretos.
Dentro de crypto.getRandomValues: el navegador solicita el CSPRNG del sistema operativo, que combina hardware y entropía del sistema y está diseñado para ser impredecible.
Los algoritmos específicos del motor y su comportamiento estadístico pueden cambiar; ni la inspección visual ni una prueba de distribución informal convierten Math.random en una fuente criptográfica. Los cálculos de colisión también suponen salidas independientes del espacio indicado. Si un generador repite el estado, se inicializa incorrectamente o se reemplaza con un dispositivo determinista, esa suposición falla y la fórmula ya no describe la implementación. Ambas API pueden producir cadenas que parecen igualmente irregulares. El modelo de amenaza los separa: los valores que deben resistir la predicción usan crypto.getRandomValues, mientras que las simulaciones y las mezclas no adversarias pueden usar Math.random. La elección se deriva de la consecuencia de la predicción, no de la puntuación o la variedad aparente en una muestra.
Ejemplo resuelto: generar la misma cantidad de identificadores con cada método y comparar lo que un observador podría inferir
El generador ToolAcre UUID utiliza crypto.getRandomValues exclusivamente; nunca usa Math.random porque el costo de un UUID predecible siempre es mayor que el costo de un generador ligeramente más lento. La diferencia criptográfica se puede medir mediante un modelo de amenaza. Un atacante que quiera falsificar UUID debe adivinar el identificador directamente o romper el generador de números aleatorios. La conjetura directa no es la comparación que cuantifica este artículo; la conclusión respaldada es que Web Crypto está destinado a la aleatoriedad criptográfica, mientras que Math.random no. Un CSPRNG y Math.random exponen contratos diferentes: el primero está diseñado para aleatoriedad sensible a la seguridad, mientras que el segundo no promete tal promesa. Un sistema que utiliza Math.random para identificadores ha perdido la propiedad criptográfica; la seguridad ahora depende de mantener en secreto la secuencia de UUID generados. Si se filtra incluso una UUID, toda la generación futura se verá comprometida.
Errores de distribución históricos: un recordatorio de que los motores han enviado implementaciones de Math.random con resultados visiblemente desiguales, descritos cualitativamente
Si la aplicación almacena UUID en un registro, una base de datos o un historial de control de versiones, la filtración es casi inevitable. La biblioteca ToolAcre impone el uso de crypto.getRandomValues y se niega a generar un UUID si el contexto seguro (HTTPS o localhost) no está disponible. Esta decisión de diseño evita el retroceso silencioso a Math.random que afectó a muchas implementaciones hechas a mano. En Node.js, la biblioteca utiliza el módulo criptográfico; en los navegadores, utiliza la API Web Crypto. Ambas rutas admitidas solicitan una aleatoriedad criptográficamente fuerte de la plataforma. La implementación no hace ninguna afirmación sobre el rendimiento porque el motor, el dispositivo y la carga de trabajo determinan el tiempo; el contrato de seguridad es la propiedad decisiva para los identificadores. Por qué el estándar de la industria se decidió por crypto.getRandomValues es una breve historia de uso indebido de UUID. Los primeros sistemas utilizaban la hora del sistema, las interfaces de red y los relojes de hardware para generar identificadores.
Lo que esto no cubre: la calidad estadística de cualquiera de los generadores para simulaciones, que es una cuestión diferente a la imprevisibilidad.
Las versiones UUID basadas en tiempo, basadas en nodos y aleatorias resuelven diferentes problemas de asignación; uno no debe presentarse como una reparación lineal para cada diseño anterior. Para la versión 4, RFC 9562 define campos aleatorios y analiza por separado la imposibilidad de adivinar. Por lo tanto, una migración fuera de Math.random cambia la calidad de los valores recién generados sin cambiar la forma textual UUID. Los identificadores existentes siguen siendo claves de la base de datos; regenerarlos rompería las referencias. Los nuevos valores pueden usar Web Crypto inmediatamente, mientras que la autorización debe continuar tratando cada UUID antiguo o nuevo como un identificador en lugar de una prueba de permiso. Documente el límite para que los socorristas sepan qué generador produjo cada población.
Conclusión: elija el generador por amenaza, no por apariencia: el generador ToolAcre UUID usa CSPRNG exclusivamente, nunca Math.random()
La validación debe distinguir entre identificaciones heredadas (no aptas para el secreto) y nuevas (respaldadas por CSPRNG). La documentación debe indicar la transición. El generador ToolAcre solo produce UUID crypto.getRandomValues; no intenta validar ni regenerar identificadores de otras fuentes. El generador ToolAcre demuestra las mejores prácticas al negarse a degradar a una fuente aleatoria más débil. Si crypto.getRandomValues no está disponible, la herramienta informa un error en lugar de utilizar Math.random de forma silenciosa. Este principio de diseño se aplica a cualquier sistema crítico para la seguridad: fallar estrepitosamente en lugar de tener éxito silenciosamente con una garantía de seguridad débil. Un desarrollador que vea "Error en la generación UUID: API criptográfica no disponible" debe abordar el problema subyacente (actualizar a HTTPS, corregir el contexto seguro o proporcionar una alternativa adecuada). Un desarrollador que recibe silenciosamente UUID creados a partir de Math.random no tiene indicios de que el sistema esté comprometido. La biblioteca ToolAcre prioriza la honestidad sobre la conveniencia.