可搜索加密 - tag - 沐木https://oldletter.cn/tags/%E5%8F%AF%E6%90%9C%E7%B4%A2%E5%8A%A0%E5%AF%86/可搜索加密 - tag - 沐木Hugo -- gohugo.iozh-cnSun, 10 Sep 2023 00:00:00 +0000可搜索加密：加密数据的模糊检索方案https://oldletter.cn/posts/crypto-06-searchable-encryption/Sun, 10 Sep 2023 00:00:00 +0000mumuhttps://oldletter.cn/posts/crypto-06-searchable-encryption/

作者:lin | 系列:密码学实战

一、问题背景:加密与检索的两难

数据库安全的成熟实践是:敏感字段落盘前加密。比如用户的手机号、身份证号、姓名,写入数据库时用 AES 加密成一串乱码。

但业务马上就会遇到一个问题:

-- 加密前,模糊查询很自然
SELECT * FROM users WHERE name LIKE '%张%';

-- 加密后,name 字段变成了 'a3f8b2c1d4e5...',LIKE 完全失效
SELECT * FROM users WHERE name LIKE '%a3f8%';  -- 这搜的是密文,不是张三

直接解密再搜索? 如果表有 1000 万行,每次查询都要全部解密再逐一比对,响应时间从毫秒级变成分钟级,完全不可接受。

保留明文索引? 那加密等于白做–索引泄露的信息量和明文几乎一样。

这就是**可搜索加密(Searchable Encryption, SE)**要解决的核心矛盾:如何在不暴露明文的前提下,高效地对加密数据做检索?

适用场景
可搜索加密不是银弹。它更适合的场景是:数据必须落盘加密(合规要求),同时业务需要检索能力,且可以接受一定程度的信息泄露(比如搜索模式泄露)。如果你的数据完全不需要检索,直接加密存储就好,不需要这些技术。

二、四种主流方案对比

方案一:桶索引(Bucket Index)

原理: 直接的思路–为每个关键词建立一个"桶",查询时直接定位到桶。

]]>