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

#1 楼

不要发明自己的加密算法或协议；那是极容易出错的。正如Bruce Schneier所说，


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


加密算法非常复杂，需要进行严格审查才能确保其安全性；如果您发明了自己的产品，那么您将一事无成，并且很容易在没有意识到的情况下得到一些不安全的东西。相反，请使用标准的加密算法和协议。可能是其他人之前曾遇到您的问题，并为此目的设计了合适的算法。

最好的情况是使用经过严格审查的高级方案：为实现通信安全，请使用TLS（或SSL）；对于静态数据，请使用GPG（或PGP）。如果您不能做到这一点，请使用诸如cryptlib，GPGME，Keyczar或NaCL之类的高级加密库，而不要使用诸如OpenSSL，CryptoAPI，JCE等之类的低级库。感谢Nate Lawson的帮助建议。

#2 楼

在没有消息身份验证的情况下不要使用加密

在不对数据进行身份验证的情况下加密数据是一个非常常见的错误。

示例：开发人员希望对消息保密，因此使用AES-CBC模式加密消息。错误：在存在主动攻击，重播攻击，响应攻击等情况下，这不足以确保安全。存在已知的未经消息身份验证的加密攻击，这些攻击可能非常严重。解决方法是添加消息身份验证。

此错误已导致在使用未经身份验证的加密的已部署系统中出现严重漏洞，包括ASP.NET，XML加密，Amazon EC2，JavaServer Faces，Ruby on Rails， OWASP ESAPI，IPSEC，WEP，再次为ASP.NET和SSH2。您不想成为此列表中的下一个。

为了避免这些问题，每次应用加密时都需要使用消息身份验证。您有两种选择方法：


最简单的解决方案可能是使用提供经过身份验证的加密的加密方案，例如GCM，CWC，EAX，CCM，OCB。 （另请参见：1.）经过身份验证的加密方案可以为您解决此问题，因此您不必考虑它。
或者，您可以按照以下方式应用自己的消息身份验证。首先，使用适当的对称密钥加密方案（例如AES-CBC）对消息进行加密。然后，获取整个密文（包括解密所需的任何IV，随机数或其他值），应用消息身份验证代码（例如AES-CMAC，SHA1-HMAC，SHA256-HMAC），并将生成的MAC摘要附加到传输前的密文。在接收端，解密之前请检查MAC摘要是否有效。这称为加密然后认证结构。 （另请参见：1、2。）这也可以正常工作，但需要您多加注意。

#3 楼

在哈希之前连接多个字符串时要小心。我有时会看到一个错误：人们想要对字符串S和T进行哈希处理。他们将它们连接起来以获得单个字符串S || T，然后进行哈希处理它得到H（S || T）。这是有缺陷的。

问题：串联使两个字符串之间的边界不明确。例如：builtin || securely = built || insecurely。换句话说，哈希H（S || T）不能唯一地标识字符串S和T。因此，攻击者可以在不更改哈希的情况下更改两个字符串之间的边界。例如，如果爱丽丝想发送两个字符串builtin和securely，则攻击者可以将它们更改为两个字符串built和insecurely而不会使哈希无效。

应用数字签名或消息时也会遇到类似的问题。修正代码：将验证码转换为字符串的串联。

解决方法：使用简单可解码的编码，而不是简单的串联。例如，代替计算H（S || T），您可以计算H（length（S）||| S || T），其中length（S）是32位值，表示S的长度（以字节为单位）。或者，另一种可能性是使用H（H（S）|| H（T）），甚至使用H（H（S）|| T）。

关于此示例的真实示例缺陷，请参阅Amazon Web Services中的此缺陷或Flickr [pdf]中的此缺陷。

#4 楼

确保您为具有足够熵的随机数生成器提供种子。

确保使用加密强度的伪随机数生成器进行诸如生成密钥，选择IV /随机数等操作。请勿使用rand()，random()， drand48()等。

