这里假设一下。您有一个高度敏感的文件,您不想公开,其他人也不想公开。为了降低被谋杀的可能性,您在 bittorrent 上发布了该文件的加密版本,并将加密密钥提供给受信任的各方(“密钥持有者”),并指示如果您被杀,请发布该文件。然后,您向公众宣布您发布的文件是真实的。(是的,我们谈论的是曼宁的情况。)
您想避免一个钥匙持有者受到威胁的可能性,并采取以下三项措施:
- 发布纯文本文档
- 使用您发布的身份验证声明让公众知道明文是真实的(即消除您的合理否认)
- 保持匿名
例如,这里有一种方法可以做到这一点。
- 创建 N 个对称密钥,每个密钥持有者一个
- 对于每个密钥持有者,复制一份明文,并在其前面加上“本文档由以下人员发布:”以及该密钥持有者的身份
- 使用相应的对称密钥加密每个副本
- 分别分配密钥
- 发布完整文件
但这需要N * size_of_plaintext
空间。这个问题问的是有没有更有效的方法。
首先,我研究了 gpg 多密钥加密。请参阅https://stackoverflow.com/questions/597188/encryption-with-multiple-different-keys(感谢@terdon)。GPG 的工作原理如下:
gpg --encrypt --recipient [email protected] --recipient [email protected] doc.txt
- GPG 选择对称密钥(
X
) - GPG 使用以下方式加密纯文本
X
- GPG
X
使用方密钥加密P_alice
,,P_bob
... 并且 Alice、Bob 等可以分别解密其中一个
这很容易受到我们想要避免的攻击:
- Bob 使用
P_bob
解密X
- Bob
X
匿名发表 - 公众可以使用以下方法解密你发布的明文
X
答案1
您可以发布合适的放预先对明文进行加密哈希处理。例如,通过发布[MD5,SHA-1-160,SHA-3-512,RIPEMD-320] 明文的哈希值,任何人都可以找到与所有这些哈希值正确匹配的明文同时地会非常困难。请注意,这种攻击比第一次或第二次攻击要困难得多原像攻击针对所涉及的任何一种哈希算法,因为相同的数据必须散列到正确的值全部涉及的算法和阅读时有意义。此外,根据维基百科目前至少没有发现比暴力破解更好的攻击方式针对整个输出空间,虽然 MD5 的碰撞攻击复杂度为 2^21,但原像攻击仍为 2^123,这仅比对其整个输出空间 2^128 的全面攻击稍微简单一些。(基本上,碰撞攻击是指您可以选择两个输入,并寻找一对不同的输入,它们产生相同的哈希值,使得一个输入的哈希值对另一个输入也有效;原像攻击是指您有哈希值,并正在寻找一些输入,最好是与原始输入不同的输入,从而产生给定的哈希值。)这些哈希值本身并不能说明任何有关明文数据的信息。
为了进一步复杂化攻击,你可以使用至少一种不基于Merkle-Damgård 构造使用传统的压缩函数(上面列出的哈希算法,可能除了 SHA-3 之外)进行压缩,如果存在这样的算法;我不知道有任何一种,但这并不排除这种可能性。显然,Keccak/SHA-3 使用的设计至少在某些部分有所不同,这似乎使其成为纳入此类哈希算法集的良好候选者。
这给某人在稍后的某个时间点收到一份纯文本文件的副本,以验证它是否与您打算在您发生意外时公开的内容相匹配。为了让该人高度确信纯文本是真实的,该人只需相信这些哈希值的来源是真实的(并且他们自己的哈希值副本没有被篡改,这可以通过使用防篡改密封以明显低技术的方式完成),并且用于在其计算机上计算哈希值的软件可以按预期运行(在某种程度上,可以通过使用多个单独的实现并根据已发布的测试向量测试这些实现来独立验证)。
然而,我不认为你能真正追究泄露解密密钥的人的责任 无需分发多个不同加密的明文副本。任何不需要为每个明文块和接收方密钥提供单独的加密数据块的多密钥加密方案都要求使用给定密钥对明文进行加密,K_0
然后依次使用一组接收方密钥对明文进行加密,对于接收方,K_1
完整的加密主密钥集包含在密文中。(如果您不想这样,则需要为每个明文提供多个密文,这会增加攻击者的攻击面,如果您的名字是 Manning 或 Snowden,则这是一个值得关注的问题。)因此,每个收件人都必须能够访问“主”解密密钥,这正是您想要防范的情况。K_n
n
E(using K_n)(K_0)
K_0
我能想到的唯一方法是使用像 DES 这样的算法(在我提到这个老古董之前,请继续阅读),它允许在密钥材料中使用未使用的奇偶校验位,为每个收件人设置唯一的奇偶校验位,并记录每个密钥收件人的奇偶校验位。(由于您将独立于剩余的密钥材料设置这些“奇偶校验”位,而不是将其设置为实际奇偶校验,并且这些位对安全性没有影响,因此不会降低安全性。)为了合理的安全性,可以使用如下方案3DES加密可以使用。但是,任何能够访问密文、了解算法并具有一些密码学知识的人都知道或能够轻松找到加密算法的这一属性,并且可以在发布解密密钥之前将未使用/奇偶校验位设置为他们想要的任何值,从而否定任何可能的问责措施,并可能将矛头指向其他人。
请注意,以上这些都不要求使用对称(或非对称)加密。虽然只使用对称算法的方法可能比只使用非对称算法的方法更实用,但两者都可以完全实现。更轻松(在解决密钥分配问题的意义上)等等实际的(例如,就密文大小而言)对数据使用对称加密,然后对解密密钥使用非对称加密——这是非对称加密通常完成的方式——但没有任何东西可以绝对有要这样做,您仍然需要能够以某种方式信任您正在加密解密密钥的公钥。
答案2
如果 Alice 确实提出了这样的主张,你会希望其他人能验证这一说法。我一直认为公钥加密在身份验证方面没有多大用处,但如果你以某种方式引入数字签名之类的东西,你就可以验证文档的真实性,这将解决问责问题。
由于您使用 gpg,所以我认为这里描述的内容类似:http://www.tutonics.com/2012/11/gpg-encryption-guide-part-3-digital.html
当发送者使用公钥为收件人加密数据时,收件人如何知道发送者是否确实是他们所说的那个人?
公钥可供任何人使用,因此需要有一种方式让发送者明确证明数据来自他们。GPG 提供了一种方法来实现上述目的,同时生成数据的签名(如指纹),以证明数据未被篡改。
答案3
不要发布加密文件本身,而要发布公钥的副本。然后向每个受信任的密钥持有者提供文档的纯文本副本,以及一份由您本人加密签名的声明(使用您刚刚发布的公钥的相应私钥),该声明既可以证实文档的合法性(例如,包括文档的哈希值),也可以提及您将向其提供此声明的密钥持有者的姓名。
这样,您的任何密钥持有者都可以泄露纯文本文档;但为了证明其合法性,他们必须透露您签署的声明的版本,从而揭示他们的身份。
为了进一步保护,你可以使用以下方法加密提供给每个密钥持有者的明文文档,并在密钥持有者之间分配密钥:沙米尔的秘密分享算法。这样,任何个人密钥持有者都无法在不与一个或多个其他密钥持有者合作的情况下读取或泄露敏感文件的内容。使用此方案,您可以要求任意数量的合作密钥持有者才能将文档发布给公众,但只有其中一名密钥持有者必须透露其身份才能验证文档的合法性。