信息安全AESRSAMD5Base64URL编码
加密与哈希实用手册：从AES到RSA，网页常见数据安全处理
在网页与小型工具开发中，我们经常需要处理“安全相关”的小任务：例如临时对一段敏感文本做加密、对文件指纹做校验、在URL里安全地传参、把二进制片段转成可传输的文本格式等等。这些工作并不是大型安全系统，却常常决定了数据是否会在传输、拼接、存储时被意外破坏，或者是否因实现细节错误而“明文裸奔”。本文从工程实践出发，把前端可立即上手的几类常见方案串起来，强调“何时用、怎么配、容易错哪里”，并附上在线工具方便即用即测。
一、AES 对称加密：快速、安全、可控
AES 是浏览器端常见的对称加密方案。它的优势是实现成熟、速度快、移动端也能承受。实际使用中需要重点关注三件事：密钥长度、加密模式、填充方式。
- 密钥长度：对应 AES-128/192/256，密钥字节数必须分别为 16/24/32；否则就是“看起来能填进去，但实际解不开”。
- 加密模式：CBC、CTR、CFB、OFB、ECB。ECB 因为“相同明文块→相同密文块”的特征不推荐；CTR/CFB/OFB 属于流式模式，一般无需填充；CBC 常见、好用，但一定要配合随机 IV。
- 填充：Pkcs7 常用、稳妥；禁用填充时要保证明文块对齐，否则必出错。
工程里最容易忽视的是 IV 的随机性与唯一性。尤其在 CBC/CTR 类模式中，“相同密钥 + 重复 IV”会泄露结构信息。实践准则是：每次加密生成新的 IV，将 IV 以明文与密文一起存储或传输（这不降低安全性）。另外，字符集/编码也要统一，Web 端建议统一 UTF-8。
二、RSA/ECDSA：密钥对、签名与交换
当你需要“对外公开公钥、仅自己持有私钥”的场景（如签名、授权、握手），就该考虑非对称方案。RSA 仍是多数开发者最熟悉的选择，2048 位长度起步更现实；若追求更小密钥与更高性能，可考虑 ECDSA（P-256 等曲线）。
几个落地建议：
- 仅在浏览器侧“生成键值”并短期保存，避免上传私钥；
- 输出采用标准格式：公钥 X.509 SPKI、私钥 PKCS#8，便于系统间互通；
- 对“签名”和“加密”概念要区分：签名保障完整性与不可抵赖，加密保障机密性；
- 生产环境仍建议由后端或专用工具链生成、轮换与托管密钥，浏览器端更适合临时性、辅助性工作流。
三、MD5：不是加密，是校验指纹
MD5 是单向哈希，常见用途是做“内容指纹校验”而非安全加密。它的碰撞抗性在安全场景里并不可靠，但在“下载后校验文件是否被破坏”“接口响应是否被意外改写”这种工程校验里仍有用武之地。实践要点：
- 明确使用目的为“校验一致性”，而不是“保密”；
- 输入编码务必统一（UTF-8），否则不同环境 hash 不一致；
- 如果要抗篡改，请使用带密钥的 HMAC（HMAC-SHA256 等）而非 MD5。
四、Base64 与 URL 编码：传输层面的“安全拼接”
前端里两类“编码”很容易混淆：
- Base64：把任意二进制转成可见字符，便于文本通道传输/嵌入，例如把图片转成 Data URI；它不改变语义，只是“可安全传输的载体”。
- URL 编码（application/x-www-form-urlencoded）：把空格、特殊字符转义为
%XY（或空格→+的表单风格）以便放进 URL/表单。误把未编码的 JSON 直接拼到查询串，是线上事故高发点。
落地建议：
- URL 参数统一做编码，前后端默认 UTF-8；
- Base64 不等于加密，敏感数据仍需加密后再编码；
- Base64 Data URI 会涨 33% 体积，适合小资源内联，不宜滥用。
五、常见“坑位”清单与排查思路
- 明文字符集不一致：浏览器默认 UTF-8，后端若按其他编码解析会导致“同文不同 hash/不同密文”。
- IV 写死或复用：表面“能用”，但安全性极差。排查日志里若总是相同密文前缀，基本可以判断 IV 问题。
- ECB 被误用在需要语义隐藏的场景：同样的块密文重复出现，图像/表格等结构一览无余。
- URL 未编码：中文、空格、特殊符号进入查询串后，后端解析失败或参数截断；必须 encodeURIComponent。
- 把 MD5 当“加密”使用：任何可逆加密/不可逆哈希的混淆使用，都会在需求升级（需要解密/需要抗篡改）时付出成倍代价。
六、工程化的“安全默认值”清单
- AES：优先 CTR/CBC；随机 IV；密钥 16/24/32 字节；统一 UTF-8；输入输出指定为 hex/base64/string 并保持一致。
- RSA/ECDSA：2048 位起步或 P-256；标准 PEM；公钥分享、私钥妥善保管；前端用于临时流程，生产用后端托管。
- 校验：优先 HMAC-SHA256；若仅做一致性校验，MD5 可用但需注明目的。
- 编码：URL 统一 encodeURIComponent；二进制走 Base64；小资源可 Data URI，大资源仍走文件。
七、落地示例与工具联动
假设你要把一段表单数据“安全地”放进 URL 里做一次性回传：
- 先 JSON.stringify 表单对象；
- 使用 AES-CTR 加密（随机 IV）；
- 把密文与 IV 以 Base64 进行包装；
- 对最终字符串做 URL 编码，作为查询参数拼接；
- 服务端收到后按相同流程解码、解密，得到原文；
中途任何一步报错，优先检查字符集、IV 长度与格式是否一致。
🔗 相关工具
- AES加密解密 - 支持CBC/CTR/CFB/OFB/ECB、多种填充，hex/string/base64 输入输出
- RSA密钥对生成 - 生成RSA/ECDSA/RSASSA-PSS密钥对，输出PEM/HEX
- MD5计算器 - 文本MD5指纹，HEX与Base64两种表示
- Base64编码解码 - 文本/文件Base64互转，实时预览
- UrlEncode编码解码 - 支持表单风格（空格→+），一键复制