确保您为伪随机数生成器提供了足够的熵。不要在一天中的任何时候播种。

示例：srand(time(NULL))非常糟糕。播种PRNG的一个好方法是从例如/dev/urandom，CryptGenRandom或类似的地址中获取128位或真随机数。在Java中，请使用SecureRandom，而不要使用Random。在.NET中，请使用System.Security.Cryptography.RandomNumberGenerator，而不要使用System.Random。在Python中，请使用random.SystemRandom，而不是random。感谢Nate Lawson的一些示例。

真实示例：在早期版本的Netscape浏览器中看到此漏洞，攻击者可以利用它破坏SSL。

#5 楼

不要重用随机数或IV

许多操作模式都需要IV（初始化向量）。您绝不能为IV重复使用相同的值。这样做会取消所有安全保证，并导致灾难性的安全破坏。


对于流密码操作模式（例如CTR模式或OFB模式），重新使用IV是安全的灾害。
对于其他操作模式，例如CBC模式，重新使用IV在某些情况下还可以促进明文恢复攻击。

否无论使用哪种操作模式，都不应重复使用IV。如果您想知道如何正确执行操作，NIST规范提供了有关如何正确使用分组密码操作模式的详细文档。

Tarsnap项目提供了一个很好的例子来说明这种陷阱。 Tarsnap通过将备份数据分成多个块来加密，然后在CTR模式下使用AES加密每个块。在Tar​​snap的1.0.22至1.0.27版本中，无意中重复使用了相同的IV，从而实现了纯文本恢复。

这是怎么发生的？为了简化Tarsnap代码-并希望减少错误的可能性-Colin Percival借此机会将AES-CTR代码“重构”为一个新文件（Tarsnap源代码中的lib / crypto / crypto_aesctr.c） ），并修改了使用AES-CTR来利用这些例程的现有位置。新代码如下所示：

        /* Encrypt the data. */
-       aes_ctr(&encr_aes->key, encr_aes->nonce++, buf, len,
-           filebuf + CRYPTO_FILE_HLEN);
+       if ((stream =
+           crypto_aesctr_init(&encr_aes->key, encr_aes->nonce)) == NULL)
+               goto err0;
+       crypto_aesctr_stream(stream, buf, filebuf + CRYPTO_FILE_HLEN, len);
+       crypto_aesctr_free(stream);

在重构期间，encr_aes->nonce++意外地变成了encr_aes->nonce，结果重复使用了相同的现时值。特别是，在加密每个块之后，CTR随机数值不会增加。 （在处理完每16个字节的数据后，CTR计数器会正确递增，但是对于每个新块，该计数器都会重置为零。）Colin Percival在以下网站中描述了完整的详细信息：http://www.daemonology.net/blog/ 2011-01-18-tarsnap-critical-security-bug.html

#6 楼

不要对加密和身份验证使用相同的密钥。请勿对加密和签名使用相同的密钥。

密钥不应用于多种用途；

例如，如果您具有RSA私钥/公钥对，则不应同时将其用于加密（使用公钥加密，使用私钥解密） ）以及用于签名（使用私钥签名，使用公钥验证）：选择一个目的并将其仅用于该目的。如果您同时需要这两种能力，请生成两个密钥对，一个用于签名，一个用于加密/解密。

类似地，对于对称加密，您应该使用一个密钥进行加密，并使用单独的独立密钥进行消息身份验证。请勿将相同的密钥用于这两个目的。

#7 楼

不要将带有ECB的分组密码用于对称加密

（适用于AES，3DES等）

这是一篇帖子，与Microsoft KB文章非常相似关于ECB模式如何导致未加密的代码。

也可以从Rook看到类似的帖子

纯文本消息：



用ECB加密的相同消息模式（使用什么密码都没有关系）：


使用CBC模式的完全相同的消息（同样，使用什么密码也没关系）：


错误的方式

