加密列不解密或分组的mysql连接查询

我在一个表上查询了一些加密字段，如下所示：

SELECT groups.`group_id` AS id, `description_s`, 
  AES_DECRYPT(`description_l`, 'decryption_key') AS `description`, 
  AES_DECRYPT(groups.`email`, 'decryption_key') AS email,
  ...
FROM groups
WHERE ...
GROUP BY `id`, `description_s`,`description`,`email`,...
ORDER BY id DESC

这和预期的一样，给了我解密的输出。但是，如果我将联接添加到另一个表中

SELECT groups.`group_id` AS id, `description_s`, 
  AES_DECRYPT(`description_l`, 'decryption_key') AS `description`, 
  ...
FROM groups
INNER JOIN details on details.`group_id` = groups.`group_id`
WHERE ...
GROUP BY `id`, `description_s`,`description`,`email`,`customer_name`
ORDER BY id DESC

结果列不再被解密，只有当我将AES_DECRYPT（

description_l

，dec_key）而不是别名

description

放在“group by”子句中时，分组才会起作用。仍然给我留下加密列

我通过使用子查询和在外部进行解密找到了一个解决方法

SELECT id,description_s, AES_DECRYPT(`description_l`,  'decryption_key') as description
FROM (
   SELECT groups.`group_id` as id, `description_s`, `description_l`
   FROM groups
   INNER JOIN details ON details.`group_id`=groups.`group_id`
   WHERE ... 
   GROUP BY `id`, `description_s`,description_l
) subq
ORDER BY id DESC

---

我很想知道到底发生了什么事。在上面的第二个示例中，为什么列根本没有被解密？有没有一种方法可以在不使用子查询的情况下获得分组的解密结果？

首先，您在数据库中执行加密的动机是什么？您是否知道（在大多数情况下）它提供的安全性非常低，因为明文与解密密钥一起发送到RDBMS或从RDBMS发送出去？受损RDBMS=游戏结束。受损的应用程序服务器=游戏结束。唯一的保护措施是防止密钥不可用的静态攻击，但它可能存在于同一台机器的某个地方，内存中或日志中或磁盘上的其他位置（例如存储它的文件）。其次，它-你能更新小提琴来显示你的问题吗？我不知道，不幸的是，我使用的是遗留数据库。我知道加密密钥会随每个查询一起发送，可能会出现在所有日志中。我看着小提琴，惊讶地发现它在工作。但我最终发现字段定义是不同的（我用'blob'代替'varbinary'）。我将fiddle更改为blob，尽管行为仍然与我的行为不完全相同（分组仍然有效），但描述字段现在不再在第二个查询中解密。所以我想我的答案是。。。BLOB不好？当我将

VARBINARY

更改为

BLOB

时，唯一的区别是在第二个查询中得到的

description

列是一个二进制字符串，而不是一个字符串。如果不进一步调查，它可能是一个bug-尽管相对较小，因为返回的数据仍然是正确的。我想，如果你仔细想想，就没有办法让

AES_DECRYPT（）

知道应该在哪个字符集中返回解密的数据；因此，它是一个二进制字符串是有意义的。我不知道为什么第一个/未连接的查询返回字符串。可以使用显式返回相应字符集中的结果二进制字符串。