cifrado de JavaScript para sitios web entregados a través de IPFS

Bueno, un problema hasta hace muy poco tiempo (es decir, ¡la semana pasada!) fue que las implementaciones de Math.random () en la mayoría de los navegadores eran, francamente, basura. V8 (el motor de Javascript detrás de Chrome y NodeJS) y < a href="http://jandemooij.nl/blog/2015/11/30/testing-math-random-crushing-the-browser/"> Spidermonkey (el motor de Firefox) usó PRNG con períodos demasiado cortos , y hay evidencia que sugiere que IE y Edge también han roto PRNGs. Esto significa que si hay alguna llamada a ellos desde cualquier elemento de una capa que dependa de ellos, habrá un conjunto limitado de resultados posibles. Ahora, esto aún puede ser un montón de resultados (alrededor de 590 millones, para el caso V8), pero eso es mucho menos que el ideal 2 ^ 132 (5,444,517,870,715,015,413,993,718,908,291,383,296).

Esto significa que cualquier ataque tiene una probabilidad mucho mayor de éxito: interceptar datos en tránsito y luego atacar sin conexión. Puede tomar un tiempo, pero AES es rápido en los procesadores modernos, y las computadoras son baratas.

Otros problemas con esto podrían ser: ¿cómo puede asegurarse de que no haya extensiones en uso? El navegador está fuera de su control. ¿Cómo puede estar seguro de que no hay fallas por descubrir en IPFS? Los profesionales de la seguridad tienden a preferir los sistemas que han sido objeto de muchos ataques, y no se han roto, a los nuevos sistemas que no se han probado tanto. Incluso si la teoría matemática es perfectamente sólida, ¿es correcta la implementación? Un error tipográfico o una adición incorrecta podría dar lugar a un problema masivo: consulte Heartbleed.

También hay problemas con otras partes de la infraestructura del navegador que pueden afectar a algunos tipos de criptografía en el navegador. La interfaz de FileWriter está en desuso, lo que significa que cualquier cosa más grande que la memoria del navegador no se puede descifrar de manera confiable (no hay una forma sensata de escribirla en el disco; curiosamente, FileReader funciona bien para el cifrado). Falta el soporte del navegador para las operaciones de encriptación: Windows y Linux pueden usar llamadas nativas para AES en la actualidad, en procesadores modernos, pero se necesitaría trabajo para que los navegadores puedan hacer lo mismo.

Estamos llegando, pero aún no es un problema resuelto. Si IPFS resiste el escrutinio, los fabricantes de navegadores implementan fuentes de aleatorización mejoradas, y así sucesivamente, estará cerca. Sin embargo, no parece probable que el problema de la extensión desaparezca: la gente parece estar atada a sus bloqueadores de anuncios, y probablemente no quieran intercambiar seguridad por no tener ninguna extensión activada para anuncios.

Hay muchos escollos , al hacer criptografía en JavaScript. Recomiendo buscar en la API de WebCrypto , ya que proporciona primitivas criptográficas que le permiten utilizar el cifrado moderno.

Recomiendo mirar la presentación de Tim Taubert sobre la API de WebCrypto a medida que te guía a través de una nota Aplicación que almacena su contenido encriptado. En su finalización, recomienda derivar una clave de cifrado a través de PBKDF2 y los cifrados mediante AES-GCM.

Sus problemas restantes son probables:

• Denegación de servicio: ¿Puede confiar en que el proveedor de almacenamiento no elimine datos o partes de los datos?
• Rendimiento: si todos los datos del usuario son un gran blog cifrado, tendrás que volver a cifrar todo, incluso con cambios mínimos.

Puede contrarrestar el problema de rendimiento cifrando los elementos en una matriz de forma selectiva, pero esto traerá consideraciones de seguridad adicionales: debe evitar la reutilización de nonce y almacenar nonces por artículo. Un proveedor de almacenamiento que no sea de confianza aún puede eliminar filas, a menos que cree un hash tree para verificar profundamente la integridad de los datos.

Usted podría también permitir cambios de contraseña con una "clave de cifrado de clave" (es decir, generar una clave de almacenamiento aleatoria para el cifrado, cifrar esta clave de almacenamiento con la "clave de cifrado de clave derivada de la contraseña").

Como puede ver, la criptografía en sí misma no es una panacea. Debes encontrar una gran cantidad de ingeniería de criptografía sólida en la parte superior.

No hagas esto. IPFS no es seguro. Alguien entre su usuario y el nodo de IPFS podría decidir interceptar y cambiar consultas. También existe el problema de que alguien podría cambiar sus archivos localmente en IPFS. Cualquier persona que obtenga sus archivos de ese host recibirá un código malicioso. Alguien podría escribir un virus que cambie el contenido de sus archivos a medida que llegan a la computadora de sus usuarios .

Incluso si asumimos que IPFS es perfectamente seguro, los scripts entre sitios son un problema real. Se ha hecho de varias maneras, y todo lo que un atacante debe hacer para completar su cifrado es cambiar una función en la que confíe.

Todo lo que un atacante XSS debe hacer es obtener una sola línea de código para ejecutar:

Math.random = function () {return 0.4;};

y todo tu cifrado probablemente caiga sin que nadie lo note. Peor aún, sus datos de usuario se almacenarán de forma insegura en IPFS, abiertos para cualquier persona que conozca sus funciones (cualquiera con acceso a IPFS) y la semilla aleatoria 0.4 para leer.

Hay muchas otras formas de romper tu cifrado si lo haces en los navegadores. Para obtener más información, consulte la página que vinculó; puede excluir muy pocos de los puntos realizados allí. Si no entiende por qué todavía son válidos, debería dedicar algún tiempo a leer sobre redes / criptografía.

Si desea crear un sistema distribuido en IPFS que tenga datos encriptados, tenga un servidor de autenticación centralizado para respaldarlo y use ese servidor para todo lo que necesite en términos de criptografía.