来自维基百科：

初始化向量与密钥具有不同的安全要求，因此IV 通常不需要保密。然而，在大多数情况下，重要的是初始化向量永远不会在相同的 key 下重用。对于 CBC 和 CFB，重用 IV 会泄露一些关于第一个明文块以及两条消息共享的任何公共前缀的信息。

您不需要对 IV 保密，但它必须是随机且唯一的。

尽管在您的情况下，IV 应该可以在数据库中以明文形式显示，但如果您允许用户控制IV，则会存在严重漏洞。

解密中的 IV用于（并且仅用于）将XOR第一个块转换为最终明文 - 因此，如果攻击者可以控制 IV，他们可以任意控制第一个数据块，并且明文的其余部分将在不修改的情况下继续存在。

如果攻击者知道第一个块的原始明文，那么问题会再次被放大，因为攻击者可以为第一个块选择任意数据而无需反复试验。

这在加密数据通过不受信任的渠道与IV 传输的情况下尤其重要，可能进入浏览器或应用程序等。

如果我用随机生成的 Key 和 Initialization Vector 对一些数据进行加密，则将所有三条信息存储在同一个表行中；是否有必要加密 IV 以及密钥？

不，可能只需要加密存储密钥；没有必要对随机 IV 进行加密。

显然（秘密）密钥需要保密。如果您使用加密（即将负担转移到另一个密钥或密钥对）或任何其他方法来做到这一点，则取决于架构师。但是，如果您要将其存储在数据库旁边，那么一个好的密钥包装方法（例如 AES-WRAP、AES-SIV）是保护您的静态密钥的一部分的合乎逻辑的选择。使用密钥时，需要具备其他安全机制，例如访问控制/防止侧信道攻击。

对于 CBC 模式，IV 需要对对手来说是不可预测的。如果不是这种情况，那么 CBC 在使用密文 oracle 的主动攻击下失败。一般来说，您应该假设存在这样的预言机。例如，您应该假设攻击者可以将任何消息发送到您的数据库，然后您将其加密并存储在数据库中以供攻击者读取。由种子良好的加密安全（伪）随机数生成器 (CSPRNG)（例如 /dev/urandom）生成随机 IV可以避免此类问题。

加密 IV 是一种危险的做法，因为 IV 会与明文进行异或运算。如果这样做，则应使用不同的密钥对其进行加密，否则还可能损害 CBC 模式的安全性。如果您必须使用当前密钥，那么您应该使用生成的密文作为 IV 而不是明文输入。但是，对于完全没有必要的随机 IV：您可以将其存储在密文旁边而无需保护。

补充：消息完整性和真实性

一般来说，在使用之前至少验证存储消息的完整性和真实性总是一个好主意。应该首选使用诸如 GCM 或 EAX 之类的操作模式。

请注意，GCM 和 EAX 都不需要不可预测的 IV；IV 只需要是唯一的 - 除了大小之外没有其他要求；使用 128 位的完全随机 IV/nonce 当然也可以。它们会自动将 IV 包含在身份验证标签的计算中。

在密文上使用 HMAC （也称为 encrypt-then-MAC）已被证明非常成功地提供了完整性/真实性，但请注意，如果您决定使用 HMAC，则应在计算中包含IV*。