为什么你需要大量的随机性来实现有效的加密?

随机性意味着输入不可测。如果输入是可猜测的,那么输出就可以很容易地计算出来。这太糟糕了。

例如,Debian在其SSL实现中有一个长期存在的错误,在创建密钥时未能收集到足够的随机性。这导致软件生成了32k个可能密钥中的一个。因此,通过尝试所有32k的可能性,可以很容易地解密用这种密钥加密的任何东西,考虑到当今的处理器速度,这是非常快的。

大多数加密操作的重要特征是,如果你有正确的信息(例如密钥),它们很容易执行,如果你没有这些信息,它们就不可行。

例如,对称密码学:如果你有密钥,加密和解密就很容易。如果你没有密钥(也不知道它的构造),那么你必须着手进行一些昂贵的工作,比如对密钥空间进行详尽的搜索,或者对密码进行更有效的密码分析,尽管如此,这仍需要大量的样本。

另一方面,如果你有关于密钥可能值的任何信息,那么你对密钥空间的详尽搜索就容易得多(或者你进行密码分析所需的样本数量要少得多)。例如,(目前)不可能执行2^128次尝试解密来发现128位密钥的实际内容。如果你知道密钥材料来自你在十亿个滴答内知道的时间值,那么你的搜索就变得简单了340282366920938463463374607431倍。

要解密消息,您需要知道正确的密钥。

您尝试的密钥越多,解密消息就越困难。

举一个极端的例子,假设根本没有随机性。当我生成用于加密消息的密钥时,我将 总是 最终得到完全相同的密钥。无论我在何时何地运行密钥生成程序,它都会给我相同的密钥。

这意味着任何有权访问我用来生成密钥的程序的人都可以轻松解密我的消息。毕竟,他们只需要让它也生成一个密钥,他们就会得到一个与我使用的密钥相同的密钥。

因此,我们需要一些随机性,使其无法预测您最终使用的密钥。正如David Schmitt所提到的,Debian有一个错误,它只生成了少量的唯一密钥,这意味着要解密Debian上默认OpenSSL实现加密的消息,我只需要尝试这少量的可能密钥。我可以忽略大量其他有效密钥,因为Debian的SSL实现永远不会生成这些密钥。

另一方面,如果密钥生成中有足够的随机性,则无法猜测 任何事物 关于钥匙。你必须尝试所有可能的比特模式。(对于128位密钥,有很多组合。)

这与密码学的一些基本原因有关:

• 确保消息在传输过程中没有被更改(不可变)
• 确保邮件在传输过程中未被读取(安全)
• 确保信息来自它所说的人(真实)
• 确保消息与之前发送的消息不同(无重播)
• 等等

那么,你需要包括一些事情来确保上述内容是正确的。重要的一点是随机值。

例如,如果我用密钥加密“太多秘密”,它可能会输出“dWua3hTOeVzO2d9w”

这有两个问题——攻击者可能更容易破解加密,因为我使用的字符集非常有限。此外,如果我再次发送相同的消息,它将完全相同。最后,攻击者可以记录它,并再次发送消息,即使攻击者没有破坏它,收件人也不会知道我没有发送它。

如果每次加密字符串时都添加一些随机垃圾,那么不仅会使破解变得更加困难,而且每次加密的消息都是不同的。

上述项目符号中的密码学的其他特征是使用随机性以外的方法(种子值、双向身份验证等)固定的,但随机性解决了一些问题,并有助于解决其他问题。

一个糟糕的随机性来源再次限制了角色集,因此更容易破解,如果很容易猜测或受到其他限制,那么攻击者在进行暴力攻击时尝试的路径就会更少。

-亚当

密码学中的一种常见模式如下(从alice向bob发送文本):

Take plaintext p
Generate random k
Encrypt p with k using symmetric encryption, producing crypttext c
Encrypt k with bob's private key, using asymmetric encryption, producing x
Send c+x to bob
Bob reverses the processes, decrypting x using his private key to obtain k

这种模式的原因是对称加密比非对称加密快得多。当然,这取决于一个好的随机数生成器来产生k,否则坏人只能猜测它。

这里有一个“纸牌游戏”的类比:假设我们用同一副牌玩几轮游戏。回合之间甲板的洗牌是随机性的主要来源。如果我们没有正确洗牌,你可以通过预测牌来击败比赛。

当您使用较差的随机性源来生成加密密钥时,可以显著降低密钥值的熵(或不确定性)。这可能会危及加密,因为它使在密钥空间上进行暴力搜索变得更加容易。

this 这个问题来自欧拉项目,它将真正让你明白“很多随机性”会为你做什么。当我看到这个问题时,这是我脑海中闪过的第一件事。

使用他在那里谈到的方法,你可以很容易地看到“更多的随机性”会给你带来什么。

• http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html

这描述了早在1995年,Netscape浏览器的密钥SSL实现就容易因PRNG种子问题而猜测SSL密钥。