数据库

MySQL利用AES_ENCRYPT()与AES_DECRYPT()加解密的正确方法示例
数据库 2024/11/5 佚名
3 2

前言

最近在工作中遇到一个需求是这样的：需要在使用AES_ENCRYPT()函数将明文加密，存储在MySQL中，但是遇到了一些问题……下面就来详细介绍下。

说将加密后的密文，解密取出来是NULL。

看了一下，她发过来的表结构：

MySQL利用AES_ENCRYPT()与AES_DECRYPT()加解密的正确方法示例

再看了她通过AES_DECRYPT()函数加密了一个字符串，然后insert进去了，执行成功后，显示了一个warning：
Query OK, 1 row affected, 1 warning (0.00 sec)

（没有报错而是warning，大概是sql_mode的缘故）

此时她忽略了这个warning，再通过AES_DECRYPT()解密后，发现取出来的明文为NULL。

再回看表结构，发现其字段属性为“varchar” && 字符集是ut8，检查warning为下：

mysql> show warnings;
+---------+------+------------------------------------------------------------------------+
| Level | Code | Message        |
+---------+------+------------------------------------------------------------------------+
| Warning | 1366 | Incorrect string value: '\xE3f767\x12...' for column 'passwd' at row 1 |
+---------+------+------------------------------------------------------------------------+
1 row in set (0.00 sec)

查了一下文档，看一下这两个函数的使用：

-- 将'hello world'加密，密钥为'key'，加密后的串存在@pass中
mysql> SET @pass=AES_ENCRYPT('hello world', 'key'); 
Query OK, 0 rows affected (0.00 sec)

-- 看一下加密后串的长度（都为2的整数次方）
mysql> SELECT CHAR_LENGTH(@pass);
+--------------------+
| CHAR_LENGTH(@pass) |
+--------------------+
| 16   |
+--------------------+
1 row in set (0.00 sec)

-- 使用AES_DECRYPT()解密
mysql> SELECT AES_DECRYPT(@pass, 'key');
+---------------------------+
| AES_DECRYPT(@pass, 'key') |
+---------------------------+
| hello world  |
+---------------------------+
1 row in set (0.00 sec)

那么到底该如何存呢？

方法①：

将字段属性设置为varbinary/binary/四个blob类型，等二进制字段属性。

创建三个字段，属性分别为varbinary、binary、blob。

并将'明文1'，'text2'，'明文_text3'加密，密钥为key，存入表中。

最后取出。

mysql> CREATE TABLE t_passwd (pass1 varbinary(16), pass2 binary(16), pass3 blob);
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO t_passwd VALUES (AES_ENCRYPT('明文1', 'key'), AES_ENCRYPT('text2', 'key'), AES_ENCRYPT('明文_text3', 'key')); 
Query OK, 1 row affected (0.01 sec)

mysql> SELECT AES_DECRYPT(pass1, 'key'), AES_DECRYPT(pass2, 'key'), AES_DECRYPT(pass3, 'key') FROM t_passwd;
+---------------------------+---------------------------+---------------------------+
| AES_DECRYPT(pass1, 'key') | AES_DECRYPT(pass2, 'key') | AES_DECRYPT(pass3, 'key') |
+---------------------------+---------------------------+---------------------------+
| 明文1   | text2   | 明文_text3   |
+---------------------------+---------------------------+---------------------------+
1 row in set (0.00 sec)

当然，属性括号内的长度要取决于明文的长度，此处明文较短，故只给了16。

方法②：

将密文十六进制化，再存入varchar/char列。

此处需要用到HEX()来存入，用UNHEX()取出。

创建一个字符串属性的字段。

将'hello world'先用密钥'key2'进行AES加密，再将加密后的串通过HEX函数十六进制化。

最后先将加密后的串通过UNHEX取出，再通过AES据密钥'key2'解密：

mysql> CREATE TABLE t_passwd_2(pass1 char(32));
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO t_passwd_2 VALUES (HEX(AES_ENCRYPT('hello world', 'key2')));
Query OK, 1 row affected (0.00 sec)

