¿Qué cifrado de clave privada debo usar para la comunicación de servidor a servidor?

2

Tengo la tentación de escribir la mía que cubre:

  • Suma de comprobación para garantizar que los datos no se manipulen.
  • Teclas rotativas largas y múltiples para que sea (prácticamente) imposible de descifrar.
  • Utilizará /dev/random para la semilla inicial

Otros elementos más esquivos que probablemente no se abordarán:

  • Según el tamaño de los fragmentos de datos y el patrón de conexión, un interceptor puede adivinar cosas sobre los datos sin verlos; Qué protocolo, cómo se está utilizando.
  • Las direcciones IP de origen y destino dan una pista de identidad.
  • Los encabezados TCP e IP pueden contener información del sistema operativo.

Aunque tengo mucha confianza, existe el riesgo de que falte algo que quizás nunca me dé cuenta: Lecciones aprendidas y conceptos erróneos sobre el cifrado y la criptología

Entonces, ¿qué usaría si tuviera que evitar escribir el mío? Los factores importantes son

  • velocidad
  • Checksum
  • Me gustaría saber cuánta información se necesita antes de que la clave se agote y se vaya a reutilizar.

¿O escribir mi propio cifrado es una buena idea en este caso?

    
pregunta George Bailey 11.07.2011 - 18:01
fuente

2 respuestas

4
  

escribir mi propio cifrado es una buena idea en este caso?

No. Aproveche el conocimiento, la experiencia y el trabajo de los profesionales que han pasado décadas diseñando algoritmos de cifrado.

  

imposible de descifrar.

Cualquier cifrado se puede descodificar simplemente probando cada clave posible con un algoritmo y verificando si la salida tiene sentido. Por lo general, nos referimos a la cantidad de trabajo que se espera que realice un atacante antes de descifrar un mensaje.

Un algoritmo se considera seguro contra una cierta clase de atacante cuando se estima que no se puede esperar que el atacante descifre el mensaje dentro de un período de tiempo relevante .

Si está protegiendo contra una sola persona con una pequeña cantidad de equipo minorista, el factor de trabajo esperado es pequeño. Si está protegiendo contra los recursos informáticos de un país industrializado, el factor de trabajo esperado es enorme.

  

Velocidad

La velocidad depende del tamaño de la clave. Varios algoritmos modernos soportan múltiples tamaños de clave. Basado en Evaluación del rendimiento de los algoritmos de cifrado simétrico parece que Blowfish es rápido, pero Blowfish no ha sido tan bien investigado como AES.

  

asegúrese de que los datos no se manipulen.

     

Checksum

Las sumas de comprobación, los hashes y los códigos de autenticación de mensajes (MAC) no se relacionan necesariamente con el algoritmo de cifrado que elija. Sin embargo, algunos algoritmos tienen modos que realizan el cifrado y la autenticación. Galois / Modo de contador es un modo de este tipo que se utiliza en un número o estándares. AES-GCM es un ejemplo de un algoritmo que proporciona cifrado y autenticación.

  

la cantidad de datos que se necesitan antes de que la clave se agote y se reutilice.

Como @ Thomas-Pornin dijo que esto no es aplicable a los algoritmos de encriptación modernos. La práctica común es usar datos aleatorios para generar claves, y los datos aleatorios realmente no se agotan. Puede estar refiriéndose a la cuestión de no repetir un vector de Inicialización (IV, también conocido como Nonce), pero no estoy seguro.

  

Según el tamaño de los datos y el patrón de conexión, un interceptor puede adivinar cosas sobre los datos sin verlos; Qué protocolo, cómo se está utilizando.

Sí, estos se conocen generalmente como ataques de canal lateral. Hay medidas que puede tomar para mitigar algunos ataques de canal lateral y, en su mayoría, implican proteger la transmisión.

  

Las direcciones IP de origen y destino dan una pista de identidad.

Sí, pero intentar ocultar tu presencia es probablemente más esfuerzo de lo que vale la pena.

  

Los encabezados TCP e IP pueden contener información del sistema operativo.

Los paquetes de red pueden ayudar a un atacante a tomar las huellas dactilares de su sistema, pero creo que es más valioso centrarse en la seguridad del buen funcionamiento, especialmente en las políticas y procedimientos que afectan su seguridad.

  

Entonces, ¿qué usaría si tuviera que evitar escribir el mío?

Para responder a esto, debemos modelar el factor de trabajo de la clase de atacante esperada, la latencia y el rendimiento deseados y los recursos informáticos disponibles. Sin embargo, mi conjetura es que algún modo de AES es adecuado para usted.

    
respondido por el this.josh 11.07.2011 - 22:58
fuente
7

Escribir tu propio cifrado es nunca una buena idea. Incluso los criptógrafos entrenados (me refiero a personas que han estudiado el tema durante años, tienen un gran diploma brillante [un doctorado] para decirlo y, lo que es más importante, han hecho y publicado investigaciones reales) no piensan en utilizar un algoritmo o protocolo que hayan diseñado antes de enviarlo a sus colegas para que lo inspeccionen durante varios años.

En el más anecdótico:

  • "Checksum" es un término grande; los criptógrafos prefieren el Código de autenticación de mensajes , que es mucho más preciso.
  • "Teclas giratorias largas y múltiples": esto suena como una novela de Dan Brown y, por lo que respecta a la seguridad, no es una cosa no buena.
  • No use /dev/random , use /dev/urandom .
  • "Cuántos datos se necesitan antes de que la clave se agote y se reutilice": esta frase tiene sentido solo si se considera el tipo de sistemas de cifrado que se utilizaron durante la Primera Guerra Mundial, es decir, antes de la invención de la computadora.

No conozco ninguna forma amable de afirmar esto: te sientes confiado, pero realmente no deberías.

Utilice TLS (el nuevo nombre estándar para SSL).

    
respondido por el Thomas Pornin 11.07.2011 - 18:19
fuente

Lea otras preguntas en las etiquetas