AES 加密-密钥对抗 IV

我正在开发的应用程序允许用户对文件进行加密。文件可以是任何格式(电子表格、文档、演示文稿等)。

对于指定的输入文件，我创建了两个输出文件——一个加密的数据文件和一个密钥文件。您需要这两个文件来获取原始数据。密钥文件必须只对相应的数据文件有效。它不应该在任何其他文件上工作，无论是来自同一个用户还是来自任何其他用户。

AES 算法需要两个不同的加密参数，一个密钥和一个初始向量(IV)。

我看到了创建密钥文件的三种选择:

  1. 在应用程序中嵌入硬编码 IV 并将密钥保存在密钥文件中。
  2. 在应用程序中嵌入硬编码的密钥并将 IV 保存在密钥文件中。
  3. 在密钥文件中保存密钥和 IV。

请注意，不同的客户使用的是相同的应用程序。

看来这三种选择都能达到同样的目的。然而，我希望得到您对什么是正确的方法的反馈。

127945 次浏览
小开

When you use an IV, the most important thing is that the IV should be as unique as possible, so in practice you should use a random IV. This means embedding it in your application is not an option. I would save the IV in the data file, as it does not harm security as long as the IV is random/unique.

小开

The important thing about an IV is you must never use the same IV for two messages. Everything else is secondary - if you can ensure uniqueness, randomness is less important (but still a very good thing to have!). The IV does not need to be (and indeed, in CBC mode cannot be) secret.

As such, you should not save the IV alongside the key - that would imply you use the same IV for every message, which defeats the point of having an IV. Typically you would simply prepend the IV to the encrypted file, in the clear.

If you are going to be rolling your own cipher modes like this, please read the relevant standards. The NIST has a good document on cipher modes here: http://dx.doi.org/10.6028/NIST.SP.800-38A IV generation is documented in Appendix C. Cryptography is a subtle art. Do not be tempted to create variations on the normal cipher modes; 99% of the time you will create something that looks more secure, but is actually less secure.

小开
最佳答案

As you can see from the other answers, having a unique IV per encrypted file is crucial, but why is that?

First - let's review why a unique IV per encrypted file is important. (Wikipedia on IV). The IV adds randomness to your start of your encryption process. When using a chained block encryption mode (where one block of encrypted data incorporates the prior block of encrypted data) we're left with a problem regarding the first block, which is where the IV comes in.

If you had no IV, and used chained block encryption with just your key, two files that begin with identical text will produce identical first blocks. If the input files changed midway through, then the two encrypted files would begin to look different beginning at that point and through to the end of the encrypted file. If someone noticed the similarity at the beginning, and knew what one of the files began with, he could deduce what the other file began with. Knowing what the plaintext file began with and what it's corresponding ciphertext is could allow that person to determine the key and then decrypt the entire file.

Now add the IV - if each file used a random IV, their first block would be different. The above scenario has been thwarted.

Now what if the IV were the same for each file? Well, we have the problem scenario again. The first block of each file will encrypt to the same result. Practically, this is no different from not using the IV at all.

So now let's get to your proposed options:

Option 1. Embed hard-coded IV within the application and save the key in the key file.

Option 2. Embed hard-coded key within the application and save the IV in the key file.

These options are pretty much identical. If two files that begin with the same text produce encrypted files that begin with identical ciphertext, you're hosed. That would happen in both of these options. (Assuming there's one master key used to encrypt all files).

Option 3. Save both the key and the IV in the key file.

If you use a random IV for each key file, you're good. No two key files will be identical, and each encrypted file must have it's key file. A different key file will not work.

PS: Once you go with option 3 and random IV's - start looking into how you'll determine if decryption was successful. Take a key file from one file, and try using it to decrypt a different encryption file. You may discover that decryption proceeds and produces in garbage results. If this happens, begin research into authenticated encryption.

小开

IV is used for increase the security via randomness, but that does not mean it is used by all algorithm, i.e. enter image description here

The trick thing is how long should the IV be? Usually it is the same size as the block size, or cipher size. For example, AES would have 16 bytes for IV. Besides, IV type can also be selected, i.e. eseqiv, seqiv, chainiv ...

小开

Key/Iv pairs likely the most confused in the world of encryption. Simply put, password = key + iv. Meaning you need matching key and iv to decrypt an encrypted message. The internet seems to imply you only need iv to encrypt and toss it away but its also required to decrypt. The reason for spitting the key/iv values is to make it possible to encrypt same messages with the same key but use different Iv to get unequal encrypted messages. So, Encrypt("message", key, iv) != Encrypt("message", key, differentIv). The idea is to use a new random Iv value every time a message is encrypted. But how do you manage an ever changing Iv value? There's a million possibilities but the most logical way is to embed the 16 byte Iv within the encrypted message itself. So, encrypted = Iv + encryptedMessage. This way the contently changing Iv value can be pulled and removed from the encrypted message then decrypted. So decryptedMessage = Decrypt("messageWithoutIv", key, IvFromEncryptedMessage). Alternatively if storing encrypted messages in a database Iv could be stored in a field there. Although its true Iv is part of the secret, its tiny in comparison to the 32 bit key and is never reused so it is practically safe to expose publicly. Keep in mind, iv has nothing to do with encruotion, it has to do with masking encryption of messages having the same content.


提交答案