Uso extraño de RSA: ¿qué tan seguro es?

Question

Uso extraño de RSA: ¿qué tan seguro es?

#1 de Lie Ryan (1 votos)
#2 de JimmyJames (0 votos)
#3 de paj28 (0 votos)

4

¿Es seguro el siguiente esquema de comunicación?

En mi opinión, utiliza el módulo RSA y el exponente de la clave pública como un secreto criptográfico, lo que es un uso extraño de RSA, pero ¿se puede romper fácilmente debido a eso?

Descripción de la comunicación proporcionada por el proveedor:

El cliente genera un nuevo par de claves RSA de 1024 bits en su máquina cada 10 horas y carga una clave pública al servidor. El cliente se autentica con una contraseña y el servidor se autentica con el certificado SSL / TLS.
Si el Servidor desea que el Cliente proporcione los datos, el Servidor genera una clave AES y la envía al Cliente cifrando el mensaje con la clave pública del Cliente mediante la biblioteca OpenSSL.
El cliente envía los datos cifrados con AES al servidor.

Problema potencial: ¿el servidor está autenticado contra el cliente en la segunda parte de la comunicación?

cryptography encryption rsa

pregunta random_crane 28.12.2015 - 14:28

fuente

3 respuestas

Lea otras preguntas en las etiquetas cryptography encryption rsa

¿Hay algún beneficio en la medición de la aleatoriedad? ¿Cómo se haría? UID firmantes que no pertenecen a una persona RL con nombre completo

score 1 · Answer 1

Por lo que puedo ver, deberían haber utilizado TLS para obtener un mejor cifrado con menos trabajo.

El uso de RSA para intercambiar la clave de sesión efímera de AES es una de las formas más comunes en que se configura TLS.

Varios problemas con este esquema personalizado:

El RSA de 2048 bits se considera el estándar mínimo para RSA en la actualidad. El RSA de 1024 bits se considera hoy en día como un atacante muy avanzado en un futuro previsible.
El cifrado AES no autentica al remitente, y agregar la autenticación a un cifrado es bastante difícil de hacer correctamente. Sugiero cambiar el paso # 3 para usar Autenticación encriptada , las bibliotecas TLS recientes son compatibles con AEAD, por ejemplo, con GCM
En el paso # 2, la clave de sesión se envía a través de la red. TLS usaría Diffie-Hellman para que el cliente y el servidor obtengan una clave de sesión simétrica sobre una comunicación no confiable canal.

score 0 · Answer 2

Problema potencial: es el servidor autenticado contra el cliente en ¿La segunda parte de la comunicación?

Si la clave pública está realmente distribuida públicamente, entonces sí, sería una forma bastante defectuosa de hacer una transmisión segura. También parece bastante débil utilizar una contraseña en el paso 1.

score 0 · Answer 3

Esta configuración es básicamente segura .

No sigue las mejores prácticas normales, pero no puedo ver una forma directa de atacar el protocolo. La clave pública RSA se mantiene privada, por lo que alguien externo no puede realizar fácilmente el paso 2.

Todavía hay un riesgo de fallas en la implementación, incluyendo:

Excesos de búfer
defectos de inyección
fallas en el manejo de contraseñas (por ejemplo, sin bloqueos)
Debilidades criptográficas (por ejemplo, aleatoriedad insuficiente)

En particular, me interesaría ver si en el paso 2 puedes enviar todos los ceros al servidor. Puede ser que cualquiera que sea la clave RSA, esto resultará en que se use una clave AES de todos los ceros. Sin embargo, esto no funcionará si están usando relleno.

Una mejor implementación sería abolir el paso 1 por completo, y en el paso 2 hacer que el servidor se autentique con un certificado de cliente. Los datos se enviarían directamente a través de esta conexión TLS sin cifrado adicional.