¿Cuáles son los problemas de usar el cifrado OTP con TRNG?

3

He programado un simple "cifrado" de One-Time Pad que puede combinar dos archivos en uno utilizando XOR a nivel de bits.

Los archivos de claves pseudoaleatorias se generan mediante el uso de > CryptGenRandom() de la biblioteca CryptoAPI de Microsoft. Ahora me pregunto si codificar o no los complementos para los generadores comerciales de números aleatorios reales.

Mi pregunta es: ¿cuáles son los problemas prácticos al implementar OTP con TRNG, aparte de requerir que los usuarios tengan el hardware especial en primer lugar?

    
pregunta Log 30.12.2015 - 13:59
fuente

1 respuesta

4

Primero, vamos a aclarar algunos términos. Para llamar a algo un teclado de una sola vez , la clave debe ser verdaderamente aleatoria . Así que con eso en mente:

Casi hiciste dos preguntas separadas:

  1. Estoy usando CryptGenRandom () para generar mi clave. ¿Es esto suficientemente bueno o debo considerar usar un TRNG?

  2. Si uso un TRNG, ¿qué problemas prácticos hay, si los hay, al implementar OTP con TRNG?

Para la pregunta 1, según tengo entendido, la única forma en que alguien haya logrado un craqueo (es decir, ha vuelto a generar la semilla adecuada) para CryptGenRandom () es accediendo a la máquina original donde se creó la clave. Y eso fue usar una falla en Windows 2000 que es una tecnología de 15 años. Entonces, basado en eso (combinado con personas inteligentes en MS que dicen que es criptográficamente segura), diría que sí, CryptGenRandom () debería ser lo suficientemente bueno como para ser usado para la generación de claves.

Dicho esto, algunos cifrados de bits altos también deberían ser lo suficientemente buenos, y si alguien está pensando en utilizar OTP en lugar de algún otro método de cifrado, es probable que estén paranoicos hasta el punto de que sean lo suficientemente buenos no va a cortarlo En otras palabras, si va a implementar algo que realmente puede llamar OTP, debe ser absolutamente imposible romper su implementación sin la clave, que no puede lograr a menos que use un TRNG. / p>

En cuanto a la pregunta 2, IMHO, no hay problemas prácticos con el uso de un TRNG. La razón es que solo 1 parte de confianza involucrada en la comunicación necesita tener el TRNG, no todos. El problema más difícil es la distribución de claves, no la generación de claves. La parte con el TRNG (dispositivo USB o algún otro artilugio) podría generar un gran conjunto de datos aleatorios y luego distribuir los datos a todas las partes involucradas. Cada parte al enviar una comunicación simplemente deberá especificar el desplazamiento en los datos aleatorios donde comienza su clave. Cuando se usa el conjunto de datos aleatorios, se puede generar un nuevo conjunto de datos.

Sin embargo, el hecho de que alguien involucrado en cada comunicación tenga que obtener inicialmente un dispositivo de hardware para poder crear la clave puede considerarse un "problema", según cómo se mire. Esto podría tener un efecto en su "argumento de venta", por así decirlo, ya que no apelará para impulsar a los usuarios que desean enviar un mensaje con cifrado inquebrantable ahora mismo ; todos los usuarios nuevos deberán esperar un poco de tiempo para obtener el dispositivo TRNG. Podría considerar usar un servicio como www.random.org , pero si lo hace, puede que a sus usuarios ultra paranoicos no les guste la ¡El hecho de que la clave se está descargando a través de SSL miserable!

TLDR; Independientemente de si utiliza CryptGenRandom () o un TRNG, la parte difícil no está realmente en la generación de claves, sino en la distribución de las claves a cada parte para que puedan descifrar el mensaje.

    
respondido por el TTT 30.12.2015 - 22:30
fuente

Lea otras preguntas en las etiquetas