public static string Encrypt(string toEncrypt, string key, bool useHashing)
{

byte[] keyArray = UTF8Encoding.UTF8.GetBytes(key);
byte[] toEncryptArray = UTF8Encoding.UTF8.GetBytes(toEncrypt);

if (useHashing)
    keyArray = new MD5CryptoServiceProvider().ComputeHash(keyArray);

var tdes = new TripleDESCryptoServiceProvider() 
    { Key = keyArray, Mode = CipherMode.ECB, Padding = PaddingMode.PKCS7 };

ICryptoTransform cTransform = tdes.CreateEncryptor();
byte[] resultArray = cTransform.TransformFinalBlock(
    toEncryptArray, 0, toEncryptArray.Length);

return Convert.ToBase64String(resultArray, 0, resultArray.Length);
}

错误在下一行

{Key = keyArray，Mode = CipherMode.ECB，填充= PaddingMode.PKCS7};


正确的方法

Microsoft的好伙伴向我发送了以下代码来更正该知识库文章上面链接。在案例号111021973179005

中引用了此示例代码，该示例代码使用AES加密数据，而AES加密的密钥是SHA256生成的哈希码。 AES是高级加密标准（AES）算法。 AES算法基于排列和替换。排列是数据的重新排列，而替换则将一个数据单元替换为另一个数据单元。 AES使用几种不同的技术执行置换和替换。有关AES的更多详细信息，请参阅MSDN杂志上的文章“使用新的高级加密标准保护您的数据安全”，位于http://msdn.microsoft.com/zh-cn/magazine/cc164055.aspx。 >
SHA是安全哈希算法。现在建议使用SHA-2（SHA-224，SHA-256，SHA-384，SHA-512）。有关.NET Framework中哈希值的更多详细信息，请参考http://msdn.microsoft.com/zh-cn/library/92f9ye3s.aspx#hash_values。

AesCryptoServiceProvider的对称算法操作模式的默认值为CBC。 CBC是密码块链接模式。它介绍了反馈。在对每个纯文本块进行加密之前，通过按位异或运算将其与前一个块的密文组合在一起。这样可以确保即使纯文本包含许多相同的块，它们也将各自加密为不同的密文块。在对该块进行加密之前，通过按位异或运算将初始化向量与第一个纯文本块组合在一起。如果密文块的单个位被整齐，则相应的明文块也将被整齐。此外，后续块中与原始错位相同的位也将被错位。有关CipherMode的更多详细信息，请参考http://msdn.microsoft.com/zh-cn/library/system.security.cryptography.ciphermode.aspx。以下是示例代码。

// This function is used for encrypting the data with key and iv.
byte[] Encrypt(byte[] data, byte[] key, byte[] iv)
{
    // Create an AESCryptoProvider.
    using (var aesCryptoProvider = new AesCryptoServiceProvider())
    {
        // Initialize the AESCryptoProvider with key and iv.
        aesCryptoProvider.KeySize = key.Length * 8;
        aesCryptoProvider.IV = iv;
        aesCryptoProvider.Key = key;

        // Create encryptor from the AESCryptoProvider.
        using (ICryptoTransform encryptor = aesCryptoProvider.CreateEncryptor())
        {
            // Create memory stream to store the encrypted data.
            using (MemoryStream stream = new MemoryStream())
            {
                // Create a CryptoStream to encrypt the data.
                using (CryptoStream cryptoStream = new CryptoStream(stream, encryptor, CryptoStreamMode.Write))
                    // Encrypt the data.
                    cryptoStream.Write(data, 0, data.Length);

                // return the encrypted data.
                return stream.ToArray();
            }
        }
    }
}

