¿Es RC2-CBC seguro?

RC2 es un cifrado de bloque "ininterrumpido" actualmente; el ataque más conocido es un "ataque de clave relacionada", es decir, algo que realmente no se aplica en la práctica (los ataques de clave relacionada tienen que ver con propiedades específicas cuando la víctima usa dos claves distintas, que el atacante no sabe, pero con una diferencia entre ellos que el atacante sabe).

RC2 todavía tiene algunas propiedades subóptimas:

• Utiliza bloques de 64 bits. Esto hace que no sea adecuado para procesar grandes conjuntos de datos, ya que el corte está alrededor de 2 bloques ^{n / 2} cuando los bloques consisten en bits n . Para un cifrado de bloque de 64 bits, esto equivale a unos 30 gigabytes con una sola clave, lo cual es grande pero no alcanzable en algunos contextos. Cifrar más datos que eso implica un riesgo de revelar parte del texto sin formato. Tenga en cuenta que 3DES sufre exactamente la misma limitación. Para los correos electrónicos encriptados, debería estar de acuerdo con eso.

• Su rendimiento apesta. Tanto como la de 3DES; en mi computadora portátil (con poca potencia), la implementación de OpenSSL alcanza aproximadamente 10 MB / s con 3DES, 12 MB / s con RC2. Una vez más, para los correos electrónicos, esto no debería ser un problema.

• RC2, en su descripción, utiliza una gran cantidad de tablas de búsqueda dependientes de los datos. En ese sentido, sería muy difícil realizar una implementación que sea de "tiempo constante" (es decir, no filtre información a los atacantes que pueden ejecutar su propio código en el mismo hardware, a través de las diferencias de tiempo inducidas por el caché); al menos, sería muy difícil hacer uno sin una desaceleración masiva (como un factor de desaceleración de 100x). Tenga en cuenta que las implementaciones clásicas de 3DES tampoco son de tiempo constante, pero eso se puede hacer con solo una desaceleración (relativamente) "moderada" (aproximadamente 3.5x con mi propio código).

  Dado que el envío de correo electrónico es asíncrono y, además, como el cifrado y el descifrado de correo electrónico tienden a ocurrir en la computadora de escritorio del usuario, no en un servidor compartido, este tipo de fuga de canal lateral no debería ser una gran preocupación de todos modos. A menos que decida cargar claves privadas en un servidor, en cuyo caso las inquietudes pueden volver: asegúrese, al menos, de que el servidor no esté alojado en una nube que comparta el mismo hardware con terceros.

• RC2 tiene una longitud de clave configurable, entre 1 y 128 bytes (es decir, de 8 a 1024 bits y múltiplos de 8). Por lo tanto, aunque RC2 en sí mismo puede ser un algoritmo tolerablemente fino, todavía puede usarse con una clave que es demasiado corta para garantizar un nivel de seguridad decente. RC2 también incluye un parámetro adicional (llamado "longitud de clave efectiva") que se puede usar para limitar la resistencia de fuerza bruta. Históricamente, RC2 se ha utilizado mucho en configuraciones destinadas a cumplir con las reglas de exportación de criptografía de EE. UU. , con una fuerza típica equivalente a 40 bits (es decir, no es fuerte en absoluto).

El cuarto punto es, en mi opinión, su mayor riesgo al usar RC2. Realmente no sabes qué tan grande es la clave de cifrado real; Si el software que utiliza no documenta esa información, entonces realmente no sabe qué tan seguro será el cifrado. Además, el software que usa RC2 puede faltar un poco de mantenimiento ...

Para resumir, no hay nada realmente incorrecto en el propio RC2 para cifrar los correos electrónicos, pero la implementación todavía tiene un amplio margen para hacer estupideces que aniquilan la seguridad.