安全实践AESRSA签名Base64JSON
加密落地备忘：AES怎么配、RSA何时用、哪些坑别再踩
我把加密这事儿当工具活，不神秘，但要把细节踩稳。很多翻车并不是算法不够强，而是“模式、填充、字符集、编码”四件小事没对齐。下面按我在项目中的固定做法梳理一遍，尽量可复用。
先分层：传输保密 vs 身份认证 vs 完整性
- 我会把目标拆三层：
- 保密性：内容只让应看的读，典型用对称加密（AES）。
- 身份认证：确认发送方是谁，常见用非对称签名（RSA/ECDSA）。
- 完整性：内容没被改动，签名或MAC（HMAC/GMAC）保证。
- 一开始就写清楚“谁生成什么、谁验证什么、谁保存什么”。这份“责任分工表”比任何代码都重要，后面联调靠它对表。
AES 怎么配：模式、填充、向量、编码
- 模式：我在通用场景优先 CTR 或 CBC。CTR 便于并行也不需要填充；CBC 更常见但要填充。ECB 我只在教学或极端兼容下做对比，不用于生产。
- 填充：CBC 下我默认 Pkcs7；ZeroPadding/NoPadding 需要严格对齐明文长度，一般不推荐。
- 密钥长度：16/24/32 字节分别对应 128/192/256 位。写死在接口文档里，别“约定在口头”。
- IV：16 字节；CBC/CFB/OFB/CTR 必需（ECB 不要 IV）。IV 不是密钥，可以明文传，但要“唯一且不可预测”。
- 字符集与输入输出格式：我会把“明文字符串→字节”的字符集固定成 UTF-8；密文落盘或上链路时统一 Base64。调试期我会保留 HEX 视图方便定位。
使用工具时，我会在下面这几步反复核对：
- 在 AES 工具里先用“已知样例”验证：同一明文、同一密钥、同一 IV、同一模式与填充，前后端得到的密文 Base64 必须一致。
- 把密钥、IV、明文、密文四份材料以 JSON 形式存档到联调文档，谁都能用来复现。
可用工具：
RSA 何时用：别拿 RSA 加大文本
- 我把 RSA 放在“交换对称密钥”和“做签名”上，而不是加密大块数据。原因很简单：
- 性能：RSA 加密大文本慢且受密钥长度限制；
- 安全：对称密钥+对称算法的组合（即“混合加密”）既快又成熟。
- 流程模板：
- 客户端随机生成会话密钥（AES-256）。
- 用服务端的 RSA 公钥加密这个会话密钥，作为 header/字段发给服务端。
- 业务数据用 AES-CTR/CBC 加密，密文与随机 IV 一起走。
- 服务端用私钥解出会话密钥，再解业务密文。
可用工具：
签名与验签：把“顺序与编码”钉死
- 我遇到最多的问题是“字段顺序、空白、编码差异”。现在我会：
- 先把待签名字段按固定顺序串联（如字典序+用&拼接）。
- 所有字符串统一 UTF-8；二进制转 Base64 参与签名时，说明“是否含换行”。
- 签名结果统一 Base64 输出，服务端验签同路径还原。
- 对“可选字段为空时是否参与签名”，一定在文档里示例清楚，否则环境切换就炸。
名词解释（便于拉齐认知）
- CBC/CTR：前者分组链式，需填充；后者把分组变流，通常无需填充，错误不会扩散。
- PKCS#7：块加密常用填充规范，N 字节块，最后补 (N − (len mod N)) 个同值字节。
- IV（初始化向量）：不是密钥，要求唯一和随机性，用来打破重复模式。
- Base64：不是加密，只是可见字符编码，便于在 URL/JSON/表单中传输二进制。
- 签名 vs 加密：签名解决“你是谁+有没有改”；加密解决“别人看不懂”。
问与答（取自真实对话）
Q：为什么我的 AES-ECB 能跑通，大家还说不安全？
A：ECB 对相同明文块输出相同密文块，会露出“图案”，容易被频率分析。能跑不等于稳妥，换 CTR/CBC。
Q：IV 可以用固定值吗？
A：绝对不行。固定 IV 会让相同前缀明文暴露模式。生成随机 IV，并把 IV 与密文一起传输。
Q：签名是先编码还是先排序？
A：先约定字段、排序方式，再编码成字节流，最后计算签名。任意一步顺序不同都会导致验签失败。
我现在的“交付清单”
- 密钥长度/模式/填充/字符集/编码/IV 生成方式，一行不落写在对接文档；
- 一份可复现样例（明文、密钥、IV、密文、签名）放 JSON 文档；
- 两端各自用工具核对一遍，再接入代码；
- 针对错误信息写“FAQ”，以后遇到直接对号入座。