// This function is used for decrypting the data with key and iv.
byte[] Decrypt(byte[] data, byte[] key, byte[] iv)
{
    // Create an AESCryptoServiceProvider.
    using (var aesCryptoProvider = new AesCryptoServiceProvider())
    {
        // Initialize the AESCryptoServiceProvier with key and iv.
        aesCryptoProvider.KeySize = key.Length * 8;
        aesCryptoProvider.IV = iv;
        aesCryptoProvider.Key = key;

        // Create decryptor from the AESCryptoServiceProvider.
        using (ICryptoTransform decryptor = aesCryptoProvider.CreateDecryptor())
        {
            // Create a memory stream including the encrypted data.
            using (MemoryStream stream = new MemoryStream(data))
            {
                // Create a CryptoStream to decrypt the encrypted data.
                using (CryptoStream cryptoStream = new CryptoStream(stream, decryptor, CryptoStreamMode.Read))
                {
                    // Create a byte buffer array.
                    byte[] readData = new byte[1024];
                    int readDataCount = 0;

                    // Create a memory stream to store the decrypted data.
                    using (MemoryStream resultStream = new MemoryStream())
                    {
                        do
                        {
                            // Decrypt the data and write the data into readData buffer array.
                           readDataCount = cryptoStream.Read(readData, 0, readData.Length);
                            // Write the decrypted data to resultStream.
                            resultStream.Write(readData, 0, readDataCount);
                        }
                        // Check whether there is any more encrypted data in stream.
                        while (readDataCount > 0);
                        // Return the decrypted data.
                        return resultStream.ToArray();
                    }
                }
            }
        }
    }
}



// This function is used for generating a valid key binary with UTF8 encoding and SHA256 hash algorithm.
byte[] GetKey(string key)
{
    // Create SHA256 hash algorithm class.
    using (SHA256Managed sha256 = new SHA256Managed())

    // Decode the string key to binary and compute the hash binary of the key.
    return sha256.ComputeHash(Encoding.UTF8.GetBytes(key));
}

有关示例代码中类的更多详细信息，请参阅以下链接：

·AesCryptoServiceProvider类

·SHA256Managed类

·CryptoStream类

此外，还有几篇文章可能有助于更好地理解.NET Framework中的加密，请参考链接。下面的内容：

·加密服务

·.NET Framework密码学模型

·密码学的简单指南

·没有秘密加密

#8 楼

Kerckhoffs的原理：即使系统中除密钥之外的所有内容都是公共知识，密码系统也应是安全的

错误的例子：LANMAN哈希

LANMAN哈希将很难弄清楚是否有人不知道该算法，但是一旦知道了该算法，现在破解起来就很容易了。

算法如下（来自维基百科）：


用户的ASCII密码转换为大写。 14个字节
“固定长度”密码分为两个七个字节。
这些值用于创建两个DES密钥，每个7字节一半都一个。
每个两个密钥用于对恒定的ASCII字符串“ KGS！@＃$％”进行DES加密，从而产生两个8字节密文值。
这两个密文值连接在一起形成一个16字节的值，即LM哈希值。

因为您现在知道了这些事实的密文，所以现在可以很容易地将密文分成两个您知道的密文是大写的，导致密码可能是一组有限的字符。

正确的例子：AES加密


已知算法
随技术扩展。需要更多加密功能时增加密钥大小

#9 楼

尝试避免将密码用作加密密钥。

在许多系统中，一个常见的缺点是使用密码或密码短语或密码或密码短语的哈希作为加密/解密密钥。问题是，这往往很容易受到脱机密钥搜索攻击的影响。大多数用户选择的密码没有足够的熵来抵抗这种攻击。

最好的解决方法是使用真正随机的加密/解密密钥，而不是确定性地从密码/口令生成的密钥。

但是，如果必须使用基于密码/密码的密码，请使用适当的方案来减慢详尽的按键搜索。我推荐PBKDF2，它使用迭代哈希（沿H（H（H（.... H（password）...）））行）来减慢字典搜索的速度。安排使用足够多的迭代来使此过程在用户的计算机上花费例如100ms的时间来生成密钥。

#10 楼

在加密协议中：使每条经过身份验证的消息都可识别：两条消息看起来都不应相同

以下内容的概括/变体：


连接多个字符串时要小心，在散列之前。
不要重用密钥。
请不要重用随机数。

