¿Qué tan seguros son los archivos HTML descifrados automáticamente para el almacenamiento de datos?

Al menos el autor escribió una página bastante clara sobre cómo funciona su cifrado . No obstante, esto parece un cifrado de flujo casero bastante antiguo, lo cual no es una buena noticia, ya que la mayoría de estos sistemas han sido completamente dañados. Parece que consta de un subsistema LFSR básico (dos LFSR con polinomios dependientes de la clave; el bit sobre los polinomios que operan en "dirección inversa" es una pista falsa, porque este subsistema es completamente lineal) y otro LFSR que actúa como un no -el motor de selección lineal. Hay algunos diseños selectos que se parecen aproximadamente a eso y parecen ofrecer una resistencia criptoanalítica no despreciable (por ejemplo, el Generador de pasos alternativos ), pero esto tiene un precio, es decir, que necesita mucho más que n bits de estado interno si desea lograr un 2 ⁿ nivel de seguridad. Además, muchos de estos diseños resultaron ser débiles.

Podemos confiar en la resistencia de un algoritmo criptográfico basado en la combinación de las siguientes propiedades:

• Se sabe que el diseñador es muy bueno en el diseño de algoritmos (por ejemplo, su nombre es Rivest ).
• El diseño tuvo una amplia exposición, como la publicación en una conferencia de alto perfil y / o la implementación a gran escala.
• Han transcurrido varios años y nadie ha encontrado ningún problema.

Este diseño le falta un poco en los tres puntos.

Editar: no lo había notado (necesito más café por la mañana) pero el flujo generado es determinista para una contraseña determinada. Esto significa que si cifras los archivos dos con la misma contraseña, estás en la infame situación de "dos veces el pad", y básicamente has perdido.

Otro punto es que la contraseña se deriva en una clave con solo un par de invocaciones de MD5. MD5 es muy rápido; Una GPU buena, pero lista para usar y no totalmente costosa puede evaluar el MD5 a una tasa de aproximadamente mil millones por segundo. Si el atacante adivina los primeros bytes de los datos cifrados (ya que se supone que el texto claro es Javascript, los primeros bytes probablemente sean " var " o " function "), entonces todo es vulnerable a ataques de diccionario , también conocido como "búsqueda exhaustiva de contraseña" (probar contraseñas potenciales hasta encontrar una coincidencia). Es posible tener una gran contraseña aleatoria que derrote los ataques de diccionario, y un cerebro humano aún podría recordarlo con algún esfuerzo. Pero la mayoría de las contraseñas son débiles a ese respecto. Además, sin sal: para una contraseña determinada, siempre se obtiene el mismo flujo. Por lo tanto, uno podría calcular previamente los primeros bytes de la secuencia para cada contraseña potencial, y después de descifrar cualquier instancia sería cuestión de unas pocas búsquedas en la tabla (la tabla podría tomar la forma de a tabla de la canilla para un almacenamiento más compacto).

Para la parte de manejo de contraseñas, este esquema es definitivamente débil.

El caso de uso también es dudoso. Dado que este es un código Javascript en el que el usuario ingresa su contraseña, es vulnerable a los ataques activos: un atacante activo podría simplemente alterar el código Javascript, de modo que cuando el usuario ingrese su contraseña, también se registre una copia de la contraseña en algún lugar (por ejemplo, los datos descifrados, que se supone que son los mismos Javascript, obtienen un fragmento de código adicional que imprime una etiqueta oculta <img> con una URL que apunta a un servidor controlado por un atacante y que codifica la contraseña).

Para vencer los ataques activos de ese tipo, la solución es conocida, y eso es SSL. El "archivo de descifrado automático" se debe servir solo a través de HTTPS. Pero si se usa HTTPS, ¿por qué sería necesario el auto-descifrado? En su lugar, haga que el servidor proporcione la parte sensible de Javascript solo después de haber autenticado debidamente al usuario, con la contraseña. Este es un modelo muy común, los servidores web existentes lo implementan fuera de la caja y es más fuerte ya que frustra los ataques de diccionario fuera de línea (desde el exterior, el atacante no puede "probar las contraseñas" a la velocidad máxima de su GPU; tiene que Pregunte al servidor para cada respuesta, y el servidor puede responder tan lentamente como lo desee).

Resumen: recomiendo en contra al usar este código. Todavía me doy cuenta de que, al menos, el diseñador de SDA parece haber hecho esfuerzos encomiables en la documentación, y estar sano, solo la cordura lo coloca en una minoría, entre la multitud de diseñadores de cifrado en Internet.

El problema con todos estos tipos de cosas es que realmente no se puede determinar qué tan seguros son. Lo que hacemos en cambio es confiar en aquellos que han sido probados a lo largo del tiempo por un gran número de personas experimentadas (@ThomasPornin tiene una excelente respuesta a esta pregunta, en la que intentaré encontrar un enlace). Probablemente esta sea la razón por la que el autor ha colocado el desafío: Él quiere que se lo pruebe.

Este puede usar un algoritmo seguro, pero si la implementación tiene puntos débiles, puede ser inseguro.

En resumen: si tiene una necesidad real de un SDA seguro, le aconsejaría que vaya con uno probado y comprobado, ya que es probable que su riesgo sea menor. Sin embargo, si puede revisar el código que se encuentra detrás de éste y evaluar el riesgo para usted de que sus usos sean lo suficientemente bajos, entonces esto puede estar bien para sus propósitos.

(Lo siento, es un poco incierto, pero mucho de esto es ...)

En general, me mantendría alejado de cualquier cosa en la que no pueda revisar el código y tenga que realizar el cifrado en línea. Tal vez no sea el caso aquí, pero cada vez que he visto nuevos algoritmos de cifrado o esteganografía que estaban disponibles solo en línea, era un honeypot que recopilaba información sobre lo que las personas podrían querer encriptar u ocultar.