秘密与非秘密初始化向量
今天，我在悠闲地阅读时偶然发现了 使用离散对数密码学的成对密钥建立方案的建议（修订）（NIST 特别出版物 800-56A）。我对此感到非常困惑：
经批准的密钥派生函数 （KDF）应用于导出秘密 来自共享秘密的密钥材料。 KDF 的输出只能是 用于秘密密钥材料，例如 作为用于数据的对称密钥 加密或消息完整性， 秘密初始化向量，或 将用于的主密钥 生成其他密钥（可能使用 不同的过程）。非秘密密钥 材料（例如非秘密 初始化向量）不应是 使用共享密钥生成。
现在我不是阿兰·图灵，但我认为初始化向量不需要保密。在什么情况下人们会想要一个“秘密初始化向量”？ Thomas Pornin 表示 IV 是公开的，而且他似乎精通密码学。 caf 也是如此。
Today I was doing some leisurely reading and stumbled upon Section 5.8 (on page 45) of Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised) (NIST Special Publication 800-56A). I was very confused by this:
An Approved key derivation function
(KDF) shall be used to derive secret
keying material from a shared secret.
The output from a KDF shall only be
used for secret keying material, such
as a symmetric key used for data
encryption or message integrity, a
secret initialization vector, or a
master key that will be used to
generate other keys (possibly using a
different process). Nonsecret keying
material (such as a non-secret
initialization vector) shall not be
generated using the shared secret.
Now I'm no Alan Turing, but I thought that initialization vectors need not be kept secret. Under what circumstances would one want a "secret initialization vector?"
Thomas Pornin says that IVs are public and he seems well-versed in cryptography. Likewise with caf.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
初始化向量不需要是秘密的（它不是密钥），但也不需要是公开的（发送者和接收者必须知道它，但英国女王不一定也知道它）。
典型的密钥建立协议将导致双方都计算他们（但只有他们）都知道的数据。使用 Diffie-Hellman（或其任何椭圆曲线变体），所述共享数据片段具有固定长度，并且它们无法控制其值（它们只是都获得相同的看似随机的位序列）。为了使用该共享秘密进行对称加密，他们必须将该共享数据导出为适合他们将要使用的任何对称加密算法的长度的位序列。
在使用密钥建立算法来获取发送者和接收者之间的共享秘密，并使用该秘密对称加密消息（可能是很长的流式消息）的协议中，可以使用 KDF一次性生成密钥和 IV。例如，SSL：来自共享密钥（称为SSL 规范中的“预主密钥”）是计算派生秘密数据的一大块，然后将其拆分为对称密钥和两个加密方向的初始化向量。您可以采取其他方式，例如，生成随机 IV 并将它们与加密数据一起发送，而不是使用通过 KDF 获得的 IV（这就是最新版本 TLS，SSL 的后继者）。两种策略同样有效（TLS 使用外部随机 IV，因为它们希望为每个“记录”（TLS 连接内的数据包）提供一个新的随机 IV，这就是为什么使用 KDF 不再被认为是合适的）。
An initialization vector needs not be secret (it is not a key) but it needs not be public either (sender and receiver must know it, but it is not necessary that the Queen of England also knows it).
A typical key establishment protocol will result in both involve parties computing a piece of data which they, but only they, both know. With Diffie-Hellman (or any Elliptic Curve variant thereof), the said shared piece of data has a fixed length and they have no control over its value (they just both get the same seemingly random sequence of bits). In order to use that shared secret for symmetric encryption, they must derive that shared data into a sequence of bits of the appropriate length for whatever symmetric encryption algorithm they are about to use.
In a protocol in which you use a key establishment algorithm to obtain a shared secret between the sender and the receiver, and will use that secret to symmetrically encrypt a message (possibly a very long streamed message), it is possible to use the KDF to produce the key and the IV in one go. This is how it goes in, for instance, SSL: from the shared secret (called "pre-master secret" in the SSL spec) is computed a big block of derived secret data, which is then split into symmetric keys and initialization vectors for both directions of encryption. You could do otherwise, and, for instance, generate random IV and send them along with the encrypted data, instead of using an IV obtained through the KDF (that's how it goes in recent versions of TLS, the successor to SSL). Both strategies are equally valid (TLS uses external random IV because they want a fresh random IV for each "record" -- a packet of data within a TLS connection -- which is why using the KDF was not deemed appropriate anymore).
好吧，考虑一下，如果两方具有相同的加密函数，但没有相同的 IV，他们将不会得到相同的结果。那么，看起来提议是两方获得相同的共享秘密，并且各自确定性地生成一个 IV（将是相同的），然后他们就可以进行通信。我就是这么读的；但我并没有真正阅读过该文档，并且我不完全确定我的描述是否准确；但这就是我开始调查的方式。
Well, consider that if two parties have the same cryptographic function, but don't have the same IV, they won't get the same results. So then, it seems like the proposal there is that the two parties get the same shared secret, and each generate, deterministically, an IV (that will be the same) and then they can communicate. That's just how I read it; but I've not actually read the document, and I'm not completely sure that my description is accurate; but it's how I'd start investigating.
IV 是公共的还是私人的，并不重要
让我们考虑攻击者已知 IV，现在通过查看加密的数据包/数据，
知道 IV 并且不知道加密密钥，他/她可以猜测输入数据吗？ （想了一下）
让我们稍微倒退一下，假设加密中没有使用IV
AES（输入，K）= E1
相同的输入将始终产生相同的加密文本。
攻击者可以通过查看加密文本和输入数据的一些先验知识（即某些协议的初始交换）来猜测密钥“K”，
因此，这就是 IV 的帮助。它添加了输入值，即使对于相同的输入数据，您的加密文本也会发生变化。
即AES（输入，IV，K）= E1
因此，攻击者看到加密的数据包是不同的（即使具有相同的输入数据）并且不能轻易猜测。 （即使有IV知识）
IV is public or private, it doesn't matter
let's consider IV is known to attacker, now by looking at encrypted packet/data,
and knowledge of IV and no knowledge on encryption key, can he/she can guess about input data ? (think for a while)
let's go slightly backwards, let's say there is no IV in used in encryption
AES (input, K)= E1
Same input will always produce the same encrypted text.
Attacker can guess Key "K" by looking at encrypted text and some prior knowledge of input data(i.e. initial exchange of some protocols)
So, here is what IV helps. its added with input value , your encrypted text changes even for same input data.
i.e. AES (input, IV, K)= E1
Hence, attacker sees encrypted packets are different (even with same input data) and can't guess easily. (even having IV knowledge)
CTR模式加密中计数器的起始值可以被认为是IV。如果您将其保密，那么您最终会获得比您所使用的密码的密钥长度所授予的安全性更高的安全性。很难说要额外增加多少，但不知道它确实会增加弄清楚如何解密给定消息所需的工作。
The starting value of the counter in CTR mode encryption can be thought of as an IV. If you make it secret, you end up with some amount of added security over the security granted by the key length of the cipher you're using. How much extra is hard to say, but not knowing it does increase the work required to figure out how to decrypt a given message.