¿Qué tan fuerte es un cifrado XOR simple con IV aleatorio?

  

Me gustaría implementar algún tipo de cifrado simple (pero lo más sólido posible) > para el tráfico de red de mi aplicación cliente-servidor. Los datos que se van a cifrar pueden ser tanto de texto como binarios.

Estás implementando un cifrado Vigenère modificado. Eso podría ser un problema porque cualquier secuencia suficientemente grande de datos repetitivos (donde los ceros binarios son los más evidentes), o datos estructurados (por ejemplo, JSON) como lo señala Polinomial, revelará la longitud de la clave y el algoritmo que está utilizando y permite, de manera trivial, descifrar el valor de la información de un par de longitudes clave.

Existen varios enfoques criptoanalíticos que pueden adaptarse a su caso. Una simple prueba de distribución revelará que vale la pena ejecutar un ataque.

Aparte de eso, tiene una vulnerabilidad permanente en la distribución de claves: tiene una clave (o un conjunto finito de claves) cableado tanto en el cliente como en el servidor, o necesita proporcionar un intercambio de claves seguro.

  

el uso de certificados y grandes librerías como OpenSSL es demasiado para mi proyecto.

Por favor, no te tomes esto mal, pero te estás acercando a esto de manera incorrecta. Estoy de acuerdo en que implementar OpenSSL sería mucho más difícil que ir a Vigenère (o Vernam / OTP, que es el siguiente paso lógico). Pero no necesita hacer eso, solo necesita utilizar una biblioteca existente. Después de eso, estará sano y salvo y realmente disfrutará no solo de más seguridad , que puede ser superfluo para usted, sino de mayor simplicidad de código y mayor mantenimiento .

Dependiendo de la configuración, quizás puedas hacer esto simplemente eliminando un proxy SSL como Stunnel frente a tu servicio HTTP simple:

                       |
HTTP service --- PROXY | === SSL channel === SSL client (browser)
                       |

y poder ambos probar su sistema en HTTP y suministrar a sus clientes de forma segura en HTTPS.

Otros servidores web (tanto Apache como Nginx), como también balanceadores de carga, permiten la SSLización de servicios del lado del servidor.

El problema número uno con el esquema que ha propuesto es que ha ignorado por completo el intercambio de claves seguro.

El siguiente problema es que la salida no será aleatoria, ya que Iserni señaló out y, por lo tanto, es susceptible a varios ataques.

El siguiente problema después de eso es que no está autenticado, lo que puede provocar ataques de modificación de texto cifrado y rellenar oráculos como POODLE.

Este esquema es demasiado simplista y tiene muy pocas consideraciones para tener propiedades de seguridad significativas para el uso en línea como lo describió.

Como Stephen Touset mencionado en En su comentario , o bien desea que sus datos estén protegidos contra escuchas ilegales o no. Si lo haces, encripta los datos correctamente. Si no lo haces, no te molestes en cifrarlo.

TLS manejaría todos los problemas difíciles como el intercambio de claves y la autenticación, y la implementación de algoritmos realmente sólidos para usted. Sin resolver esos problemas, no tiene seguridad, así que no intente engañarse pensando que sí, agregando una complejidad arbitraria y llamándolo algoritmo de cifrado. Simplemente deje los datos sin cifrar, y será exactamente tan seguro como lo sería con el esquema que ha propuesto.

TLS no lo es, como lo has llamado "teóricamente irrompible". De hecho, tiene algunas debilidades muy reales en los puntos. Sin embargo, es razonablemente seguro y ya está implementado en muchas bibliotecas. Su esquema no es "lo suficientemente bueno" pero, de hecho, parece estar mal diseñado y, para todos los efectos, inutilizable sin mucho más trabajo.

Básicamente, estás hablando de implementar un " pad de una vez " (con algunas modificaciones)

Para hacer un pad de una sola vez, deberías:

• asegúrese de que haya suficientes datos aleatorios (que es básicamente la clave);
• necesita tener propiedades aleatorias criptográficamente fuertes;
• necesita distribuir esta clave de manera segura a todas las partes que necesitan descifrarla;
• necesita proteger la clave en el almacenamiento (entre la distribución y el descifrado); y debe asegurarse de que la clave nunca se reutilice ...
• por lo que su clave debe ser más larga que los datos cifrados.

La conclusión es: si puede implementarlo correctamente, es extremadamente fuerte (probablemente irrompible, salvo el análisis de criptoanálisis con manguera de goma). SIN EMBARGO, es un enorme "si", es decir, es más sencillo simplemente implementar el cifrado regular, ya que las condiciones previas para implementarlo son muy estrictas y estrictas. (Es decir, si tiene un mecanismo para distribuir y proteger esa cantidad de datos de forma segura, también puede utilizar ese mecanismo en los datos secretos en sí, en lugar de en la clave).