1. 加密技术基础
做多语言加密SDK适配，你必须先把地基打牢。加密技术听起来高大上，说白了就是两件事：保秘密、验身份。我从入门到现在十几年，踩过的坑不少，尤其跨语言调用时，算法选错、填充模式不一致，跑出来的结果牛头不对马嘴。这一章我们把对称/非对称加密、哈希函数、数字签名、国密算法过一遍，后面实战才不会翻车。
1.1 对称加密与非对称加密
加密算法分两大派。对称加密，加密和解密用同一把钥匙。你想想看，就像俩人都拿一样的钥匙开同一把锁。优点是快，适合加密大量数据，比如文件、通信流。缺点是密钥分发难——你总得先把钥匙安全地递给对方吧？
我个人习惯把对称加密比作「快递柜」。你放进去，对方用同样的密码开锁。常用的算法有：
- AES（128/192/256位）—— 全球通用，SDK基本都支持。
- SM4 —— 国密标准，在国内金融、政务项目必须用。
- DES/3DES —— 老古董了，我建议新项目放弃它。
非对称加密就不同了。公钥加密，私钥解密。公钥谁都能拿，私钥只能自己收好。我记得第一次用RSA时，觉得「公开密钥还能安全？」实际上，你只要私钥不泄露，别人就算拿到公钥也解不开。但缺点是慢，比对称加密慢几百倍。所以实际项目中常把两者结合起来：用非对称加密传输对称密钥，再用对称密钥加密数据。这就是混合加密。
核心区别速览：
| 特性 | 对称加密 | 非对称加密 |
|---|---|---|
| 密钥数量 | 1个（对称密钥） | 2个（公钥 + 私钥） |
| 速度 | 快（硬件加速后可达Gbps） | 慢（RSA 2048位签名每秒千次级） |
| 密钥分发 | 困难（需安全通道） | 容易（公钥公开） |
| 典型算法 | AES、SM4 | RSA、SM2 |
| 典型用途 | 大量数据加密 | 密钥交换、数字签名 |
避坑指南： 我曾经在对接Java SDK时，发现两边AES加密结果不一样，查了一天才发现是填充模式一个用了PKCS5Padding，一个用了PKCS7Padding。记住：跨语言时务必备注填充模式、IV值、密钥长度，否则又得改代码。
1.2 哈希函数
哈希函数不是加密，它不「加」也不「解」。它干一件事：输入任意长度数据，输出固定长度摘要（哈希值）。你想想看，就像给文件算个指纹——只要内容动一个比特，指纹就全变了。
我经常跟新同事说：哈希是密码学的「反向工程」。你不能从摘要反推原文，这叫单向性。还得保证两个不同原文几乎不可能算出同一个摘要，这叫抗碰撞性。常见的哈希算法有：
- MD5 —— 128位，已经能被碰撞攻击，别用在签名上了。我用来做文件校验，也只做辅助。
- SHA-1 —— 160位，理论上已被攻破，但工业中还有遗留。新项目直接上SHA-256。
- SHA-256 —— 256位，目前最靠谱，区块链和HTTPS都在用。
- SM3 —— 国标256位，强度和SHA-256相当。国内合规必备。
哈希在加密SDK里的典型场景：消息完整性校验、用户密码存储（加盐防彩虹表）、数字签名中的摘要生成。对了，密码存储千万别直接用MD5——我见过一个项目，用户密码直接MD5存库，猜猜后来怎么着？被脱裤后全跪了。
⚠️ 重要提醒： 哈希算法「无密钥」，所以不能用来加密。如果你看到有人说「用MD5加密数据」，说明他还不够专业。哈希是哈希，加密是加密，两个概念。
1.3 数字签名
数字签名，说白了就是「电子盖章」。你发出一份文件，怎么证明是你发的？怎么保证文件没被改过？签名就能搞定。
过程很简单：发送方先对文件原文算哈希，然后用自己的私钥加密这个哈希，签名就生成了。对方收到后，用你的公钥解密签名，得到哈希值，再跟文件原文算一遍哈希。两个哈希一比，一样就证明没被改。
这里要注意：数字签名用的是「私钥签名，公钥验证」，跟加密的顺序反着来。我记得刚开始做SSL证书时，总把签名和加密搞混。其实记住一句话就行：「私钥签，公钥验；公钥加，私钥解」。
实际应用中，SDK里签名主要出现在：
- 代码签名 —— 防止注入、防篡改。
- API请求签名 —— 如微信支付、阿里云SDK都会要求对参数签名。
- 证书与PKI —— 数字证书本质上就是签名过的公钥。
我的经验： 多语言环境下签名最常见的问题是私钥格式不统一。比如Python读PEM，Java读DER，C++可能需要PKCS#12。我曾经在Go里用openSSL读取Java生成的.p12，折腾了半天才发现是密码编码方式不同。提前约定好密钥交换格式（PEM+PKCS8+base64），能省很多时间。
1.4 国密算法概述
国密算法是国家密码管理局发布的商用密码标准。现在做to G、to B的项目，只要涉及数据安全，十有八九绕不开国密。作为加密SDK适配者，你必须知道这三兄弟：
| 算法 | 类型 | 对标国际 | 典型用途 |
|---|---|---|---|
| SM2 | 非对称加密 | 对标RSA/ECDH | 密钥协商、数字签名、加密通信 |
| SM3 | 哈希函数 | 对标SHA-256 | 完整性校验、数字签名摘要 |
| SM4 | 对称加密 | 对标AES-128 | 大量数据加密、VPN、数据库加密 |
我最早接触国密是2017年做某银行项目，客户要求必须用SM2做电子签章。那时候SDK还不成熟，各种坑——SM2公钥压缩格式、C1C3C2顺序、椭圆曲线参数……后来逐渐标准化了。现在主流加密库（比如OpenSSL、Bouncy Castle、GmSSL）都支持国密，适配起来跟国际算法差不多，但细节上仍要小心。
举个例子：SM4的密钥长度128位，这和AES-128一样。但SM4的S盒、密钥编排算法全不同。如果你用AES的API去调用SM4，结果肯定是错的。
一句话总结： 国密不是「切换算法名称」就完事了。你需要确保底层库、填充方式、参数顺序全部匹配。后面章节我会手把手带你过这些坑。
看到这张图你大概就明白了。加密技术基础分为三大块：对称与非对称加密保机密性，哈希函数保完整性，数字签名保身份和防抵赖。而国密算法则是在这三块里分别选了一个中国自己的标准。后面每一章，我们都会深入到具体算法的SDK适配细节中。