RSA 4096 con el proceso de cifrado AES 256 mediante PyCrypto

Mi principal comentario: No proporciona suficientes detalles técnicos para proporcionar una crítica completa de su propuesta, pero ha proporcionado suficiente información como para ver que está cometiendo varios errores comunes. Estos son los principales errores que puedo ver hasta ahora:

• Error # 1: inventar tu propio formato de cifrado. Por lo general, no es una buena idea diseñar su propio formato para almacenar datos cifrados ; Es probable que te equivoques. Es mejor usar un formato estándar, como GPG o el formato de mensaje OpenPGP.

• Error # 2: no se incluye la protección de integridad del mensaje. El cifrado de datos sin autenticar también lo abre a ataques sutiles pero graves . Esto es altamente contraintuitivo, y un error muy común. Es tentador pensar, caramba, quiero mantener este secreto, así que si lo cifro con un buen algoritmo de cifrado, estaré bien. Pero no, no estarás bien. También necesita autenticación de mensajes, para defenderse de los ataques de texto cifrado elegidos. Y debe aplicar con un modo adecuado (p. Ej., Cifrado autenticado o cifrado y luego MAC) y con la administración de claves adecuada (claves independientes para la autenticación y el cifrado, o el uso adecuado de la separación de claves).

Para evitar estos problemas, siga los consejos en los enlaces que proporcioné anteriormente.

Otros comentarios misceláneos:

• Puede haber otros problemas; No nos ha proporcionado suficiente información para identificarlos a todos. Aquí hay algunos ejemplos de problemas potenciales:

  • Por ejemplo, no describe cómo se genera el IV. En sistemas anteriores, la generación deficiente de IV ha ocasionado ocasionalmente problemas de seguridad. (La IV debe generarse utilizando un generador de números pseudoaleatorios de fuerza criptográfica).

  • No describe cómo se encripta la clave AES. (Debe usar un esquema de relleno adecuado, por ejemplo, OAEP o PKCS # 2).

• Las longitudes de clave que ha seleccionado son excesivas.

• Tenga en cuenta que, cuando la criptografía moderna se implementa y utiliza correctamente, casi nunca es el enlace más débil del sistema.

  En su lugar, los atacantes generalmente derrotan a cripto no rompiendo los algoritmos de criptografía, sino evitando la criptografía y atacando algún otro aspecto del sistema, tal vez aplicando ingeniería social a los humanos, tal vez encontrando un agujero de seguridad en el código y comprometiendo una punto final, tal vez explotando errores en la administración de claves, o cualquiera de varias otras formas de atacar un sistema.

No hay "lo suficientemente seguro" a menos que definas un modelo de ataque, que es la lista de poderes que consideras que tiene el atacante previsto.

Aunque, como comentario básico, aquí no hay una verificación de integridad, por lo que los atacantes activos se divertirán con sus datos. Además, no dice nada sobre el modo de encriptación (ECB, CBC, CTR ...?) Y la administración de IV asociada, por lo que es posible que la haya estropeado (no resulte difícil, es fácil estropearla, es difícil obtenerla). Correcto). Los tamaños de las teclas son excesivos, por lo que o bien eres una administración gubernamental con más ciclos de CPU con los que sabes qué hacer, o eres un tanto paranoico o ambos. Además, estás inventando tu propio cripto, y eso es malo, porque es mucho más fácil estropearlo que notar que lo has estropeado.

1. Solo la clave AES es secreta. El CBC IV no es un secreto, siempre y cuando nunca reutilice un IV. Cada vez que cifre un mensaje con CBC, puede prefijar el texto cifrado con el IV y almacenarlo como el texto cifrado. Cuando descifre el mensaje, simplemente recuerde que el primer bloque es el IV.

2. No incluye ninguna comprobación de integridad. Puede generar una firma de varias maneras, pero debe recordar nunca firmar y cifrar usando el mismo par de llaves RSA. Una forma de generar una firma es generar aleatoriamente una segunda clave para HMAC, obtener un resumen del texto cifrado con HMAC-SHA512 y la clave generada, y luego cifrar y almacenar la clave HMAC generada junto con la clave AES generada. Si sigue la práctica de concatenar el IV con el texto cifrado, debe aplicar HMAC-SHA512 al texto cifrado IV + concatenado, no solo el texto cifrado original.

3. Usted no especificó esto de una manera u otra, pero la clave AES, el CBC IV y la clave HMAC deben generarse mediante un generador de números pseudoaleatorios seguro criptográficamente (PRNG criptográfico al azar), a menos que resulta que tiene un verdadero RNG a mano.

4. Existen formatos estándar generales para serializar mensajes cifrados. Puede elegir usarlos en lugar de almacenar los bytes en bruto de los textos cifrados y los compendios. Los estándares incluyen el OpenPGP Message Format y el Sintaxis criptográfica de mensajes .

Tenga en cuenta que el número 1 no es estrictamente un problema de seguridad, pero el problema en la práctica es que las personas a menudo están confundidas acerca de qué partes del sistema deben ser secretas y qué partes pueden ser públicas, y cuál es el contexto correcto para estas reglas. , y tal confusión a menudo conduce a errores. El propósito de la IV es proporcionar un alto grado de entropía al cifrado del primer bloque del texto plano, no para ser una especie de segunda clave.