Generar correctamente las claves RSA + AES

Question

Generar correctamente las claves RSA + AES

#1 de Tom Leek (1 votos)

2

Para fines de aprendizaje, estoy creando una aplicación de chat donde las conexiones se realizan a través de SSL / TLS, y los mensajes se cifran utilizando AES-CBC-256 y las claves AES se cifran con RSA-2048.

La clave AES se genera aleatoriamente (AesProvider.GenerateKey ()) por usuario por sesión (lo que significa una clave para cada persona con la que un usuario está chateando) y la IV se genera aleatoriamente (AesProvider.GenerateIV ()) al pasar la clave generada, cada vez que se crea un mensaje (antes de ser enviado). En el lado de RSA, estoy generando un nombre de sesión aleatorio seguro para almacenar las claves privadas generadas en contenedores y enviar la clave pública. También estoy usando el mismo modelo (un par de claves por usuario por sesión) que en AES.

También debo indicar que estoy usando HMAC-SHA512 para hacer un hash de los mensajes y enviar la clave HMAC encriptada usando la misma clave pública con la que se encripta la clave AES / Iv. Desde que leí que no es necesario regenerarlo a menudo, planeo volver a generar la clave HMAC cada 5000 o 10000 llamadas.

Preguntas: 1) ¿Debo crear solo un par de claves RSA por usuario y usarlo para todas las sesiones, o es bueno cómo está ahora? 2) ¿Se considera seguro usar la misma clave AES y solo cambiar la IV como la explicada anteriormente?

encryption

pregunta Camilo Terevinto 06.11.2015 - 16:51

fuente

1 respuesta

Lea otras preguntas en las etiquetas encryption

Bloqueo de fuerza bruta con múltiples IP en el rango Strange Inicia sesión en Apache

score 1 · Accepted Answer

Aparentemente usa RSA para realizar un intercambio de claves: la parte A quiere tener un secreto compartido con la parte B (por ejemplo, una clave adecuada de algunos AES o HMAC); así, la parte A genera un valor aleatorio K y encripta K con la clave pública RSA de B. B utilizará su clave RSA privada para realizar el descifrado y recuperar K .

Este proceso funciona solo mientras la parte A utilice para cifrar una clave pública RSA que realmente pertenece al destinatario deseado (B). A puede recordar la clave pública de B de una interacción anterior, o puede haber un repositorio central de confianza, tal vez un repositorio "virtualizado" (de eso se tratan los certificados). En cualquier caso, debe haber algo para evitar que los atacantes presionen sus propias claves públicas RSA falsas en lugar de las auténticas. Este no es un problema fácil de resolver. Si genera nuevos pares de claves por sesión, entonces ese problema será mucho más difícil.

De todos modos, cuando usa SSL (lo cual es una buena idea), ya obtiene ese tipo de mecanismo para todas las comunicaciones de cliente a servidor. Los clientes SSL utilizan la clave pública del servidor SSL (en el certificado del servidor) para establecer un secreto compartido con ese servidor. No ves nada de esto porque está todo oculto dentro de la biblioteca SSL; pero está ahí. Si desea un cifrado adicional, debo asumir que desea un cifrado de usuario a usuario, ya que el servidor central no es de confianza. (Si solo deseaba algún cifrado entre cada cliente y el servidor, esto sería completamente redundante con el SSL).

Para el cifrado de usuario a usuario, cada usuario A debe conocer de algún modo la clave pública de todos los demás usuarios B con los que A desea hablar. La distribución de dichas claves públicas es el problema central, porque desea bloquear claves falsas, pero no confía en el servidor central para mantener el orden (si confiaba en el servidor central, simplemente dejaría que el SSL haga el trabajo). Es posible que desee investigar la noción de Web of Trust para un posible modelo para la distribución descentralizada de claves públicas.

Para el cifrado simétrico, el objetivo principal de generar un nuevo IV es, de hecho, poder reutilizar con seguridad las claves de cifrado simétrico. Siempre que genere dicha IV correctamente (el CBC requiere una IV aleatoria, uniforme e impredecible), esto debería estar bien.