Cifrado: ¿debería utilizar RSA o AES?

Ninguno, a menos que sea ambos. estás haciendo la pregunta incorrecta . No debería estar pensando en un algoritmo criptográfico en esta etapa, sino en un protocolo criptográfico.

Los protocolos criptográficos son difíciles de diseñar y una fuente frecuente de errores de seguridad. No entiende completamente la criptografía de clave pública, por lo que no está listo para usarla en su propio protocolo criptográfico.

En un nivel alto, su modelo es susceptible a la criptografía de clave pública (por ejemplo, RSA). Permita que cada cliente tenga su propia clave privada y publique su clave pública al otro cliente. La clave privada de un cliente no cambia con el tiempo, a menos que el cliente haya sido comprometido. La criptografía simétrica (por ejemplo, AES) no se escalaría bien aquí porque cada par de clientes tendría que tener su propia clave secreta.

Utilice el software existente siempre que sea posible. Implementar protocolos criptográficos es casi tan complicado como diseñarlos. Para un modelo en el que los clientes ocasionalmente envían mensajes entre sí, al estilo de correo electrónico, una herramienta que funcionaría bien es GnuPG . (Para comunicaciones bidireccionales, use SSL / TLS .)

Entonces: para la operación del día a día, para enviar un mensaje, llame a gpg , cifre con la clave pública del destinatario, y mientras lo hace, firme con la clave privada del remitente. Al recibir un mensaje, verifique la firma con la clave pública del remitente supuesto y descifre con la clave privada del receptor. En otras palabras, envíe con gpg --sign --encrypt -r NAME_OF_RECIPIENT y reciba con gpg --verify seguido de gpg --decrypt .

El problema restante es el de la distribución de claves. Una vez que un cliente ha generado su par de claves, debe informar al resto de los clientes y distribuirlo sin permitir que la clave pública sea interceptada y reemplazada en tránsito por un atacante. Cómo hacer esto depende mucho de su escenario preciso. No descuide la seguridad de esta parte.

Si, y solo si, la invocación de GnuPG resulta ser demasiado lenta, entonces considere usar una implementación más liviana, tal vez hecha en casa, de un protocolo similar (que va desde la sobrecarga del rango de correo electrónico a la sobrecarga del rango de SMS). Bajo el capó, GnuPG genera una clave simétrica para cada mensaje, porque la criptografía de clave pública es costosa para los mensajes grandes; el algoritmo de clave pública solo se utiliza para cifrar la clave simétrica y para firmar un resumen del archivo. Deberías seguir este modelo. El uso de AES para cifrado simétrico, SHA-256 como algoritmo de resumen y RSA como algoritmo de clave pública es una buena opción.

Como ya lo dijo In silico, RSA y AES tienen dos propósitos diferentes. AES es un algoritmo rápido, adecuado para cifrar una conversación completa. Pero tiene un problema: ¿cómo decidir qué clave usar entre dos partes sin que las otras lo sepan?

RSA puede ser la solución a esto. Si cada participante tiene la clave RSA pública de todos los demás participantes, cualquier persona puede iniciar una comunicación cifrada con otra persona (utilizando la clave pública del otro participante) y decidir qué clave secreta de AES usar. Una vez que se decide la clave AES, el resto de la conversación se puede cifrar utilizando AES. Para demostrarle al participante B que es realmente A lo que quiere decirle algo, se puede usar una firma digital.

Lo que describí es, grosso modo, lo que hace el protocolo SSL cuando un navegador se conecta con un servidor web habilitado para SSL.

No lo tomes a mal, pero ...

  

Sé lo básico de cómo funcionan RSA y AES, pero no puedo entender qué es lo mejor.

Si solo sabes lo básico, es posible que no seas la persona adecuada para resolver este problema (todavía). La seguridad es una de esas áreas en las que debe ser muy particular y cuidadoso o de lo contrario invalida toda su configuración de seguridad.

Además, no creo que tengamos suficiente información para darle una respuesta adecuada. Los contratos comerciales sobre expectativas de seguridad deberán ser conocidos desde el principio.

En la mayoría de los casos, las claves nunca abandonan la máquina en la que se generan por razones de seguridad, por lo tanto, si tiene la intención de "compartir" información, una solución de clave pública suele ser la opción correcta desde un punto de vista de seguridad. La excepción a esto es si puede compartir una clave simétrica de manera segura, como enviar la clave a la persona en un medio físico.

Básicamente, el uso de cifrado de clave pública (como RSA) es mucho más caro que el uso de cifrado de clave simétrica (como AES), y cuando hay muchos mensajes que pasan de uno a otro, es mejor utilizar una clave simétrica.

Ahora, la creación y el intercambio de la clave simétrica se pueden realizar mediante el cifrado de clave pública.

Por ejemplo:

Cada cliente tiene un par de claves públicas y privadas, y la clave pública se almacena en el servidor. Cuando dos clientes inician la sesión de comunicación, cada uno toma la clave pública del otro del servidor y envía un número cifrado al otro. Luego, cada lado escribe esos dos números y utiliza el resultado como la clave para cifrar / descifrar los datos de ahora en adelante.

Si usa el estilo PÚBLICO / PRIVADO (RSA con suficientes bits :)) puede configurar el tipo de comunicación segura que describe de esta manera:

1. Alice escribe un mensaje
2. Alice lo cifra con la clave Alice de PRIVADA
3. Alice lo cifra nuevamente usando la tecla Bob de PUBLIC
4. Alice envía los resultados a Bob.

Entonces:

1. Bob recibe un mensaje (supuestamente) de Alice
2. Bob lo descifra con la tecla Bob PRIVADA
3. Bob lo descifra nuevamente usando la tecla PUBLIC de Alice
4. Si todo va bien, Bob lee el mensaje.

Nota:

• Bob es el único que puede leer este mensaje.
• Bob sabe sin ninguna duda que vino de Alice.

Obtener ambos atributos con AES es un poco más complicado.