在运行加密协议期间，许多没有密钥（密钥或密匙）就无法伪造的消息。随机数）可以交换。接收者可以验证这些消息，因为他知道一些公用（签名）密钥，或者因为只有他和发送者知道一些对称密钥或随机数。这样可以确保这些消息没有被修改。

但是，这不能确保在协议的同一运行期间已经发出了这些消息：攻击者可能在之前或期间捕获了这些消息。协议的并发运行。攻击者可能会启动多个并发运行的加密协议，以捕获有效消息并未经修改地重用它们。

通过巧妙地重放消息，可能可以在不破坏任何主键的情况下攻击协议，而无需攻击任何主键。 RNG，任何密码等。

通过使该协议的每条经过身份验证的消息对于接收方来说都明显不同，可以减少（未消除）重播未修改消息的机会。

#11 楼

不要在两个方向上都使用相同的密钥。

在网络通信中，常见的错误是在A-> B方向和B-> A方向上使用相同的密钥。这是一个坏主意，因为它通常会启用重播攻击，从而将发送给B的东西重播回B，然后再重发给A。最安全的方法是协商两个独立的密钥，每个方向协商一个密钥。或者，您可以协商单个密钥K，然后将K1 = AES（K，00..0）用于一个方向，将K2 = AES（K，11..1）用于另一个方向。

#12 楼

不要使用不安全的密钥长度。

请确保您使用的密钥长度足够长的算法。

对于对称密钥加密，我建议至少使用80位密钥，如果可能的话，最好使用128位密钥。不要使用40位加密；它很不安全，很容易被业余爱好者破坏，只需彻底尝试所有可能的键即可。不要使用56位DES；破解并不容易，但是专门的攻击者可以破解DES。 128位算法（例如AES）不会比40位加密慢很多，因此您没有借口使用伪造的加密。

对于公共密钥加密，密钥长度建议取决于密钥长度。算法和所需的安全级别。同样，增加密钥大小会损害性能，因此过大的杀伤力是不经济的。因此，这比选择对称密钥密钥大小需要更多的思考。对于RSA，El Gamal或Diffie-Hellman，我建议密钥至少为1024位，并且绝对最小值。但是，1024位密钥处于短期内会变得容易破解的边缘，通常不建议用于现代用途，因此，如果有可能，我建议使用1536位甚至2048位密钥。对于椭圆曲线密码学，160位密钥显得足够，而224位密钥则更好。您还可以参考已发布的准则，以建立对称密钥和公共密钥大小之间的大致等效性。

#13 楼

使用正确的模式

等效地，不要依赖库的默认设置来保证安全。具体来说，许多实现AES的库都实现了FIPS 197中描述的算法，即所谓的ECB（电子代码簿）模式，该模式本质上是以下各项的直接映射：

AES(plaintext [32]byte, key [32]byte) -> ciphertext [32]byte

非常不安全。推理很简单，尽管密钥空间中可能的密钥数量很大，但这里的薄弱环节是消息中的熵量。与往常一样，xkcd.com所描述的要比我更好http://xkcd.com/257/

使用像CBC（密码块链接）之类的东西基本上使密文[i]映射：

ciphertext[i] = SomeFunction(ciphertext[i-1], message[i], key)

只需要指出一些容易出错的语言库即可：http://golang.org/pkg/crypto/aes /提供一个AES实现，如果天真地使用它会导致ECB模式。

pycrypto库在创建新的AES对象时默认为ECB模式。

OpenSSL，可以这个权利。每个AES调用都明确说明操作模式。 IMO真正最安全的事情就是只是不要自己做这种低级加密。如果您被迫这样做，请像小心地在碎玻璃上行走一样继续操作，并尝试确保用户有理由相信您，以保护他们的数据。

#14 楼

不要在许多设备上重复使用相同的密钥。

