我编写了一个简短的C++程序，用于对文件进行异或加密，用于一些个人文件（如果它被破解也无大碍 - 我只是在保护免受偶然查看者的侵犯）。基本上，我取得一个ASCII密码，并重复使用该密码与文件中的数据进行异或运算。
现在我很好奇：如果有人想要破解这个加密，他们会怎么做？这需要很长时间吗？这取决于密码长度吗（即，它的大O复杂度是什么）？
14个回答
129
XOR加密的问题在于，对于长时间重复出现的字符，很容易看出密码。这种长时间重复的字符在文本文件中最常见的是空格。假设你的密码是8个字符，在某行中有16个空格（例如在ASCII图形表的中间），如果你只用这个密码进行XOR加密，你会发现输出会有重复的字符序列。攻击者只需要寻找任何这样的序列，尝试猜测原始文件中的字符（空格将是首选），并从重复组的长度推导出密码的长度。
二进制文件可能会更糟，因为它们经常包含重复的0x00字节序列。显然，使用这些字节进行XOR加密没有任何效果，所以你的密码将以明文形式显示在输出中! 一个具有长时间空字符序列的非常普遍的二进制格式的例子是.doc。
- Pavel Minaev
5
14请注意，使用空格字符对整个文件进行异或运算几乎是微不足道的，此时任何明智的字符串都可能成为可能的密码。对于用ASCII字符串进行异或运算的二进制文件，在结果中的任何字符串都是密码。在shell提示符下，strings命令可以找到它们。 - RBerteig
44顺便提一下，如果“密钥”小于明文时，你应该清楚地表明你正在谈论的是一个异或方案。如果密钥与明文大小相同，并且“真正”的随机（至少从攻击者的角度来看），那么它就是一次性密码本；也就是不可破解的。 - Noon Silk
好的解释。但是如果密码与明文长度相同，XOR不能更加安全吗？ - rvighne
3是的，如果你有一次性密码本（相同长度且具备加密质量的随机数），那么使用异或加密是完全可行的。 - Pavel Minaev
@NoonSilk - 你是否知道任何方法，可以将一个小密码输入到密钥派生函数中生成与明文大小相同的密钥？这样做会使XOR操作安全且快速吗？虽然KDFs很慢，但如果想要生成1MBit大小的密钥，是否可以减少KDF的迭代次数并保持安全性？ - Lord Loh.
73
我同意Pavel Minaev对XOR弱点的解释。对于那些感兴趣的人，这里有一个基本概述标准算法是如何在短短几分钟内破解简单的XOR加密：
确定密钥长度。通过将加密数据与不同位移的自身进行XOR运算，并检查有多少字节相同来实现此操作。
如果相等的字节大于某个百分比（根据Bruce Schneier的应用密码学第二版，为6%），则表示您已经将数据按密钥长度的倍数移位。通过找到导致大量相等字节的最小移位量，您可以找到密钥长度。
将密文按密钥长度移位，并进行XOR运算。这将去除密钥并使您拥有明文与移位后密钥长度的明文XOR。应该有足够的明文来确定消息内容。
阅读更多信息，访问加密问题，第1部分
- GeneQ
2
1你能解释一下第三部分吗？我尝试过了，但好像不起作用。例如，如果我使用十进制数字进行操作。明文是23456，密钥是12，加密后得到31577，然后进行异或运算会得到无意义的结果。 - user1174868
3请注意，截至2020年2月7日，似乎http://www.kuro5hin.org/?op=displaystory&sid=2000/4/10/174741/423这个网址不再可用，该域名似乎正在出售。但是，您可以在WayBack Machine（互联网档案馆）上找到原始文章，网址为Encryption Matters, Part 1。 - Jonathan Leffler
26
XOR加密的强度可以比较强，如果满足以下条件：
- 明文和密码长度大致相同。
- 密码不会被重复使用于加密多条消息。
- 密码无法被猜测，例如不能通过字典或其他数学方式进行推理。实际上，这意味着位数必须是随机的。
“比较强”指的是它不能被轻易地、通过数学手段破解，就像GeneQ在帖子中所示。但它的强度仍然不如您的密码。
- SingleNegationElimination
3
7一次性密码本需要的密钥长度必须与明文长度相同。当这个条件满足，并且密钥从未被复用，一次性密码本就是绝对安全的。如果你对密码学的历史感兴趣，我强烈推荐读David Kahn的《破译密码》（The Codebreakers）：http://www.amazon.ca/Codebreakers-Comprehensive-History-Communication-Internet/dp/0684831309 - Dale Hagglund
11“reasonably secure”翻译为“相对安全”。一次性密码本只要是完全随机的，就无法通过任何手段破解，它们是唯一绝对安全的加密方法。 - BlueRaja - Danny Pflughoeft
7一次性密码本并不是绝对安全的，它只有在加密端和解密端分享密码本的方法足够安全时才能保证安全。 - Russell Borogove
15
除了已经提到的要点，XOR加密完全容易受到已知明文攻击的威胁：
cryptotext = plaintext XOR key
key = cryptotext XOR plaintext = plaintext XOR key XOR plaintext
通过异或明文可以相互抵消，只留下密钥。
不易受已知明文攻击是任何“安全”加密方法的必要但不充分条件，其中使用相同密钥进行多个明文块的加密（即一次性密码仍然是安全的）。
- laalto
1
8值得一提的是，即使已知文件的一个小部分（比如大多数文件格式使用的标头），密钥也可以轻松获取并解密整个文件。 - BlueRaja - Danny Pflughoeft
9
XOR加密的方法：
使用多个密钥，每个密钥的长度都是质数，但不要使用相同长度的密钥。将原始文件名作为另一个密钥，但要记得创建一个检索文件名的机制。然后创建一个带有扩展名的新文件名，以便您知道它是加密文件。
使用质数长度的多个密钥的原因是，它们使得结果XOR密钥在重复之前的长度为密钥A乘以密钥B。
在加密文件之前，将任何重复的模式压缩掉。
生成一个随机数，并在每个X偏移量处进行XOR操作（请记住，这个数字也必须可再现。您可以使用文件长度的随机种子）。
如果使用31位及以上的5个密钥，则最终得到的密钥长度约为100兆！
密钥包括：文件名（包括完整路径），文件大小+文件日期+日期+时间，随机生成的密钥，您的全名，仅创建一次的私钥。
使用一个数据库来存储用于加密每个文件的密钥，但将DAT文件保存在USB存储器中而不是计算机中。
这应该可以防止像图片和音乐这样的文件中的重复模式，但是长度为四个Gig或更长的电影可能仍然容易受到攻击，因此可能需要第六个密钥。
我个人将DAT文件本身加密在存储器中（使用Microsoft Access的Dat文件）。我使用了3个密钥的方法来加密它，因为它永远不会那么大，只是一个带有相关密钥的文件目录。
与其随机生成一个非常大的密钥，不如使用多个密钥，因为质数乘以质数很快就会变得非常大，而我可以控制密钥的创建。而且你知道真正不存在完全随机的数字。如果我创建了一个大的随机数，其他人也可以生成相同的数字。
使用密钥的方法：使用一个密钥加密文件，然后使用下一个密钥，直到所有密钥都被使用。每个密钥都会一遍又一遍地使用，直到整个文件都用该密钥加密。
由于密钥的长度不同，重复的重叠对于每个密钥都不同，因此创建一个派生密钥，其长度为键一次键二的长度。这个逻辑对于其余的密钥也是如此。使用质数的原因是重复会发生在密钥长度的除数上，因此您希望除数为1或密钥长度，因此选择质数。
好吧，承认，这不仅仅是简单的文件XOR，但概念是相同的。
Lance
- Lance Summers
6
我只是在保护普通观众
只要这个假设成立，你的加密方案就可以了。认为Internet Explorer就是“互联网”的人是不可能破解它的。
如果不行，就使用一些加密库。已经有很多好的算法，如Blowfish或AES用于对称加密。
- John Smith
2
另一个技巧是为您的密码生成 md5() 哈希值。您可以使用受保护文本的长度作为偏移量，或将其与您的密码结合使用，以提供更好的短语分布并使其更加独特。对于长短语，通过将每个 16 字节块与前一个哈希值组合来演变您的 md5() 哈希值——使整个异或密钥“随机”且不重复。
- Phil M
2
以前的诺顿反病毒软件使用了一种技巧，即将上一个未经加密的字母作为下一个字母的密钥。我回忆起来，花了我额外半个小时才想明白。
如果你只是想阻止普通用户查看，那么这已经足够了；我曾经用它来隐藏可执行文件内的字符串。然而，对于任何真正尝试的人来说，它都无法经受10分钟左右的时间。
总之，现在有更好的加密方法可供选择，为什么不使用更好的东西呢？如果您只是想隐藏在“普通”用户的视线中，甚至像gzip这样的东西也可以更好地完成这项工作。
- Chris Arguin
1
RC4本质上是异或加密！许多流密码也是如此-关键是关键（无恶意的双关语！）您绝不能重复使用密钥。永远不要！
- Michael Howard-MSFT
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接