mysql> SELECT AES_DECRYPT(UNHEX(pass1), 'key2') FROM t_passwd_2; 
+-----------------------------------+
| AES_DECRYPT(UNHEX(pass1), 'key2') |
+-----------------------------------+
| hello world   |
+-----------------------------------+
1 row in set (0.00 sec)

同样，根据明文的长度不同，AES_ENCRYPT加密后的串长度也会有所变化，所以HEX后的字符串长度也会有所变化。
实际使用时，需要据业务评估出一个合理值即可。

方法③：

直接存入varchar中，不做十六进制化。

回溯到问题的一开始，将加密后的串，存到utf8字符集并且属性为varchar中，是不行的。

实际上，将字符集改成latin1就可以了：

在insert的时候也不会报warning了。

mysql> CREATE TABLE t_passwd_3(pass varchar(32)) CHARSET latin1;
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO t_passwd_3 SELECT AES_ENCRYPT('text', 'key3');
Query OK, 1 row affected (0.00 sec)
Records: 1 Duplicates: 0 Warnings: 0

mysql> SELECT AES_DECRYPT(pass, 'key3') FROM t_passwd_3;
+---------------------------+
| AES_DECRYPT(pass, 'key3') |
+---------------------------+
| text   |
+---------------------------+
1 row in set (0.00 sec)

这样的方法虽然美，只需将字段字符集设置为latin1就可以了，但可能会带来隐患：

文档上写了这样的一句：

Many encryption and compression functions return strings for which the result might contain arbitrary byte values. If you want to store these results, use a column with a VARBINARY or BLOB binary string data type. This will avoid potential problems with trailing space removal or character set conversion that would change data values, such as may occur if you use a nonbinary string data type (CHAR, VARCHAR, TEXT).

大意是，如果用方法③那样，直接将加密后的串存入char/varchar/text类型中，在做字符转换的时或空格被删除时，可能会带来潜在的影响。

所以如果一定要存在char/varchar/text中，那么还是参考方法②，十六进制化一下吧。

或者如同方法①，直接存在二进制字段中。

总结

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作能带来一定的帮助，如果有疑问大家可以留言交流，谢谢大家对的支持。

参考文档：

Chapter 12 Functions and Operators - 12.13 Encryption and Compression Functions

标签：
mysql,aes,encrypt,mysql,aes,decrypt,mysql,aes加密
免责声明：本站文章均来自网站采集或用户投稿，网站不提供任何软件下载或自行开发的软件！ 如有用户或公司发现本站内容信息存在侵权行为，请邮件告知！ 858582#qq.com
白云城资源网 Copyright www.dyhadc.com
www.dyhadc.com 白云城资源网
129,905影音资源
244,626技术资源
111,817软件资源
578,645站长资源
一句话新闻
一口气升级7个大模型SaaS应用，百度智能云：突出一个“开箱即用” - 2024/11/5

这一波大模型产业落地浪潮里，不少企业其实处在 “干瞪眼“的状态。

一种情况是，很多大模型产品看得见却摸不着，在台上一个个遥遥领先——今天Sora技精四座，明天英伟达的机器人又赢得满堂彩，可是到了台下一问：啥时候能用上啊？答曰：遥遥无期。

另一种情况是，企业想用上大模型，却又难免瞻前顾后——既要考虑场景融合，又得兼顾安全性，还要考虑打通现有系统，再加上各种部署成本和繁琐的采购流程……最后只能拂袖：罢了，再等等吧。

稳了！魔兽国服回归的3条重磅消息！官宣时间再确认！

昨天有一位朋友在大神群里分享，自己亚服账号被封号之后居然弹出了国服的封号信息对话框。

这里面让他访问的是一个国服的战网网址，com.cn和后面的zh都非常明白地表明这就是国服战网。

而他在复制这个网址并且进行登录之后，确实是网易的网址，也就是我们熟悉的停服之后国服发布的暴雪游戏产品运营到期开放退款的说明。这是一件比较奇怪的事情，因为以前都没有出现这样的情况，现在突然提示跳转到国服战网的网址，是不是说明了简体中文客户端已经开始进行更新了呢？

更新日志

友情链接

杰晶网络 DDR爱好者之家 南强小屋 黑松山资源网 白云城资源网 更多链接
白云城资源网 Copyright www.dyhadc.com