JavaScript 密码学不是一个好主意

JavaScript 密码学本身并不坏，它只是对最常见的威胁无效。

如果您认为中间人 (MITM) 是一种威胁，那么 SSL/TLS 是一种更有效的控制，否则攻击者可以用 JavaScript 替换不使用加密的版本。

如果您认为客户端的恶意软件是一种威胁，那么它可能会以任何喜欢的方式修改 JavaScript，而您的加密将毫无用处。

如果您认为服务器端是一种威胁（例如，客户端希望服务器存储某些内容但看不到内容），那么它可能是有效的，但客户端需要一些其他方法来确保 JavaScript 没有被篡改（这不是一个容易解决的问题）并且客户需要自己管理密钥。

在您描述的用例中，听起来客户端加密不会真正增加任何额外的安全性。无论哪种方式，您都必须处理传递密钥的问题，这可能取决于 SSL/TLS 的完整性，无论. 客户端要么必须将密钥发送到服务器，要么相反，即使您使用公钥加密来解决这个问题，您仍然会遇到确保发送给客户端的公钥是真实的问题。您很可能最终只是重新实现了一个典型的公钥基础设施。

除此之外，在 JavaScript 中执行加密没有根本问题，除了：

• 按照大多数标准，它通常相当慢
• 生成加密安全密钥可能是一个问题，尤其是在不支持此任务的某些较新 API 的旧浏览器中

SSL/TLS是浏览器和服务器之间的加密层。只要您在服务器上正确配置了 SSL/TLS，任何额外的 javascript 类型加密都是多余的。

如果您正在尝试创建一个安全的应用程序，而您的团队不了解 SSL/TLS 的作用，您可能需要考虑聘请安全顾问来帮助您处理这些架构细节，并确保您避免任何陷阱。

你有没有想过在服务器端使用 SSL/TLS。因此数据将通过安全通道遍历。稍后在服务器端，您可以加密 ti 并将其以这种形式存储在数据库中

从 OP 的评论来看，这听起来对他们没有用，但是，它可能对其他人有用。

可以有效地加密信息客户端，但用例很少而且相差甚远。

示例用例：

1. 用户需要处理必须存储在本地的机密文件（至少根据他们的判断）（也许是为了降低服务器成本）
2. 他们工作的计算机没有受到其他用户的保护（足够）（即其他人可以打开他们的浏览器）
3. 但是，它足够安全，其他用户无法篡改操作系统、Web 浏览器或硬件。（听起来有些牵强，但可能类似于物理安全的共享信息亭机器）
4. 用户愿意在开始工作时输入密码。

在这种情况下，javascript 应用程序可以通过 TLS 交付。可以使用认为可以接受的任何两种加密方式对文档进行加密。密钥可以从用户密码中导出，并且只存储在内存中。如果上述任何一项都不是真正的 javascript 加密将是多余的，如下所示：

1. 如果文档可以存储在服务器上，那么 TLS 可以解决问题，并且服务器可以在必要时处理加密存储。
2. 如果只有所有者可以访问计算机，则文档可以仅存储在本地存储中。
3. 如果计算机是公共的，则可能会安装键盘记录器或恶意版本的浏览器，并且在这种情况下没有可行的安全措施。
4. 如果用户无需额外密码即可访问他们的工作，那么任何用户都可以访问他们的工作。