¿Por qué se nos aconseja nunca implementar criptografía asimétrica a menos que seamos expertos?

Implementé un criptosistema similar a RSA en una clase de teoría de números en la universidad. Tiene razón en que es fácil de implementar de tal manera que los mensajes se pueden descifrar y un observador casual sin una computadora no puede descifrar los mensajes. Sin embargo, ¡eso no es lo mismo que un sistema seguro!

Los desafíos criptográficos de Matasano son una excelente manera de aprender sobre la criptografía moderna y cómo romper las implementaciones malas en particular. Algunas de las formas en que RSA puede romperse incluyen:

  1. Si el mismo mensaje se cifra con 3 claves diferentes con e = 3 (un parámetro común), el texto sin formato se puede derivar matemáticamente.
  2. Si no utiliza el relleno criptográfico adecuado, el atacante puede hacer cosas matemáticas interesantes en su texto cifrado para filtrar información sobre su clave o omitir los controles de integridad del mensaje.
  3. Si no verifica correctamente ese relleno, es fácil falsificar firmas digitales que su sistema verificará incorrectamente.

Además, tiene problemas para cronometrar ataques (¿Cuánto tiempo lleva descifrar este mensaje? ¿Cuánto tiempo para verificar que el relleno fue malo?), Ataques de canal lateral y otras formas creativas de usar las matemáticas y las propiedades de las computadoras para reunir pequeños fragmentos de información sobre su clave RSA cada vez que la usa.

Nunca debe intentar implementar ningún método criptográfico si tiene bibliotecas confiables disponibles.

Cualquier error que cometa resulta en una vulnerabilidad y la mayoría de las vulnerabilidades surgen de los errores que ni siquiera sabía que cometió.

Considere este simple ejemplo:

si contraseña == hash entonces bla bla

Parece muy inocente, pero puede romperse porque la operación “==” en la mayoría de los lenguajes de programación comparará las cadenas hasta que un carácter difiera y luego devuelva falso.

Esto conduce a un posible ataque de tiempo en el que el atacante puede medir el tiempo que tarda el servidor / método / lo que sea que responda y luego adivinar la contraseña, carácter por carácter.

Este pequeño ejemplo debería convencerlo de que reinventar la rueda en criptografía no solo es innecesario, sino que con frecuencia está mal, muy mal.

PD: Estoy totalmente de acuerdo con la respuesta de Daniel Miller, solo quería proporcionar este pequeño ejemplo de cómo las cosas ingenuas pueden salir mal.

Si estuviera familiarizado con solo una parte de los tipos de ataques que existen contra las implementaciones de RSA y RSA, no se le haría la pregunta que está haciendo. Pero, por supuesto, no debe implementar RSA a menos que esté familiarizado con esos ataques.

Aquí hay algunas cosas que debe preguntarle a cualquiera que implemente RSA fuera de un juguete.

  • ¿Qué pasos se están tomando para garantizar que no se usen los ataques de texto sin formato seleccionados?
  • ¿Qué pasos se toman para defenderse contra el tiempo y otros ataques de canal lateral?
  • Al generar claves privadas, ¿cuál es su fuente de aleatoriedad y cómo se utiliza?
  • Al generar claves privadas, ¿su sistema para encontrar primos se inclina hacia ciertos tipos de primos?
  • ¿Cómo se valida la entrada antes de ser entregada a cualquier operación de cifrado? ¿La entrada maliciosa puede provocar fugas de claves privadas?
  • ¿Qué sistema de relleno está utilizando y es vulnerable a los ataques?
  • ¿Qué pasos se toman para garantizar que su sistema no sea vulnerable a los ataques de mensajes relacionados?

Todo lo anterior son cosas que, si no se manejan adecuadamente, pueden conducir a la explotación de los sistemas RSA. Algunos realmente han sido explotados en la naturaleza. Esa lista no es exhaustiva.