问题标签 [initialization-vector]

我即将使用以下脚本来加密和解密一些数据。我正在使用它，因为我当前的加密在我们的新服务器上不起作用。我们目前正在使用 mcrypt，所以我想更改为 openssl。

在我们的数据库中，我们使用 aes 加密，它使用 128 位密钥，所以我知道密钥是什么，但我不知道 openssl iv 是什么？为什么我需要钥匙和 iv。

我将要使用的代码是这个，我在一个网站上找到的，因为我不太了解加密。

显然我会修改它，以便将密钥保存在其他地方。

我需要生成一个唯一的IV (Initialization Vector)标题。

IV应为 96 位长，由年份（16 位，0 到 65535）、当前时间（64 位，今年的纳秒）和用于生成 96 位 IV 的计数器（16 位）组成。

如何在 中生成此唯一标识符CGI bash script？

出于性能原因，我们希望尽可能为给定密钥重用我们的 Cipher 对象 (java)。但是，我们希望遵循良好的加密卫生，并在每组明文上使用随机 IV 进行加密。是否可以重用相同的密码对象，更改 IV，并且在不每次都重新初始化密码对象的情况下完成所有操作（即，只在开始时初始化一次）？我希望它在每次 doFinal 调用后使用新的 IV。如有必要，我可以在每次 doFinal 调用后手动设置它。

我考虑过扩展 IVParameterSpec 并覆盖 getIV 方法，以便它每次生成一个随机方法，但是，我有两个问题：

1. 在实践中可能不会成为问题，但我怎么知道给定的 CipherSpi 对象不会为给定的明文调用两次？我需要为给定的明文返回相同的 IV，但为不同的明文返回不同的 IV。我想大多数供应商都不会打电话两次，但我不确定。

2. 查看 CipherSpi 文档，看起来它在初始化时通过了 IVParameterSpec，我不知道提供者是否会立即获取 IV，然后在对象的生命周期内缓存它。如果这样做，那么无论要加密的明文是否不同，IV 都将始终相同。

是否有其他方法可以重用 Cipher 对象，但在每次不需要重新初始化的 doFinal 调用后更改 IV？我知道像 SIV 这样的一些模式对 IV 的要求不那么严格，但现在这不是一个选择。另外，我知道我可以选择一个可能支持我上面描述的解决方案的特定提供商，但我希望有一个与提供商无关的解决方案。

谢谢！

如何将密文和IV（分组密码操作模式，例如AES-GCM）存储在文件中？如果我用对应于“：”字符的字节将它们分开，那么在读取它时，我必须将整个字节数组转换为字符串，然后将字符串拆分为由“：”分隔的块，然后再次将块转换为字节数组。有没有更简单的方法？也许一个我们确定不能作为 AES 加密和初始化向量的结果出现的字节？

当前代码（在 Java 中）是后续代码，但我不确定它是否是执行我所要求的最佳方法，即使它有效，因为我不知道表示“：”的字节是否可以出现在IV 或密文。

以下 node.js 代码尝试在 ECB 模式下使用 AES 128 创建密码，初始化向量 (IV) 填充为 0 字节。<< rant >>我知道应该不惜一切代价避免使用 ECB 模式进行加密，但它仍然需要支持二战前构建的遗留系统（当 ECB 模式加密的危险首次被发现时）。 <</咆哮>>。

当调用 createCipheriv（或 createDeciperiv）时，node.js 代码会抛出“Invalid IV length”。

对于 128 位（16 字节）密码，AES 应该有一个 16 字节的初始化向量 (IV)。

这是一个错误还是我做错了什么？

I generate randomly IV value everytime I encrypt when doing AES/CBC.

And I concat IV Value to cipher byte everytime I encrypt.

Is there any secure improvement if I hash (SHA-256) IV value before concat to cipher byte?

我试图在加密之后但在写入之前将一个 16 字节的安全生成的 IV 附加到每个文件上。这样我就可以稍后通过从文件中提取 IV 来解密它。到目前为止，这是我的代码：

关于如何做到这一点的任何建议？

我需要一些帮助来验证下面的代码片段，以使用 CBC、PKCS5Padding 和 IV 进行 Java AES 加密。

我测试了代码并且能够加密和解密。我有一些疑问，如下所述。

1. 作为一个好的约定，密码应该存储在哪里？
2. 将盐和 IV 字节附加/检索到密文的方式是否正常？
3. 任何其他意见高度赞赏，谢谢！

我想向客户端提供一个加密的令牌，并且我正在使用 javax.crypto.Cipher 进行加密。根据我的阅读，不推荐使用 ECB 作为加密模式，因此我使用带有初始化向量的 CBC 和 TripleDES 作为密码方法。据我了解，有几点是正确的。

1. 更重要的是 IV 是随机的，并且每次加密都会初始化一个新的，而不是保密。
2. 必须使用相同的 IV 来加密和解密令牌。
3. 没有标准的方法来存储 IV 值，并且每个实现在这方面都可能不同。

因此，如果这些都是真的，我通过存储附加到加密字节数组的 IV 来完成我的实现，并且在解密阶段，IV 从字节数组中切出并用于解密。以下是 Scala 代码，但在 Java 中差别不大。

此外，字节数组在发送到客户端之前使用 org.apache.commons.codec.binary.Base64.encodeBase64String / decodeBase64 进行编码/解码。

所以我的问题是，这种将IV存储在与存储加密字符串相同的字节数组中的方法有什么问题或危险吗？是否有更好的选择来存储 IV:s？

我想将 AES 加密数据存储在数据库字段中。

存储密文前面的 AES IV（每行唯一）是否安全？例如

IV_密文

两者都将以 Base64 编码。

使用的密钥不会存储在数据库中。