Javascript从服务器发送到客户端；无论您在客户端执行什么加密，只有在客户端运行的代码在传输过程中没有被更改的情况下才能提供安全性——这意味着仍然需要 SSL，至少要确保客户端接收和运行的内容确实是真正实现您的协议。

这意味着如果服务器对客户端怀有敌意，那么服务器将获胜，而客户端则注定失败。相应地，试图保护客户端计算不受服务器影响是徒劳的。从这个（有点简单化）的论点，我们可以得出结论，在客户端加密数据没有什么意义；只需使用 SSL，将数据发送到服务器，然后让服务器完成其工作。服务器是受信任的，这意味着如果服务器想背叛你，那么你就毫无防备。

斯坦福 Javascript 加密库仍然是一门很好的科学，但它并不能很好地映射到经典 Web 环境中的 Javascript 使用。作为浏览器扩展或任何类似脚本的一部分，它会更有意义，因为它受益于特定的、独立的、安全的代码分发机制。

（请注意，即使您的协议从密码学的角度来看是坚如磐石的，上述所有内容都适用——而且没有多少密码学家敢假装自己可以在没有广泛同行评审的情况下完成这样的壮举。）

没有足够的信息，但从它的声音......不！不要推出自己的计划。

这里的问题不在于加密......AES非常强大。问题在于协议，它有许多细微差别，例如密钥协议、如何确保完整性等。

这是最近的一个例子，它来自一些开发人员推出他们自己的安全消息传递协议的头条新闻。Moxie 很好地指出了一些你可能犯错的地方。

使用 sjcl 使用 AES 加密一次将导致对手可能无法弄清楚结果的密文。

实施一个使用 AES 进行保密的完整安全聊天协议可能会很好……但它可能存在严重的问题，可能会让某人入狱。