我有一个可能有用的应用程序的想法（尽管如果不是，我仍然在这个过程中学到了，这很重要）。
有一堆加密的 pastebin Web 应用程序（例如 defuse.ca/pastebin.htm）使用 JavaScript 在客户端上执行加密/解密。这样就实现了端到端加密，除非有人入侵服务器并修改 JavaScript，以便未来连接的用户获得修改后的 JavaScript 代码，从而将未加密的密码泄露给黑客。
我的想法是用户应该与独立的客户端应用程序而不是浏览器应用程序进行交互，以消除 JavaScript 漏洞。
- 用户下载客户端独立应用程序。在下载/安装期间提供了一些安全性，因为：客户端应用程序经过数字签名 b. 下载发生在 https 服务器 c. SHA 哈希可用于下载的文件 d。客户端应用程序的源代码可用
- 用户启动应用程序并选择“新粘贴”。他看到一个大文本框。
- 用户键入/粘贴文本并单击“提交”。提示用户输入密码并输入。
- 客户端应用 CSPRNG 生成 128 位 salt S。
- 慢推导函数以密码和S为参数，推导256位密钥K和128位初始化向量IV。
- 使用明文、K 和 IV 执行 Aes 加密（128 位块大小、256 位密钥、CBC 模式、PKCS7 填充）以生成密文 C。
- 客户端应用程序调用服务器（对 https uri 的其余调用），将其传递给 S 和 C。
- 服务器将 S 和 C 存储在数据库行中（S 是主键）。
- 服务器告诉客户端数据已存储。客户端告诉用户“数据已保存”并将 S 作为唯一的粘贴标识符呈现给用户。
- 用户记下 S（他的计算机上的文本文件、给自己的电子邮件等……不必保密）。密码必须保密。
- 稍后，用户再次启动客户端应用程序。
- 他选择“打开现有粘贴”。他输入 S 并选择查找。
- 客户端应用程序要求服务器查找匹配 S 的粘贴（对 https uri 的其余调用）。如果是，则返回加密文本。
- 如果找到粘贴，客户端应用程序会提示用户输入解密密码。他输入。
- 慢推导函数以密码和S为参数，推导256位密钥K和128位初始化向量IV。
- 使用明文、K 和 IV 执行 Aes 解密（128 位块大小、256 位密钥、CBC 模式、PKCS7 填充）以生成明文。
- 客户端应用程序将纯文本放入框中。用户可以更改它并重新加密或关闭它并重新粘贴（返回步骤 2）。
笔记：
- 在以下情况下，多个用户可能会查看相同的粘贴：他们事先就密码达成一致，或者在用户 1 粘贴后将密码从用户 1 传递给用户 2，并且 b。进行粘贴的用户与其他用户共享 S（这可能不安全地共享）。
问题：
- 此设置有哪些安全漏洞，如何改进？
- 就用户体验而言，我是否遗漏了任何重要的东西？
- 回复：第 17 步。我读到你不应该两次使用相同的盐。每次修改/重新加密都会更改粘贴 (S) 的标识符会很烦人（如果多个用户正在访问同一个粘贴，他们需要在每次更新/重新加密时重新传达新的 S），但它是如果我不想牺牲安全性，这是不可避免的吗？
提前致谢！