📚 课程目录第2章密码学基础

2、密码学基础：对称加密、非对称加密、哈希函数

做移动端密文检索，绕不开这三个老伙计：对称加密、非对称加密、哈希函数。你得先弄明白它们各自在干什么，才能在设计 SDK 的时候不掉坑里。

我说白了，这三样东西没有哪个是万能的。你想想看，要是哈希就能解决所有问题，那还要加密干嘛？我刚开始接触密文检索时，也觉得对称加密包打天下，后来被甲方拿着合规清单一问，才发现全是漏。

对称加密，就是加密和解密用同一把钥匙。密钥不能泄露，否则一切归零。在移动端，密钥一般存储在安全区域（比如 iOS 的 Keychain、Android 的 TEE），应用层拿到的是经过封装后的句柄。

常见的对称算法

我个人习惯用 AES-256-GCM。为什么？因为 GCM 模式自带认证标签，能防篡改。你想想看，要是只用 CBC 模式，攻击者修改密文后服务端解密出来的结果是什么？牛头不对马嘴，而且你不知道有没有被改过。

避坑指南：我曾经在项目里直接用了 ECB 模式，结果数据分布规律在密文上完全暴露，密文检索直接废了。记住：永远不要在密文检索场景里用 ECB。

对称加密的优点是快。移动端每秒能跑几十 MB 的 AES，适合加密大量正文内容。缺点是密钥分发难。你给每个用户发同一把钥匙？那跟不加密有啥区别。

非对称加密用一对钥匙：公钥加密，私钥解密。公钥可以公开，私钥自己保管。这玩意用在密钥交换、数字签名、身份认证上。

常见非对称算法

算法	性能	推荐密钥长度	主要用途
RSA	慢	2048 / 4096 bits	密钥传输、签名
ECC（椭圆曲线）	快	256 bits（等效 RSA 3072）	密钥协商、轻量级签名
SM2	中等	256 bits	国密体系

在移动端，非对称加密一般只用来加密对称密钥。什么意思？用户 A 想给用户 B 发一段密文，但 B 没有共享密钥。这时候 A 用 B 的公钥加密一个随机生成的对称密钥（比如 AES 的 Session Key），B 用私钥解密得到它，后续对话就用对称加密。

嗯，这里要注意：非对称加密没法加密大段数据。我试过用 RSA 加密一张照片，几百毫秒才出来，手机直接卡成 PPT。所以记住原则：非对称加密只加密密钥，不加密正文。

哈希函数把任意长度的数据变成固定长度的指纹（摘要）。它不可逆，只能从输入到输出，不能从输出反推输入。特性：相同输入 → 相同输出；输入变一点点 → 输出完全不一样。

常用哈希算法

算法	输出长度	安全性	移动端速度
SHA-256	256 bits	高	快
SHA-3	可配置	极高	快
SM3	256 bits	高	快
BLAKE2	可配置	高	更快

哈希在密文检索里的作用非常关键：我们经常用哈希值构建索引。比如用户输入的查询关键词，先算哈希，再去已加密的索引里匹配。注意：这不是明文匹配，而是密文上的哈希匹配。

警告：直接对原始数据做哈希，容易遭到彩虹表攻击。一定要加盐（Salt）。我曾经在前期版本里忘了加盐，用户搜索记录被枚举出来一堆常见词，差点背锅。

做密文检索 SDK，通常的套路是：

你看，三个技术串起来，才算一套靠谱的密文检索方案。单独用哪一个都有漏洞。

我的建议：别自己造轮子。直接用 iOS 的 CommonCrypto 或 Android 的 AndroidKeyStore + javax.crypto。这些系统库已经封装好了算法选择和密钥保护，比你自己手写 OpenSSL 要安全得多。

对称加密别用静态密钥：每个会话、每条数据的密钥最好独立生成。我见过一个 APP 把所有用户数据都用同一把硬编码在代码里的 AES 密钥加密，反编译一下连源码带密钥全曝光。
非对称加密不要加密大文件：效率太低。哪怕 RSA 加密一个 256 位的 AES 密钥都够呛，加密大文件直接卡死。
哈希必须加盐：不加盐的哈希就是给攻击者递字典。我曾经在一个 demo 里偷懒没加盐，结果内部测试时用彩虹表 3 秒破了一堆关键词。
密钥保管走硬件隔离：iOS 的 Secure Enclave、Android 的 TEE，能用的都用上。别把密钥裸存到 SharedPreferences 或 UserDefaults 里。

好了，密码学基础就聊到这儿。记住：对称加密管「机密性」，非对称加密管「密钥分发」，哈希管「完整性与索引」。三者在移动端密文检索里各司其职，少了谁都会出问题。