非对称密码:解密自己的消息而没有私钥

Question

我已经为我的网站建立了一个信息系统。用户可以发送被AES加密后存储在DB中的管理消息。

我认为使用非对称密码(通过openssl进行RSA)会更安全:在php源代码中没有解密密钥到硬编码。事实上，只有管理员才有私钥。

当我在PHP中创建已发送的文件夹功能时，问题就开始了。如果用户没有私密的管理密钥，他们如何解密自己发送的消息？

编辑！请告诉我，这种方法是否比在PHP:

中硬编码对称密钥更有效和更安全。

1)脚本生成用户密钥对从他的密码 (手动输入)

2) openssl_封口使用公钥(管理标准生成的发布密钥和用户密码派生的发布密钥)对消息进行加密。

3)脚本将结果存储在DB中。

4)当用户请求内容时，脚本重新派生用户密钥并解密。

5)当管理请求时，内容脚本使用标准生成的管理密钥并解密。

Answer 1

OpenPGP

处理此问题的标准方法是以标准OpenPGP格式存储加密消息。有什么理由不使用一些现成的库来实现RFC 4880和RFC 3156呢？

(对关于这个IT安全性的OpenPGP站点进行了大量的实际讨论，对StackExchange关于密码学的OpenPGP站点进行了更多的理论讨论)。

OpenPGP格式的加密消息可以存储为文件、SQL等。

详细信息

OpenPGP的工作原理与fin1te解释的完全一样(据我所知，openssl_seal()的工作方式也完全一样)：

• 对于每一条消息，系统都会生成一个新的、随机的会话密钥，其他人都无法猜测。在存储完整的加密消息BLOB之后，系统会立即忘记该密钥。
• 消息的明文用该会话密钥加密，并存储在BLOB内对称加密的数据包中。
• 几个加密的会话密钥包存储在BLOB中--每个BLOB包含该消息的会话密钥的另一个相同副本，每个都用不同的公钥加密。在这种情况下，一个副本用发件人的公钥加密，另一个副本用管理员的公钥加密。

当任何人(用户或系统管理员)想要读取加密消息时，该人将加密消息和她的密码发送给一段软件，该软件对其进行解密并显示明文。该软件通常：

• 将密码输入到密钥派生函数中。该软件使用生成的密钥对密钥环文件进行解密，以获得该用户的私钥及其相应的公钥。(或者，我认为可以使用密钥派生函数直接从密码生成私钥，然后从该私钥生成公钥)。
• 搜索BLOB中的所有加密会话密钥数据包，直到它找到一个具有匹配公钥的会话密钥包。
• 使用私钥解密会话密钥。然后使用会话密钥解密明文消息。

只要您避免通过HTTP或其他明文协议发送密码，这似乎是安全的，不受被动攻击(监视线路上的内容；读取服务器的备份磁带，包括所有公钥和管理员的加密密钥环)。

编辑：

我应该在哪里保存加密的键盘？

这是一个很好的问题，值得一页全新的问答。

在理想的世界中，您将给每个用户一个安全令牌，当第一次打开时，它会生成一个新的密钥，并给您一个公钥，但是私钥永远不会离开这个令牌。

在我们这个不太理想的世界里，许多人使用Gnome Keyring或一些类似的软件将加密的键盘存储在他们的个人笔记本或智能手机上，就像在“私钥存储的标准格式？”上讨论的那样。

我怀疑您会更喜欢这样一个系统，您不需要购买一堆安全令牌，用户仍然可以在您的服务器上访问他们自己的文件，即使他们的智能手机意外丢失、砖块或以其他方式被破坏。这几乎迫使您在服务器上存储加密的密钥环-- “这种客户端加密设计安全吗？”讨论了其中的一些含义。

Answer 2

如果使用对称算法(AES)加密消息，则存储此密钥两次--一次用管理员的公钥加密，另一次用用户公钥加密。

这样，当管理员想查看消息时，他会解密第一个密钥，用户使用第二个密钥。

Answer 3

我认为一个更好的问题是：“你想用这种加密来解决什么问题？”

在实践中，公开密钥加密是在不安全的通道上使用的，以确保数据完整性和不可抵赖性(消息是完整的、不变的，并且来自声称来自的消息)。可以想象，我认为在信息进入数据库之前对其进行加密的唯一原因是，数据库本身是一种不安全的媒体--我可以说，在保护数据之前保护媒体。

虽然如果您绝对打算使用公钥来保护这些信息，那么我会采取类似@fin1te所提出的方法。在两处加密消息，一次(在管理员的收件箱中)使用管理员的公钥，这样只有管理员才能读取；第二次(在用户的发送框中)对称地使用用户的密码作为AES密钥(或允许用户选择单独的加密密码)。这样，用户仍然可以访问，同时确保只有管理员可以访问发送给他的权限。

我要注意的唯一警告是，如果用户更改了密码，您将不得不遍历所有发送的消息，并使用新密码重新加密它们。

编辑:我没有看到你上面提议的算法中有任何数学上的缺陷，但在参考问题中还没有提到，但是要注意的是，OpenSSL_封口生成一个随机对称密钥，并使用所提供的公钥对进行加密。您还必须将该密钥存储在数据库中，以便能够逆转该过程。

您的反向过程如下所示：

1. 用户将扩展密码作为种子提供给PRNG。
2. 使用PRNG“种子”密钥生成方案恢复私钥
3. 使用派生私钥解密存储的对称密钥
4. 使用解密的非对称密钥解密消息。

总之，如果您在每次页面刷新时执行此操作，只需读取一些已发送的消息，那么这似乎是相当多的工作，而且计算成本很高。

既然openssl_seal无论如何都使用对称密钥，为什么不只是短路并使用用户的密码呢？