共享密钥越广泛，就越不可能将其保密。某些已部署的系统已将相同的对称密钥重用于系统上的每个设备。问题在于，迟早有人会从单个设备中提取密钥，然后他们便能够攻击所有其他设备。因此，请不要这样做。

另请参阅此博客文章中的“对称加密不要＃6：不要在多个设备之间共享单个密钥”。感谢Matthew Green。

#15 楼

如果密钥是通过算法拉伸的，则一次性垫不是一次性垫。

标识符“一次性垫”（也称为Vernam密码）经常误用于各种密码试图声称牢不可破的安全性的解决方案。但是根据定义，只有并且满足以下所有三个条件时，Vernam密码才是安全的：


关键材料确实是不可预测的。 AND
密钥材料的长度与明文相同； AND
关键材料永远不会重复使用。

任何违反这些条件的行为都意味着它不再是一次性填充密码。

常见的错误是使用算法扩展了短密钥。此操作违反了不可预测性规则（不必担心密钥长度规则）。完成此操作后，一次性填充将在数学上转换为密钥扩展算法。将短键和随机字节组合在一起只会改变暴力破解键拉伸算法所需的搜索空间。类似地，使用“随机生成”字节会将随机数生成器算法转换为安全性算法。这里是一个简单的示例。我收到一条消息，我将使用“一次性密码”加密，该密码使用加密安全功能作为密钥生成器。我选择了一个秘密密钥，然后在其中添加了一个随机数以确保它不会被重用。由于我没有重用密钥，因此无法通过从另一消息中减去一条消息来攻击密文。

          plaintext : 1234567890123456789012345678901234567890
       key material : 757578fbf23ffa4d748e0800dd7c424a46feb0cc
OTP function (xor)  : ----------
         ciphertext : 67412E83622DCE1B0C1E1A348B04D25872A8C85C

密钥材料是使用SHA-1安全生成的，用于对我的秘密密码（加上随机数）进行哈希处理以对其进行扩展。但是，任何知道所使用的扩展算法*为SHA-1的攻击者都可以通过尝试将各种输入SHA-1并将输出与密文进行XOR来对其进行攻击。现在，猜测“ OTP”密钥比猜测密码算法的组合输入更困难。无论选择哪种基本密码算法，采用何种度量复杂度，如何实现或设定种子，此属性均成立。

您可能有一个很好的密钥拉伸算法。您可能还具有非常安全的随机数生成器。但是，根据定义，您的算法不是一次性填充，因此不具有一次性填充的不可破坏的属性。

*应用Kerckhoff原理意味着您必须假设攻击者可以始终确定使用的算法。

#16 楼

不要相信标准。

密码术中存在许多标准，有时您必须使用它们。但是，请不要以为编写标准的人充分理解了他们所需的加密技术。例如，EAX在网络标准中进行了重新设计。 EAX有安全证明。重做的版本没有。

MD5是标准。现在坏了。由于具有丰富的危险功能，芯片和PIN屡屡被破坏。 GPG仍然支持DSA密钥，这些密钥太短而无法舒适。 SSL具有不应使用的选项，并且需要避免使用这些选项。

该怎么办？谨慎行事，了解已知风险，并跟上新风险的研究。

#17 楼

请勿在磁盘加密中使用OTP或流密码。
示例1

假设使用流密码/ OTP保存了两个文件。如果在进行较小的编辑后重新保存文件，则攻击者可以看到仅某些位被更改，并推断出有关文档的信息。 （想象一下将称呼“亲爱的鲍勃”更改为“亲爱的爱丽丝”）。

示例2

输出中没有完整性：攻击者可以修改密文并修改只需对数据进行XOR即可处理数据的内容。

要点：密文的修改未被发现，并且对明文具有可预测的影响。

解决方案

对于以下情况，请使用分组密码：邮件完整性检查

#18 楼

永远不要一次使用一个Time Pad（OTP）或流密码密钥

一次应用一次OTP意味着用“完全保密”加密的数据将被解密并且是明文。发生这种情况是因为数据被异或两次。

示例

