it-swarm-es.com

¿Cuánto tiempo debe ser un nonce aleatorio?

NIST proporciona buenas pautas sobre la longitud de las claves y hashes para varios algoritmos . Pero no veo nada específicamente sobre la longitud de un aleatorio o pseudoaleatorio nonce (número usado una vez).

Si hay una sola buena respuesta para una variedad de usos, me encantaría verla. Pero para hacer esto concreto, usaré la situación común de "restablecimiento de contraseña por correo electrónico", en la que el servidor genera una URL con un componente de ruta pseudoaleatoria. Parece un poco similar a HTTP Digest Authentication, en el que ejemplo en el RFC parece tener 136 bits (dcd98b7102dd2f0e8b11d0f600bfb0c093).

Observo que muchas personas parecen usar UUID de versión 4 (que proporcionan 122 bits pseudoaleatorios) o esto, como se discute en ¿Son seguros los GUID para tokens únicos? , aunque el usuario debe tener cuidado con el uso de versiones previas de UUID mucho más predecibles, y desagradables ataques locales persistentes en el generador de números aleatorios de Windows que fueron principalmente parcheado para 2008.

Pero ignorando el riesgo de enredarse en versiones e implementaciones de UUID, ¿cuántos bits pseudoaleatorios deben incorporarse en la URL?

35
nealmcb

Un nonce de 64 bits es probablemente más que suficiente para la mayoría de los propósitos prácticos, si los 64 bits son aleatorias de calidad criptográfica.

¿Por qué son suficientes 64 bits? Permítanme presentar el tipo de razonamiento que puede usar para responder esta pregunta. Asumiré que esta es una URL de tiempo limitado de un solo uso; después de usarlo una vez, ya no es válido, y después de un tiempo (3 días, por ejemplo), caduca y ya no es válido. Dado que el nonce solo es significativo para el servidor, la única forma en que un atacante puede intentar una suposición es enviar la suposición de 64 bits al servidor y ver cómo responde el servidor. ¿Cuántas conjeturas puede intentar el atacante antes de que expire el nonce? Digamos que el atacante puede realizar 1000 solicitudes HTTP por segundo (es un atacante bastante fornido); entonces el atacante puede hacer aproximadamente 1000 * 3600 * 24 * 3 = 228 conjeturas dentro de un período de 3 días. Cada suposición tiene un 1/264 posibilidad de estar en lo cierto. Por lo tanto, el atacante tiene como máximo un 1/236 posibilidad de romper el esquema. Eso debería ser más que seguro para la mayoría de las configuraciones.

23
D.W.

Primero, calcule la cantidad máxima de usos que obtendrá su sistema (la cantidad de veces que se generará un nonce aleatorio). Luego, decida sobre un nivel de seguridad aceptable, es decir, cuán improbable debe ser que un nonce sea un duplicado de uno antiguo. Calcule la cantidad de usos en bits, duplíquelo y agregue la improbabilidad que necesita en bits y tendrá su longitud nonce.

Un ejemplo de AES-GCM con IV aleatorio. El número de invocaciones permitidas con IV aleatorio para una determinada clave es 232. La probabilidad de que se reutilice un IV debe ser inferior a 2-32. La longitud de nonce requerida para esto es 32 × 2 + 32 == 96 bits.

Si, hipotéticamente, quisieras poder generar 296 paquetes, cada uno con un nonce aleatorio y desearía que la probabilidad de un nonce duplicado sea inferior a 2-32, necesitaría un nonce de 96 × 2 + 32 == 224 bits de longitud.

Comparando esto con la respuesta anterior de 64 bits ... si tiene más de 2dieciséis (65536) usos de su sistema, la probabilidad de tener un nonce duplicado en ese tiempo es más de 2-32 (más de 1 en 4 mil millones, escala corta). Esto podría ser bastante aceptable, dependiendo de sus requisitos de seguridad, o podría no serlo.

Como una respuesta única para todos: los UUID aleatorios mencionados son una solución bastante buena.

Tenga en cuenta que estos valores son aproximaciones, y los cálculos más precisos son mucho más complejos.

7
Nakedible