关于加密和密码学的经验教训和误解

Question

密码学是一门非常广泛的学科，即使是经验丰富的程序员也几乎总是会在最初几次出错。然而，加密是一个非常重要的话题，我们常常无法承受这些错误。

这个问题的目的是识别并列出与给定的算法或API不相关的内容。这样我们就可以从别人的经验中吸取教训，防止不良行为的蔓延。

为了保持这个问题的建设性，请

1. 包括一个“错误”的例子
2. 解释一下这个例子有什么问题
3. 提供正确的实现(如果适用)。
4. 尽你所能，提供关于上面第2和#3的参考资料。

Answer 1

不要翻动自己的密码。

不要发明自己的加密算法或协议，这是非常容易出错的。就像布鲁斯施耐尔喜欢说的，

“任何人都可以发明一种他们自己无法破解的加密算法；要发明一种无人能破解的加密算法要难得多。”

密码算法非常复杂，需要经过密集的审查才能确保它们是安全的；如果你发明了自己的密码算法，你就不会得到它，而且很容易在没有意识到的情况下导致某种不安全的结果。

相反，使用标准的加密算法和协议。很可能是其他人曾经遇到过你的问题，并为此目的设计了一个合适的算法。

最好的情况是使用高级别的经过良好审查的方案:对于通信安全，使用TLS (或SSL)；对于静止的数据，使用GPG (或PGP)。如果您不能这样做，请使用高级密码库，如密码库、GPGME、凯沙尔或NaCL，而不是像OpenSSL、CryptoAPI、JCE等低级密码库。感谢内特·劳森的建议。

Answer 2

不使用没有消息身份验证的加密

加密数据而不对其进行身份验证是一个非常常见的错误。

开发人员想要保密消息，所以使用AES-CBC模式对消息进行加密。错误:在存在活动攻击、重放攻击、反应攻击等情况下，这不足以保证安全性。在没有消息身份验证的情况下，对加密的攻击是已知的，而且攻击可能相当严重。修复方法是添加消息身份验证。

此错误导致在未进行身份验证的情况下使用加密的已部署系统存在严重漏洞，这些系统包括ASP.NET、XML 加密、亚马逊EC2、JavaServer Faces，Rails，OWASP、IPSEC、WEP、ASP.NET再一次和SSH2。你不想成为这个名单上的下一个。

为了避免这些问题，每次应用加密时都需要使用消息身份验证。对于如何做到这一点，您有两个选择：

• 最简单的解决方案可能是使用提供认证加密的加密方案，例如GCM、CWC、EAX、CCM、OCB。(另见：1.)通过身份验证的加密方案为您处理此问题，因此您不必考虑它。
• 或者，您可以应用您自己的消息身份验证，如下所示。首先，使用适当的对称密钥加密方案(例如AES-CBC)对消息进行加密.然后，获取整个密文(包括任何IVs、nonces或解密所需的其他值)，应用消息身份验证代码(例如，AES-CMAC、SHA1-HMAC、SHA1 256-HMAC)，并在传输前将结果MAC摘要附加到密文中。在接收端，在解密之前检查MAC摘要是否有效。这就是所谓的加密然后认证结构。(另见：1，2.)这也很好，但需要你更多的关心。

Answer 3

在连接多个字符串时要小心，然后再散列.

我有时会看到一个错误:人们想要一个字符串S和T的散列，他们把它们连在一起得到一个字符串S\T，然后再散列得到H。这是有缺陷的

问题是:连接使两个字符串之间的边界变得模糊。示例：builtin而今(securely)=built\##*$}insecurely。换一种说法，散列H(S_例如，如果Alice想发送两个字符串builtin和securely，攻击者可以将它们更改为两个字符串built和insecurely，而不会使哈希无效。

在将数字签名或消息身份验证代码应用于字符串连接时，也会出现类似的问题。

修复:而不是简单的级联，使用一些明确可解码的编码。例如，不需要计算H(S_~_或者，另一种可能是使用H(H(S)_x_H(T))，甚至是H(H(S)_x_(T))。

有关此缺陷的真实示例，请参阅亚马逊服务中的此缺陷或Flickr中的这个缺陷 pdf格式。