Transmitir cifras utilizando HTTP simple

Parece que estás intentando inventar algún tipo de clon "DropBox".

  

La seguridad de un solo algoritmo de cifrado está bien estudiada, mientras que el apilamiento de varios algoritmos es desconocido (por ejemplo, NaCl() vs. AES(NaCl() )

Creo que esto no se aplica. No puedo hacer un argumento matemático difícil aquí, pero para los cifrados independientes, con claves completamente no relacionadas, la fuerza del cifrado compuesto NO puede bajar en absoluto. Y será por lo menos tan fuerte como el más débil de los dos encriptados. Eso es todo. Solo está evitando la simple adición de dos longitudes de clave. En el peor de los casos, terminas con la menor de las dos longitudes de clave en la pila. Eso es solo para claves independientes. Lo que podemos asumir para una combinación de cifrado en reposo y cifrado de clave de sesión TLS. (Corríjame si me equivoco, Sec: SE.)

  

Simplicidad (en reposo == en tránsito)

Creo que esto se verá contrarrestado en gran medida por la complejidad de su propio esquema de autenticación / firma.

  

Aumento de la carga del servidor (archivo de envío de copia cero (2) en lugar de copiar en la RAM para cifrado TLS).

Creo que el impacto en la latencia y el rendimiento será insignificante. Tal vez ni siquiera medible. Insistiría en un punto de referencia. (- > Consulte enlace )

Y de nuevo: no tengo idea de cuánto impacto tendrá el esquema de autenticación.

  

El servidor valida el token (para evitar su reutilización) y luego transmite archivos encriptados a / desde el disco.

Esto significa que el servidor ya NO es almacenamiento tonto.

En su lugar, ¿qué hay de configurar las cosas como un espejo para una distribución de Linux? Archivos firmados en tonto (S) FTP? Ya que haces la verificación del lado del cliente de todos modos.

Cuando realiza el cifrado de extremo a extremo, el canal para enviar los textos cifrados de un lado a otro ya se considera inseguro. La única razón por la que puede querer tener un túnel SSL / TLS envuelto alrededor de los textos cifrados es para validar la identidad del servidor, que, según su caso, podría no ser necesaria.

Incluso puede ir un paso más allá y enviar los datos directamente a través de TCP (o UDP, si corresponde). Esto ahorra algunos gastos generales. De hecho, algunas aplicaciones de chat hacen exactamente esto (Telegram). Obviamente, esto implica que usted mismo debe cuidar la autenticación y la privacidad del mensaje.

Después de pasar por diferentes modelos de ataque, encontré dos riesgos posibles:

1. Recuperación lenta (Denegación de servicio)

   MiTM en el canal HTTP puede simular una transmisión lenta, negando al usuario de un servicio de calidad.

2. Manejo de mensajes corruptos

   Using HTTPS
   corrupt packets    → MiTM
   corrupt ciphertext → corrupt parties (can be the server)
   
   Using HTTP
   no way to distinguish since packet == ciphertext 
   

   Saber que la distinción es valiosa, por lo que el programa puede realizar la acción correcta (por ejemplo, reintentar más tarde una vez que se haya asegurado el canal, o descartar el mensaje de inmediato)

Lastpass hace algo similar, y funcionaría tan bien en HTTP simple como en su implementación.

Utilizan HTTPS para la autenticación, como se especifica en el OP.
Todas sus contraseñas se transmiten y almacenan utilizando su algoritmo de cifrado.

Todo el cifrado y descifrado se realiza en su propia PC, por lo que no tienen una carga de servidor impuesta por el proceso de cifrado.

En lo que se diferencian de esta publicación es que continúan utilizando también HTTPS para las comunicaciones y la autenticación.

No está claro por qué uno querría evitar el HTTPS. Y dado que el OP dice que se use HTTPS para la autenticación, entonces ¿por qué no continuar usándolo por el resto de la sesión? Con los procesadores modernos, existe una carga de servidor muy pequeña impuesta mediante el uso de HTTPS.

El mayor riesgo en el uso de HTTP es en un ataque de reproducción en el que la base de datos de Lastpass podría corromperse o bloquearte.

Creo que tienen el mejor modelo para comunicaciones y almacenamiento seguros.

Sí, funcionaría en HTTP simple excepto por la autenticación.

Espero que esto ayude.