使用aes_cfb_encryptandaes_cfb_decrypt函数，我有以下问题。

1. 加密中的unsigned char *iv （初始化向量）是什么。
2. 是否需要保留*iv进行解密。
3. 每次我加密一个数据块时，*iv都会被修改，我对这个修改后的*iv有什么影响。

4. 我正在加密一个大约 100mb 的大文件，并第一次传递一个随机*iv，我是否必须在循环的其余部分使用相同的*iv，或者我必须使用上次调用中更新的*iv的加密块。

5. 最后，我正在处理一个结构化文件，所以我必须使用Sizeof(struct)作为缓冲区的长度还是必须使用sizeof(struct)*8作为缓冲区的长度来进行加密或解密。请指导..

AES_RETURN aes_cfb_encrypt(const unsigned char *ibuf, unsigned char *obuf, int len, unsigned char *iv, aes_encrypt_ctx cx[1]);

我面临一个奇怪的问题，我正在使用 cfb 模式的 aes 加密。进展顺利，我已经用固定 IV 测试了加密。但是当我使用随机 IV 时，问题就出现了。我去详细说。

上述代码的示例输出为 8229343736510872

当我在加密阶段使用此功能时，它可以，但是当我使用相同的密钥解密文件时，输出是垃圾。但是当我在加密阶段硬编码这个密钥时，解密成功。

我错过了什么。我将使用简单的随机数生成器。

我正在尝试解密已在 openssl 中使用 aes256 加密的 base64 字符串。我得到了会话密钥和 IV，它们是用我的密钥加密的。我将它们转换为十六进制，以便可以使用以下 openssl 命令：

我收到错误消息说 IV 是非十六进制值。我从使用我的密钥加密的 base64 中的 IV 和会话密钥开始。所以我做了以下事情：

//将base64转换为二进制

//使用我的私钥解密

//使用以下C代码转换为十六进制：

包括

//使用十六进制IV和密钥解密消息

我在最后一步得到错误，说 IV 不是十六进制的。有任何想法吗？

我知道使用唯一的初始化向量来加密每条记录是一种很好的做法，但是如何在该字段上进行搜索呢？

目前我使用单个 IV，这意味着我可以重建加密的搜索字符串，例如电子邮件地址并在数据库中查询该字段。如果我开始使用唯一的初始化向量，我将无法重建加密的搜索字符串。

我的环境是 ASP.NET、Entity Framework 和 SQL Server。也许这直接在数据库上更容易，但我的查询是通过 LINQ-to-Entities 进行的。

[我的第一个问题-最后我找不到答案！]

我的部门需要使用由另一个部门编写的加密库，问题是加密库已经硬编码了它的 AES 计数器模式初始化向量（全零）。（基本上，其他部门拿走了 Bouncycastle 库并在其周围包装了他们自己的损坏代码。）我们已经记录了此代码的问题，因此现在除非管理层决定采取行动，否则我们将被困在使用损坏的加密库.

我想知道我们是否可以通过在明文前面加上一个唯一的 IV 来伪造一个正确的初始化向量，然后在解密后截断明文的前 16 个字节，例如

这对我来说似乎很好，但我几乎不是密码学专家

I need to write a simplified encryption API that can easily deal with symmetric encryption, either by using a random generated key or a password-derived key.

The password generation is performed with the PKCS5_PBKDF2_HMAC() function from the OpenSSL library and using EVP_sha256() as hashing algorithm and a random generated 16-byte salt.

The symmetric encryption is performed with the OpenSSL EVP API.

My question is: how (in)secure is it to use the password derivation salt also as the IV for encryption?

The reason behind this question is that this will allow me to simplify the API and the output stream in the following way:

• for the encryption routine, a user would have to provide either the password or the secret key; based on whichever is provided, the code can decide if a key needs to be derived from the password or use the provided key as it is;
• similarly, for the decryption routine, a user would have to provide either the password or the secret key; based on whichever is provided, the key could be re-derived from the password and the IV, which is also acting as a password salt (and is put first in the output stream, right before the ciphertext);
• the output stream will consist only of the IV concatenated with the ciphertext, eliminating a separate salt;
• the output stream will be the same for a random generated key or a password-derived key.

Note: the API automatically takes care of the salt/IV generation, which is randomly generated for each encryption session, so even if a password is reused, the key is guaranteed to be different.

Thank you in advance for your answers.

我正在尝试将用于加密数据的 16 位 IV 添加为用于保存加密数据的字节数组中的最后一个块。我显然想为解密部分执行此操作，以便我可以为每个加密/解密调用使用完全随机的 IV。我有以下用于测试目的：

加密步骤列表如下：

1. 创建 IV
2. 加密数据
3. 将 IV 附加到加密数据字节数组的末尾
4. 使用十六进制编码字节数组

解密步骤列表如下：

1. 解码十六进制
2. 从字节数组中破解加密数据和 IV
3. 使用 IV 解密数据

我有什么作品，但我想我想知道的是，有没有“更好”的方式来做到这一点？我的意思是，是否有一套或更简单的方法来使用这些Cipher*类型来做到这一点？我找不到他们。

谢谢。

我在正确解密字符串时遇到了一些麻烦。令人愤怒的是，它只是前几个字节搞砸了，其余字符都是正确的。

因此，当我只是使用硬编码的 IV 进行加密和解密时，我的测试程序运行良好。该程序接受一个字符串，对其进行加密（使用 AES），然后我得到加密二进制文件的十六进制表示。当我试图将 IV 附加到密文的末尾时，问题就出现了。奇怪的是，十六进制字符串的长度在附加 IV 后并没有增加。但是，解密功能似乎是从密文末尾获取IV，否则它无法解密任何内容，对吧？

我尝试了很多不同的东西，比如创建一个精确大小的缓冲区，并使用memcpy. 这是代码：

AES 加密

AES 解密

这将产生输出：

如果我memcpy(cipherText + cipherTextLength, iv, 16);从加密函数中删除该行，并在解密函数的开头取消注释硬编码的 IV（并注释以下两行），则输出是正确的：

笔记！, 十六进制在两种情况下都是相同的。

谁能看到我在这里出错的地方。我以前遇到过类似的事情，但似乎不记得我是如何解决的。显然，在尝试附加 IV 时有一些事情正在进行中。有足够的空间cipherText来容纳 IV 的添加。

提前致谢。

所以我试图在一个 Objective-C 项目中使用 Crypto++ 的加密。问题在于如何处理 IV？我尝试将其预先附加到密文中。但是后来我在恢复它以进行解密时遇到了问题。

这是代码：

请注意，我需要将 5 添加到预期的 iv 大小才能获得完整的 IV。然后我收到一个关于“发现无效的 PCKS#7 填充。无效的密文”的错误

如何最好地管理静脉输液？（我还想在 iv+ciphertext 中添加一个 HMAC（Encrypt-then-MAC）...

如果我这样做：

日志将显示仍然在密文中的一些 IV 字节，并生成“无效密文，大小不是块大小的倍数”异常。

日志：

请注意，在我尝试撤销它之后，IV 的一部分仍然在密文前面。这是为什么呢？

我在客户端生成初始化向量，其中消息被加密，然后与向量一起发送到服务器进行解密。

客户代码：

服务器代码

我得到以下异常：

例如，如果我为缓冲区分配 1024 个字节，则将 32 个大小的 byte[] 发送到服务器，但在服务器上将生成一个 1024 个大小的 byte[]：

我是否走在正确的道路上？