加密基础理论：对称加密、非对称加密、哈希算法、数字签名

各位同学，这一章我们聊点实在的。加密基础理论，说白了就是 SDK 开发的「内功心法」。你可能用过各种加密库，但如果你不理解背后的原理，遇到坑的时候就会被卡住。我个人习惯是先搞清楚“为什么”，再去写代码。今天我就把这四个核心概念掰开揉碎讲一遍。

对称加密：一把钥匙开一把锁

这是最直观的加密方式。加密和解密用同一把钥匙。

想象一下，你有个带锁的盒子。你用钥匙锁上，收件人用同一把钥匙打开。这就是对称加密。速度快，适合加密大量数据。我当年做金融数据接口时，交易报文加密清一色用的 AES（Advanced Encryption Standard）。

非对称加密：公钥锁、私钥开

对称加密有个大麻烦：你怎么把钥匙安全地传给对方？非对称加密就是为了解决这个痛点。

它有两把钥匙：

• 公钥：公开的，谁都能拿。
• 私钥：保密的，只有自己知道。

公钥加密的数据，只能用私钥解密。反过来，私钥签名的数据，公钥可以验证。

为什么这很重要？你想想看，你在做 SDK 时，客户端和服务端第一次握手，怎么确定彼此身份？非对称加密就是答案。

哈希算法：不可逆的指纹

哈希算法不是加密，它不可逆。你把任意长度的数据丢进去，它吐出一段固定长度的摘要。这个过程有去无回。

常用的哈希算法有：

• MD5：128 位，已经不安全了，碰撞攻击很容易。别用了。
• SHA-1：160 位，同样不推荐。谷歌在 2017 年就演示了碰撞。
• SHA-256：256 位，目前最常用的选择。
• SHA-3：新一代标准，为了防量子计算做准备。

哈希的应用场景很多：

1. 数据完整性校验：下载文件后比对哈希值，确认没被篡改。
2. 密码存储：数据库里存密码的哈希值，而不是明文。
3. 唯一标识：用内容的哈希作为唯一 ID。

数字签名：你是谁？你说了算不算？

数字签名，是哈希算法与非对称加密的结合体。

流程是这样的：

• 发送方对消息做哈希，得到摘要。
• 用私钥加密这个摘要，形成数字签名。
• 接收方用公钥解密签名，得到一个摘要。
• 接收方自己再对消息做哈希，得到另一个摘要。
• 两个摘要对比，一致则验证通过。

这样就解决了三个问题：

• 完整性：消息中途被改，哈希值就对不上。
• 身份认证：只有私钥持有者才能生成有效签名。
• 不可否认：签名者事后无法抵赖。

我记得有一次，客户问「接口签名怎么防重放攻击」。答案是在签名时加入时间戳和随机数，让每次签名的结果都不同。这个后面讲，你们先记住数字签名是认证的核心工具。

四种算法对比

把这些放在一起看，就知道谁该在什么时候用了。

避坑指南

我曾经在一次接口调试中，发现对方用 MD5 做签名校验。我当时就笑了——MD5 的碰撞攻击已经非常成熟，这等于没锁门。换了 SHA-256 后，问题立刻解决。

还有一次，团队新人直接用 RSA 加密了整个 10MB 的请求体，结果接口超时报错。我帮他改成 AES 加密内容，RSA 只加密 AES 密钥，性能提升了 40 倍。

所以各位，SDK 开发不是简单的调库，你得选择正确的工具，放在正确的位置。加密基础理论，就是帮你做出这些选择的理论根基。今天的内容，我希望你不仅仅是记住概念，更要在写代码时，脑子里有这张图——什么场景用什么算法，为什么用，用错了会出什么乱子。

嗯，今天就聊到这里。记得多动手写代码，把理论落在地上。