Estoy creando una aplicación web simple para chat encriptado. Cada mensaje se someterá a un cifrado AES de 256 bits en el lado del cliente, utilizando la biblioteca criptográfica de Stanford Javascript. Ningún dato no cifrado o información de contraseña dejará el navegador del usuario.
¿Es seguro implementar este esquema, utilizando el cifrado del lado del cliente, incluso sin SSL?
Javascript se envía desde el servidor al cliente; cualquier criptografía que haga del lado del cliente proporcionará seguridad solo en la medida en que el código que ejecuta el cliente no haya sido modificado en tránsito, lo que significa que aún se requiere SSL, al menos para asegurarse de que lo que el cliente recibe y ejecuta realmente es el Implementación genuina de su protocolo.
Esto implica que si el servidor es hostil al cliente, entonces el servidor gana y el cliente está condenado. En consecuencia, es un intento inútil tratar de proteger los cálculos del cliente del del servidor. A partir de este argumento (algo simplista), podemos concluir que tiene poco sentido cifrar los datos en el cliente; simplemente use SSL, envíe los datos al servidor y deje que el servidor haga su trabajo. El servidor es de confianza , lo que significa que si el servidor quiere traicionarte, estás indefenso.
La Stanford Javascript Crypto Library sigue siendo una buena ciencia, pero no se relaciona bien con el uso de Javascript en un clásico Contexto web Tendría mucho más sentido como parte de una extensión del navegador o cualquier cosa similar que tenga un script que se beneficie de un mecanismo de distribución de código específico, independiente y seguro.
(Tenga en cuenta que todo lo anterior se aplica incluso si su protocolo es sólido desde el punto de vista criptográfico, y no muchos criptógrafos se atreverían a pretender que pueden lograr tal hazaña por sí mismos. , sin una extensa revisión por pares.)
No hay suficiente información, pero por el sonido ... ¡NO! No despliegue su propio esquema.
El problema aquí no es el cifrado ... AES es muy fuerte. El problema es el protocolo, que tiene muchos matices como el acuerdo clave, cómo se garantiza la integridad, etc.
Este es un ejemplo reciente que se desprende de los titulares de algunos desarrolladores que desarrollan su propio protocolo para la mensajería segura. Moxie hace un buen trabajo señalando algunos lugares donde podrías haber cometido un error.
El cifrado con AES usando sjcl una vez resultará en un texto cifrado del cual un adversario probablemente no puede averiguar el resultado de.
La implementación de un protocolo de chat seguro completo en el que se usa AES para mantener la confidencialidad podría ser buena ... pero podría tener problemas graves que podrían hacer que alguien sea encarcelado.
Lea otras preguntas en las etiquetas encryption tls javascript client-side