¿Qué debo intercambiar con el servidor cuando genero mi clave AES 256?

4

Estoy creando un juego móvil de ritmo rápido y actualmente estoy trabajando para iniciar sesión / registrarme / conectarme. Estoy tratando de hacerlo bien para que no se arruine en el futuro.

Por ahora, he leído varios artículos sobre qué método debo usar para realizar una "sesión de usuario segura" entre el cliente y un servidor.

Mi objetivo es usar RSA solo para intercambiar la clave AES y enviar paquetes solo con AES

Debería verse así:

Almacene la misma clave RSA pública en todos los clientes

Almacene una clave RSA privada en el servidor

El cliente envía el ' AES initialization data ' al servidor cifrado con público RSA . El servidor descifra los datos AES con una clave privada RSA , almacena los datos AES , cifra los datos AES con los datos AES y envía al cliente.

El cliente recibe AES de datos encriptados con el mismo AES de datos, los descifra y, si todo está bien, se hace un saludo, podemos enviar mensajes de forma segura utilizando AES de datos.

Estoy usando Java y he hecho el algoritmo RSA , verifiqué los paquetes con Wireshark, los cifré y desencripté y funcionó. Lo que no puedo terminar es el cifrado AES porque me falta algo de conocimiento.

Sé que AES usa IV parameter que se usa como una 'sal' en SHA . Básicamente, sé cómo funciona la IV, leo un poco, pero no tengo idea de cuándo y cuántas veces debo enviarla.

¿Debería generarse IV una y otra vez con cada paquete o solo debo generar uno con un SecretAESKey , guardarlo y usar este par para cifrar datos y descifrarlos?

Realmente aprendo rápido, así que no me juzgues porque esta pregunta puede parecerte estúpida.

¡Gracias por cualquier ayuda!

    
pregunta Spectre 06.10.2016 - 18:05
fuente

1 respuesta

2

No hagas esto, nunca.

Inventar un protocolo seguro, incluso usando primitivas criptográficas bien conocidas es extremadamente difícil. La implementación de un protocolo correctamente diseñado todavía se considera difícil, incluso cuando se usan primitivas criptográficas correctamente implementadas. Personas con experiencia que trabajan en criptografía en Google / Microsoft / Apple han cometido errores graves con estas cosas. Han aprendido de estos errores y todos recomiendan que utilices la API más resistente al mal uso que puedas, en lugar de lo que estás haciendo, que está usando una API de nivel extremadamente bajo, mal.

De las preguntas que hace, está muy lejos de estar calificado para hacer este tipo de trabajo para cualquier cosa que pueda dejar su computadora.

Parece que estás intentando inventar el criptográfico de los 90.

AES no tiene un "parámetro IV". Está preguntando acerca de los modos de operación de cifrado de bloque (específicamente CBC, que no se usa en los nuevos protocolos), y está tratando de decidir si hacer el error IV determinista en TLS 1.0 CBC. Bueno, adivinen qué, el error apareció en la lista de correo en el último siglo y se ha corregido desde entonces. Y luego CBC fue desaprobado en favor de los modos AEAD, y ahora la industria está en modos AEAD resistentes al uso indebido que no se rompen de forma catastrófica cuando se repite un nonce. Trabajando solo sin que los mejores criptógrafos señalen los problemas con tu esquema, puedes descubrir todos esos errores famosos por ti mismo, en un millar de años.

Dado que no ha preguntado cómo combinar el cifrado y el MAC, sospecho que está realizando un cifrado no autenticado, que es catastrófico. Cuando descubras que necesitas un MAC, lo combinarás mal con el cifrado y el relleno, como hizo SSL en los años 90.

¿Entiende cómo funciona el relleno seguro de RSA y por qué lo necesita?

Está intentando realizar un intercambio de claves RSA que no se permite en HTTP2 y TLS 1.3, por buenas razones. Los protocolos modernos brindan secreto hacia adelante.

¿Entiendes que el cálculo de índice está matando lentamente a RSA y al DH clásico y es por eso que la gente cambió a ECC?

Para resumir: no hagas esto. Siempre.

Use libsodium (o tweetnacl) en su lugar. Es seguro, rápido, tiene una API resistente a los usos indebidos, ha sido examinado por las mejores personas. Es mucho, mucho mejor que TLS, incluso TLS 1.3, que aún no está estandarizado.

Para fines educativos, recomiendo hacer cryptopals . Aprenderás todo lo que necesitas saber sobre cómo romper una mala criptografía.

    
respondido por el Z.T. 11.10.2016 - 21:01
fuente

Lea otras preguntas en las etiquetas