假设正在重用具有相同密钥的OTP /或流。

攻击者收集了从客户端发送的大量数据然后将一组两个数据包进行XOR运算，直到两个数据包互相解密（或其中的子集）。

ASCII编码具有足够的冗余性，这意味着给定足够的密文，就可以对原始消息进行解码（以及秘密的OTP密钥）。

现实世界的例子



项目维罗纳（1941-46）是俄罗斯人使用的OTP的例子，随后被美国情报机构解密
/> Microsoft的PPTPv1客户端和服务器都使用相同的密钥加密数据。
一旦发送2 ^ 24个数据包，或者重置了NIC卡，WEP就会重复使用相同的密钥。第一个问题是由于IV的长度为24位，导致在发送1600万帧后创建了两个时间间隔。第二个问题发生在硬件实现中，在重新上电之后，IV重置为零，导致两个时间间隔。因为IV是明文发送的，所以这个问题很容易看到。

建议


应该为每个会话创建一个新密钥（例如TLS）。
客户端应与服务器一起使用一个OTP（或带有PRG的流密码），并且服务器在向客户端加密数据时服务器应使用其他密钥
而不是生成许多密钥，可以使用PRG（假设您信任PRG）将单个键扩展为长数据流，并使用该扩展的每个段作为键。
请注意，并非所有PRG都可以在增量模式下工作，并且随机输入可能需要。 （RC4在增量模式下存在此问题）

#19 楼

使用可以在硬件或软件中正常工作的现代流处理器

并非所有流密码都设计为在硬件或软件中实现。线性反馈移位寄存器（LFSR）是易于破解的广泛使用的硬件密码的一个示例。

LFSR用于：DVD加密（也用于被称为CSS）2 LFSR
GSM加密（A5 / 1.2）3 LSFR
蓝牙（E0）：4 LFSR

上述硬件广泛部署，因此很难更新或提出现代标准。以上所有内容均已严重破坏，因此不值得用于安全通信。

攻击：

由于在加密过程中密钥被分为两部分（17位和25位） ），而这些位用于加密相同的密文，则可以使用MPEG格式的知识，并强行使用17位密钥来推断25位密钥是什么。

这并不是什么新鲜事物，但是FOSS很容易找到，证明了这个问题。

解决方案：

eStream项目（在2008年）限定了应使用的5个流密码。显着的区别在于，密码使用的是密钥，随机数和计数器，而不是使用带有IV的密钥。 Salsa20以这种方式操作，并且设计为可轻松在硬件和软件中使用。具体来说，它包含在x86 SSE2指令集中。

在旁边

现代密码不仅更安全，而且速度更快：

PRG          Speed (MB/sec)
RC4              126         (obsolete)
Salsa20/12       643         (modern)
Sosemaunk        727         (modern)

#20 楼

不要使用RC4

RC4于1987年设计，用作流密码。它在HTTPS和WEP中使用。

存在弱点


初始输出中存在偏差：Pr [2nd byte = 0] = 2/256
等于零的16位的概率是1/256 ^ 2 + 1/256 ^ 3。在加密了几Gig数据之后，就会发生这种情况。
容易受到相关的密钥攻击，在这种情况下，仅IV发生了变化，但密钥保持不变。

如果必须使用RC4，请忽略前256个字节（有偏差）。如果将RC4用于数据的Gig，则RC4中的偏差将允许攻击所有以前的加密数据。

#21 楼

仅使用不易受到邮件扩展攻击的MAC

MAC是确保给定纯文本的邮件完整性（无修改等）的哈希码。许多实现和已发布的标准未能保护MAC免受攻击者的攻击，因为攻击者无法向MAC添加其他数据。

解决此问题的方法是MAC实现使用第二个（不同的）密钥并重新加密最终输出。

ECBC和NMAC是正确加密的示例防止邮件扩展攻击。

解决方案：


使用Encrypted CBC (ECBC)代替raw CBC

使用NMAC代替cascade