知识就是力量。换句话说，如果用户必须能够执行某些操作而其他人不应该能够执行相同的操作，那么必须有一些只有用户知道的值（“键”），其他人都不知道。

此外，使用价值必然意味着手头有该价值；当您使用密钥解密时，至少只要您解密，您就拥有该密钥。如果密钥必须只有用户知道，那么这意味着解密只能在用户独占控制的系统上进行。简而言之，解密必须发生在用户的机器上（桌面系统、笔记本电脑、平板电脑……），而不是任何不应该看到密钥的系统（例如您的服务器）上。

因此，您有两个问题需要解决：

• 如何存储密钥以便用户可以访问它，但只有该用户可以访问它。
• 如何以您无法轻易规避的方式在客户端系统上进行解密。

第一个问题可以使用本地文件或存储区域来解决。在某种程度上，你可以帮助客户端进行一些服务器端存储和基于密码的加密：如果你有一些数据D，那么你可以在服务器上存储E _p ( D )，这是对D的加密服务器不知道的密码p 。一般而言，基于密码的加密很难；首先阅读这个答案。在该模型中，真正特定于用户的知识是密码p，用户在他的脑海中传输该密码。

第二个问题更成问题。您不会在纯 JavaScript 中（在 Web 上下文中）解决它，因为客户端执行的任何 JavaScript 都将由您的服务器发送，因此您的服务器始终具有发送一次恶意 JavaScript 的概念能力，该恶意 JavaScript 会抓取密码/密钥/任何内容并将其发送回给您。我想您在这里的问题不仅是让用户能够单独解密数据，而且还要如此令人信服地做到这一点，即能够向第三方证明您确实无法访问数据。在最好的情况下，这很困难。一种可能的策略是让客户端使用一些可以处理解密并由您签名的本地应用程序代码，并且易于逆向工程（这里想到 C#/.NET 和 Java）。如果有这样的客户端应用程序，那么您可以声称您不能谨慎地掠夺用户的数据，因为这将需要在他们的系统上推送恶意应用程序，稍后可能会对其进行逆向工程，从而使您的签名入罪。

在没有这种本地应用程序的纯 Web 中，算了。Java 小程序模型本来可以应用，但在实践中很难做到，因为现在支持 Java 小程序的人并不多（而且 .NET+SilverLight 的部署更不广泛）。