注意：这个问题特定于Threema Messenger，并且与他们的加密实现有关（根据他们的文档使用NaCl ECDH实现）。
我在他们网站上的验证文件中特别提到了他们的“关于传出消息的注释” ：
通过输入发件人的私钥和收件人的公钥（即不知道收件人的私钥）可以解密传出消息，这似乎很奇怪。...
现在，考虑这种情况：
有了 Bob 的密钥和流量，Eve 现在可以解密 Bob 发送给 Alice 的所有内容吗？
换句话说，对于 Threema，接收内容的隐私是否取决于 SENDER 的私钥的安全性？
对于 Diffie-Hellman 密钥交换，如果使用相同的密钥对，则创建的共享密钥将相同。这意味着如果 Eve 掌握了发送者或接收者的私钥，那么他们就可以计算共享秘密并解密 Alice 和 Bob 之间所有过去和未来的消息。解决此问题的常用方法是使用临时密钥，以便共享密钥仅对该特定会话有效。
然而，对于 Theema，他们决定不在端到端加密中使用临时密钥，而是只确保传输层上的前向保密，如他们的加密白皮书中所述。他们陈述的理由是：
在发送者和服务器之间或服务器和接收者之间通过 Internet 窃听任何路径的风险比窃听服务器本身的风险大几个数量级
因此，要直接回答您的问题，对于 Theema 的消息，只有传输层上的转发安全性，因此如果攻击者拥有加密的消息以及发送者或接收者的私钥，那么他们就可以对其进行解密。
问题一：
有了 Bob 的密钥和流量，Eve 现在可以解密 Bob 发送给 Alice 的所有内容吗？
是的。
它是关于“前向保密”的，它取决于 Threema 如何管理会话密钥。（来自维基百科：“前向保密保护过去的会话免受未来密钥或密码的泄露。”）
有两点需要考虑：
由于移动信使固有的异步特性，在端到端层上提供可靠的前向保密是很困难的。新聊天会话的密钥协商将要求对方在发送第一条消息之前在线......由于这些和以下考虑，Threema仅在传输层实现了前向保密
用于密钥派生的盐。
crypto_box_open()根据验证底漆在此处使用，该底漆生成具有以下默认盐的密钥：static const unsigned char sigma[16] = "expand 32-byte k";
static const unsigned char n[16] = {0};
最后，通过以下伪公式计算加密密钥：
KEY = HSALSA20(DH(privkey, pubkey), n, sigma);
这意味着端到端加密的密钥在 Threema 中的 Alice 和 Bob 之间永远不会改变。
问题2：
接收内容的隐私是否取决于 SENDER 的私钥的安全性？
是的。
尽管我会说这是一个更广泛的问题：无论如何，当私钥被泄露时，隐私也会受到损害。如果 RECEIVER 的私钥被泄露，则接收到的内容也可以被第三方解密（密钥 = 接收者的私钥 * 发送者的公钥）。
“捕获网络流量的攻击者即使事后发现了客户端或服务器的长期密钥，也无法解密。”