Cómo usar RC4 de forma segura

3

Quiero cifrar mis comunicaciones de red con RC4 . La razón para elegir RC4 es la implementación simple y la velocidad.

Necesito tener una implementación de Python pura, porque no puedo compilar para mi sistema de destino. Mi implementación está ligeramente modificada de TLS Lite .

Si entiendo los problemas de seguridad correctamente, el problema principal es que el algoritmo no está diseñado para usarse con un nonce . Tal como se propuso en Wikipedia, mi enfoque es generar un hash MD5 de una clave y un nonce y usar esto como clave de cifrado.

¿Esto es suficiente o también tengo que implementar la variante dropN ? ¿Algún otro punto débil que tenga que mirar?

También se apreciaría una alternativa rápida y simple a RC4.

Actualizar Después de leer Archivo de impresión electrónica de criptología: Informe 2002/067 , creo que definitivamente debería usar el enfoque dropN (con al menos 512 bytes).

Actualización 2 Revisar mi implementación también sería bueno.

    
pregunta schlamar 19.06.2012 - 14:20
fuente

2 respuestas

3

Primero: NO utilice MD5. Siempre. Nunca. Especialmente no en cualquier forma de contextos de seguridad. Utilice al menos SHA-1 o SHA-2 (256 o 512/256 si la velocidad es un problema en las máquinas de 64 bits). Aparte de algunas razones heredadas, el MD5 debe estar prohibido y, cuanto más rápido dejes de usarlo, mejor te irás.

Si necesita una implementación simple y pura de Python RC4, tengo una en enlace .

Es básicamente la misma implementación que usamos como una de las fuentes para los vectores de prueba en RFC 6229 .

Sí, debes usar nBytes. Mire el arcfour128, arcfour256 definido en RFC 4345 o algunos de los otros para los que hemos calculado vectores de prueba.

Me doy cuenta de que debo mover el RC4.py a GitHub . Y cambia la huella dactilar para usar algo que no sea MD5. Facepalm. ;-)

    
respondido por el Joachim Strömbergson 19.06.2012 - 16:15
fuente
1

RC4 tiene algunas deficiencias:

  • No tiene un Vector de inicialización distinto de la clave. Si usas la misma clave dos veces, obtienes el doble de la misma secuencia de bytes pseudoaleatorios, y usar eso es un pecado mortal. Por lo tanto, cada clave debe usarse una sola vez (para un flujo de bytes posiblemente largo). Derivar la clave de cifrado a partir de una "clave maestra" y un valor aleatorio por mensaje, utilizando una función de derivación de clave (por ejemplo, una función de hash), puede corregir que si se realiza correctamente .

  • Tiene sesgos bastante grandes en los primeros bytes. Si se eliminan los primeros N bytes de salida (para algún valor de N , que deberían ser unos pocos cientos), se puede arreglar eso.

  • Tiene pequeños sesgos después. Estos pueden ser exhibidos estadísticamente sobre unos pocos gigabytes de datos. No existe una cura conocida. Estos sesgos rara vez son fatales.

  • RC4 es solo cifrado . No hace nada por la integridad. En cualquier modelo de ataque serio, el cifrado debe estar acoplado con un MAC . Combinar un cifrado simétrico y un MAC de forma segura no es fácil .

Por todas estas razones, la mejor manera de usar RC4 es a menudo no usarlo en absoluto. En su lugar, use un modo de cifrado autenticado que hace todo el trabajo duro; Mi favorito es EAX .

En cuanto al rendimiento , considere que la CPU x86 moderna ofrece una implementación de hardware de AES en contra el cual RC4 será un caracol artrítico. Si todavía tiene un problema de rendimiento real en una arquitectura que no ofrece un AES optimizado para hardware, RC4 tampoco es el mejor en su clase; hay otros cifrados de flujo que son más rápidos y más seguros (todos los cifrados de flujo de la cartera actual de eSTREAM recibió una buena cantidad de escrutinio y se realizó sin daños).

    
respondido por el Thomas Pornin 03.01.2013 - 21:16
fuente

Lea otras preguntas en las etiquetas