添加 MCrypt 的 AES-CBC 加密后数据未保存到数据库或未正确解密

Data is not saved into database or not properly decrypted after adding MCrypt's AES-CBC encryption

我写的加密脚本有问题。我有数百个输入,因此我使用桶排序算法作为 "in-script" 数据库,以避免处理数百 MySQL 列的麻烦,更不用说它节省了代码 space.数据存储在 SQL 数据库的一列中。条目由 ' 分隔,该条目中的变量由 > 分隔。这就是为什么我用字符串替换加密的最终结果...以避免产生额外的分隔符。

加密:

$iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_128, MCRYPT_MODE_CBC);
$iv = mcrypt_create_iv($iv_size, MCRYPT_DEV_URANDOM);
$key = pack("H*", "**64CharacterStringHere**");

$value = mcrypt_encrypt(MCRYPT_RIJNDAEL_128, $key, $value, MCRYPT_MODE_CBC, $iv);

$value = $iv . $value;

$value = str_replace (">", "9Y6SnNmOBl", $value);
$value = str_replace ("'", "SxsNEpBe18", $value);   

解密:

$value = str_replace ("9Y6SnNmOBl", ">", $value);
$value = str_replace ("SxsNEpBe18", "'", $value);

$iv = substr($value, 0, 16);
$value = substr($value, 16);

$key = pack("H*", "**64CharacterStringHere**");

$value = mcrypt_decrypt(MCRYPT_RIJNDAEL_128, $key, $value, MCRYPT_MODE_CBC, $iv);

如果我从我的代码中省略这个片段,它会完美运行。数据显示和保存正常。但是,如果我添加这段代码,有时数据根本不会被保存,并且如果它至少有一个变量由于某种原因没有被解密,即使我 100% 确定该函数正在 运行在每个变量上,因为该函数不仅仅是加密和解密。

我完全不知道为什么会这样。

MySQL 查询:

$new_accountant = "'" . $var_1 . ">" . $var_2;
$new_string = $string . $new_accountant;

$new_entry_query = 'UPDATE phone_tree SET string="' . $new_string  . '" WHERE id="' . $userid . '";';
mysql_query($new_entry_query);

在上面的脚本中,$string 由 MySQL 查询定义,该查询获取包含到目前为止所有数据的列的当前值。

我现在正在弄乱它。大约有一半的时间它根本不保存,而当它保存时,大约有一半的时间变量没有被正确解密。

我怀疑这与我如何存储 IV 有关...它与变量有关,但我不知道我在做什么是一个问题。

在我看来,您的 MySQL string 列是用 varchar(nnn) 数据类型定义的。对吗?

如果是这样,我建议您先对加密的 material 进行 base-64 编码,然后再将其存储到 MySQL,然后再进行 base-64 解码?这是加密信息传输和存储的常见做法。它使您的 material 字符串安全。 MySQL 可能会破坏您的二进制数据。

base-64 字符集(由 php 中实现的 base-64 的 MIME 版本使用)仅包含 7 位 ASCII 字符。它包括数字、大小写字母和字符+ / =。这很好,因为您选择的分隔符 (> ') 不会出现在编码文本中,因此您可以摆脱符号填充 str_replace ("9Y6SnNmOBl", ">", $value) 代码。

在编码时执行此操作,并跳过符号填充。

$value = base64_encode($iv . $value);

在解码时执行此操作,并跳过符号取消填充。

$value = base64_decode($value);
$iv = substr($value, 0, 16);
$value = substr($value, 16);

这会使您的加密数据比其他方式大 1.3 倍。这在现代大容量存储价格中并不算多,而且是为简单性而付出的合理价格。如果它提出了无法克服的成本障碍,您可以在 MySQL.

中研究压缩行格式