1. 先把三类算法放进各自的抽屉里经常看到有人把登录密码存数据库之前 MD5 一下叫做加密也有人把哈希、对称加密、非对称加密这些密码学算法混在一起觉得反正都是让数据变得看不懂。概念一旦混淆带到工程里就很容易在错误的地方用错算法该保密的用了哈希该认证的只做了加密最后安全评审一问一个准。这篇不是教科书而是我做安全加固和接口联调时沉淀下来的工程视角笔记三类最常见密码学算法分别解决什么问题、内部大概怎么运转、实际选型时哪些坑必须绕开。适合刚接触安全开发的后端工程师也适合天天在调加密接口却很少追问底层原理的开发者。1.1 先想清楚你在防谁防什么很多失败方案的本质是被加密两个字带偏了。我见过不少团队不做威胁分析直接一拍桌子说领导要求加密那就全上 AES。可如果你的真实风险是用户密码泄露后被拿去撞库重点根本不在 AES而在口令哈希算法如果接口消息在链路上会被篡改光上 AES 也只能保证别人看不懂保证不了数据原封不动。通信场景里的威胁大致有四类窃听、篡改、伪装、抵赖。哈希主要解决篡改和完整性校验对称加密主要解决窃听非对称加密主要解决密钥怎么安全地交给对方、以及如何证明身份。算法之间不是竞争关系是分工关系真实工程方案几乎都是组合拳。HMAC 我特意在下面的表里单列了一行它可以理解为给哈希装了一把对称密钥锁解决任何人都能算哈希的问题。很多项目做接口签名时把普通哈希当 HMAC 用拿参数拼一个摘要就发给对方结果攻击者改完参数重新算一遍摘要就行防线形同虚设。这个错误非常典型后面我会专门展开。1.2 三类算法的速览对照把算法先分堆后面讲细节才不会乱。下表按是否需要密钥、速度、典型用途三件事做了个速览类别是否存在密钥代表算法速度典型用途哈希无密钥MD5、SHA-1、SHA-256、SHA-3很快完整性校验、口令存储消息认证码对称密钥HMAC很快消息完整性 来源认证对称加密一把共享密钥DES、3DES、AES快大批量数据机密性非对称加密公私钥对RSA、ECDSA慢密钥交换、数字签名、证书判断一个方案靠不靠谱第一件事就是看它对应表格里的哪一行。如果需求是证明消息没被动过答案应该在哈希或 HMAC 里找如果需求是别人看不懂答案才落到对称加密和非对称加密。拿着加密算法去回答完整性问题是大多数项目翻车的共同起点。2. 哈希算法不可逆的指纹仪2.1 三个让人一眼看懂的性质哈希算法输入任意长度输出固定长度。无论输入是你好还是一整部小说SHA-256 的输出都是 64 个十六进制字符。这个固定长度的输出不是压缩更不是加密它有三个核心性质确定、单向、雪崩。确定性指同样输入永远得到同样输出这是后续一切校验比对的地基单向指从输出反推输入在计算上不可行雪崩指改动输入里哪怕一个比特输出大概有一半比特会发生变化。三个性质凑在一起哈希就变成了数据的指纹。单向需要一句话展开。哈希确实丢弃了大量输入信息但真正让它不可逆的不是信息丢弃而是反推只能靠逐个猜测输入、重算哈希然后比对计算量超出可行范围。所以哈希适合做完整性校验、口令存储、去重但不适合做保密只要你的目的是把数据藏起来以后再解出来哈希就选错了。2.2 MD5 和 SHA-1 为什么被请下台MD5 输出 128 位SHA-1 输出 160 位两者在上世纪都是明星算法但今天在安全场景里看到它们请直接打上问号。MD5 的碰撞攻击早就公开构造两个内容不同但哈希完全一样的文件在计算上是可行的用大白话说攻击者可以造出一个看起来正常却和恶意文件哈希相同的文件骗过校验环节。SHA-1 的碰撞也在多年前被实际演示过任何还在依赖这两个算法的安全方案都该列入整改清单。不过把话说回来MD5 和 SHA-1 并非一无是处。文件下载的完整性校验要防的是传输误码而不是蓄意攻击MD5 便宜、快、占用小用起来很顺手。判断标准只有一条场景里有没有一个刻意和你作对的攻击者。存在就上 SHA-256 或更高强度的算法不存在拿 MD5 当普通校验码完全没问题。很多人在这一点上走极端要么完全不理解碰撞攻击的危害要么一听到 MD5 就过敏其实关键在于对抗模型。2.3 口令存储问题从来不是选哪个哈希口令存储是整个安全开发里最容易翻车、也最该被重视的模块。有人把用户密码 SHA-256 之后直接存库自以为已经加密了但 SHA-256 太快了现代显卡一秒钟能算数十亿次普通人类可选的弱密码在暴力枚举面前几乎没有抵抗力。再叠加没加盐的问题同一个密码在不同用户那里哈希值完全一样撞库和彩虹表攻击都会变得格外顺畅。正确思路分两步加盐以及换用慢速的专用口令哈希算法。盐是每个用户唯一的一段随机数不要低于 16 字节和密码一起参与计算让预计算好的彩虹表彻底失效专用算法方面优先考虑 Argon2、bcrypt 这类带工作因子、能主动调高计算成本的方案PBKDF2 配高迭代次数也可以。安全审计时密码只做了一次 SHA-256 后入库属于可以直接判不合格的实现不要心存侥幸。2.4 HMAC给哈希装一把只有双方能用的锁普通哈希有个尴尬之处任何人都能算。如果我只是防篡改给业务数据算一个 SHA-256 摘要放在旁边攻击者改完数据后重新算一份摘要替换掉就行防御等于零。HMAC 解决的就是这个问题它把一把对称密钥混进哈希计算过程没有密钥就算不出合法认证值通信双方各自持有同一把密钥第三方既改不了数据也伪造不了认证值。HMAC 的实现思路不复杂把密钥做特定填充后和消息组合起来执行两次哈希运算得到固定长度的认证标签。工程上它被广泛用在接口签名、Webhook 回调校验、token 防篡改等场景。普通哈希和 HMAC 的区别用一句话就能说清哈希证明数据没坏HMAC 证明数据没坏而且改它的人没有密钥。做接口对接时对方要求你对参数算一个签名十有八九要用的就是 HMAC而不是把参数拼起来做一次普通哈希。3. 对称加密同一把钥匙的省心与操心3.1 从 DES 到 AES密钥长度决定生死对称加密的特点是加密和解密用同一把密钥目标是在密钥不泄露的前提下让拦截者拿到密文也恢复不出原文。老一代 DES 的密钥只有 56 位暴力枚举在专用硬件的加持下只需要几小时到几天今天已经形同虚设。它的升级版 3DES 把 DES 连续做三遍以提升有效强度但因为分组大小仍停留在 64 位性能又差走到了淘汰边缘。现在只要没有特殊兼容约束新系统没有理由再迁就这两个老家伙。AES 是当前公认的主流选择分组长度固定 128 位密钥支持 128、192、256 位。密钥长度每增加一位暴力破解空间就翻一倍AES-256 的搜索空间在可预见的未来内基本不可能被硬件跑穿。我现在的习惯是直接写 AES-256-GCM 这一档既拿到足够长的密钥又拿到后面要讲的认证能力。不过这里想强调一句密钥长度从来不是安全的全部算法怎么被使用才是真正的灾难高发区。3.2 AES 只是块密码真正决定安全的是模式和随机数AES 本身一次只能加密一个 16 字节的块数据一长就得定义块与块之间怎么串联这就是分组模式。每个模式的安全性质差异巨大模式选错再强的算法也白搭。ECB 模式是最典型的反面教材它让每个块独立加密同一个明文块永远输出同一个密文块加密一张图片后轮廓照样能看出来这是教学上最直观的泄密演示生产环境绝对不要碰。CBC 模式把前一个密文块混合进当前块再加密并且需要一个随机 IV 来启动链条解决了模式重复问题。但它的加密链路是串行的速度受限还要处理填充历史上围绕填充出现过不少攻击。GCM 是当前的推荐项它属于 AEAD 认证加密模式输出里同时包含密文和认证标签机密性与完整性一次拿到省掉了再单独跑一遍 HMAC的麻烦。IV 或 nonce 的生成规则同样致命GCM 用 96 位随机 nonce但同一把密钥底下绝对不能重复一旦重复攻击者可以借助两次加密的内部关系把机密性拆穿。3.3 填充问题为什么长度不是 16 的倍数会报错CBC 这类分组模式要求明文长度是 16 字节的整数倍不够就要填充最常见的方案是 PKCS#7缺几个字节就补几个值等于几的字节。联调时经常遇到的数据长度不对解密结果乱码一半以上是两边的填充方式不一致一个按 PKCS#7 补了另一个按零填充或者压根没补。GCM 这类 AEAD 模式不需要传统填充数据按流式处理输出是密文、认证标签、nonce 三个值。这里有个接收顺序需要注意拿到数据后要先验证认证标签确认数据没被篡改再去解密。顺序反过来接收方等于先处理了不可信数据破坏了认证加密的意义。很多人对接 AES-GCM 接口时只关注解密忽略了标签校验结果接口能用安全性已经悄悄漏水。4. 非对称加密公钥公开、私钥保密、速度却慢得离谱4.1 RSA 的基本形态为什么 2048 位才及格RSA 是知名度最高的非对称算法核心数学难题可以一句话概括找到两个大质数相乘很容易但拿到乘积后反推是哪两个质数非常难。公钥可以公开给全世界用于加密或验签私钥必须自己锁好用于解密或签名。这个非对称性直接解决了对称加密最头疼的问题——密钥怎么安全地送到对方手里。但使用门槛同样高RSA 对密钥长度非常挑剔1024 位早被验证不可靠现在安全基线是 2048 位起步重要系统直接上 3072 位。另一个问题是 RSA 的运算比对称加密慢几个数量级能加密的明文长度还受密钥长度限制填完随机填充后真正能装的业务数据很有限。所以拿 RSA 直接加密大段 JSON 本身就是一种错误用法。此外教科书版本的 RSA 直接做幂运算失去了随机性攻击者通过选择密文的手段就可以拆解信息实际使用必须套 OAEP 这类带随机填充的加密方案签名场景也要用 PSS 填充不能图省事。4.2 椭圆曲线用更短的钥匙打同样的工椭圆曲线加密是另一族非对称算法常见形态包括签名的 ECDSA 和密钥交换的 ECDH。它的核心卖点在同等安全强度下密钥短得多256 位椭圆曲线密钥的安全性大致相当于 3072 位 RSA。密钥短握手包更小运算更快移动端和低功耗设备的优势非常明显。但也正因为数学结构和实现细节复杂它对随机源和曲线参数的敏感度更高参数不规范、随机数生成有瑕疵都可能把私钥直接暴露出去。业内已经发生过因为随机数重用攻击者反推出签名私钥的真实事故所以用椭圆曲线算法时要特别注意三点曲线参数采用公开标准不要自选随机数必须来自可信随机源密钥生命周期要纳入正规管理。工程上如果条件允许我倾向优先使用 ECDSA 或 ECDH配合 P-256 这类成熟曲线移动端性能和安全性都能兼顾。4.3 非对称算法在真实系统里只干三件事把非对称算法放到真实系统里看它的职责其实非常收敛主要是三件事第一是密钥交换通信双方通过公钥机制安全地商量出一把临时对称密钥后续大数据量加密交给 AES第二是数字签名用私钥签名、公钥验签解决身份认证和防抵赖第三是证书把公钥和某个身份绑定到一起再由可信任的签发方给这个绑定关系做签名。看到这里你应该明白了任何用 RSA 加密整个请求体的设计大概率都可以用非对称加密一把随机密钥 对称加密业务数据的混合方案替代这也是 HTTPS 能跑得动海量流量的根本原因。5. 三把工具的组合拳HTTPS、数字签名与证书链5.1 一次 HTTPS 会话里发生了什么HTTPS 是混合加密最标准的样本。握手阶段服务器先出示证书证书里包含服务器公钥和签发者对该公钥与身份的签名客户端验证签名可信后取出服务器公钥参与协商出临时会话密钥后续真正的业务数据改用 AES 这类对称加密处理。这个分工值得每一位做接口设计的人反复品味非对称算法只处理密钥协商和身份认证两件少量但昂贵的事对称算法负责大量但快速的数据加密。这个思路可以直接迁移到自研系统。假设两个系统之间要传一批数据正确做法是先随机生成一把 AES 密钥再用对方的 RSA 公钥把这把 AES 密钥加密后发过去之后用 AES 加密真正的数据。这样既绕开了 RSA 加密长度受限的短板又避免了对称密钥在链路上裸奔的问题。我见过太多项目在这里贪图省事直接 RSA 加密整个请求体最终要么性能崩要么密文超长被网关拒绝。5.2 数字签名为什么先哈希再签名签名如果直接作用在整份文件上文件一大运算开销和可操作性都很差。标准做法是先对消息计算哈希得到固定长度的摘要再对摘要做签名验证方同样先计算哈希再用公钥验证签名。哈希在这里相当于把消息降维成一个固定尺寸的指纹签名实际锁定的就是这个指纹。这样做还有一个额外好处由于摘要长度固定且雪崩敏感攻击者几乎不可能构造出另一份内容不同但哈希相同的数据去复用同一个签名。这套哈希 非对称签名的组合遍布日常系统软件包完整性签名、应用安装包签名、HTTPS 证书、代码提交签名底层都是同一个套路。做一个新系统时如果只想用非对称算法做身份认证而不传递数据那你需要的不是加密是签名把这两个概念分开接口设计会清爽很多。5.3 证书链原来公钥不是发出去就有人信公钥本来就是公开数据真正的难点在于怎么让接收方相信这个公钥确实是声称拥有它的那台服务器的证书链就是回答。服务器出示的公钥证书由可信任的根证书逐级签发每一级用自己的私钥给下一级的公钥与身份信息做签名客户端只要信任根证书就能顺着签名链把信任传导到服务器公钥上。这也解释了为什么根证书过期、中间证书没配全时浏览器会直接拦截并提示不安全。很多人为了省事想用自签名证书结果一上线客户端直接报错这是因为自签名证书缺少上游信任锚点。证书不是额外的官僚手续它是非对称签名解决身份可信问题的必要组件。在内部系统里自建证书体系完全可以但要有意识地维护好根证书和签发流程把它当成密钥管理的一部分来做而不是随手生成一个就完事。6. 踩坑总结与我现在会用的算法组合6.1 高频雷区先说我见过最多的几类问题。第一是自创算法把 AES、RSA 拼一个密钥切成三份轮流加密的自创方案在安全评审里几乎必挂。密码学安全的难点从来不在把算法拼起来而在模式和协议细节任何一个 padding、nonce、时序的处理有偏差都会让整个方案崩掉成熟库的默认参数经受过多年攻防检验比自己设计的组合可靠得多。第二是随机数质量。IV、nonce、salt、密钥生成都必须来自足够强的随机源用普通随机数生成器来造 IV等于把加密链路的关键螺丝拧在一个可以预判的位置上。与随机数伴生的是重复使用问题GCM 的 nonce 重复、RSA 随机填充重复、盐重复每一个都是独立的灾难。第三是只加密不认证攻击者读不出内容却可以翻转密文比特让解密结果按他想要的方向变化AEAD 模式把机密性和完整性一起解决选模式时请优先认准这一类。第四是硬编码密钥密钥写进代码仓库配合代码泄露加密就退化成了混淆密钥应该有独立的生成、分发和轮换流程。6.2 当下我会选择的算法组合下面的表是我目前做设计时的默认选择普通业务没有特殊合规要求时直接照着抄基本不会出大错使用场景推荐组合备注文件/数据完整性校验SHA-256 或 SHA-3无对抗对手时可用 MD5消息来源认证与防篡改HMAC-SHA256密钥独立管理用户口令存储Argon2 / bcrypt / PBKDF2加盐、工作因子调高传输数据保密AES-256-GCMAEAD认证标签先验证数字签名ECDSAP-256或 RSA-PSS2048 位起移动端优先 ECC密钥协商标准密钥交换协议 签名认证不要裸用传统模式表里的每一项都对应标准算法 安全参数 正确模式三个维度只记算法名字不记参数和模式和没写是一样的。还有一点要单独强调TLS 已经在传输层把加密、认证、密钥协商全做完了业务层不要再自己造加密轮子如果只是做接口消息签名优先用标准化的 token 方案不要在 JSON 里手工拼一个密文再加一个签名那样只会增加审计者的工作量。6.3 拿到一个新加密接口时我必看的三处第一处是算法全名。文档里只写 AES 是不够的要确认到 AES-256-GCM 这个粒度对称加密的模式差异比算法差异更容易出问题。第二处是密钥和随机参数密钥多少位、IV 从哪里来、是否每次随机、重复会怎样文档里都要交代清楚。第三处是认证方案有没有输出认证标签验证顺序是不是先认证后解密。三处都清晰我才敢把这个接口接到生产链路里。最后分享一个我一直在用的自检习惯完成加密方案后拿一段已知明文和密钥做对照测试比对输出是否与公开测试向量完全一致。这个动作能快速定位填充、模式、字节序三类低级错误。另一件常做的事是每隔一段时间回看代码里的算法调用把带 MD5、SHA-1、ECB、硬编码密钥的地方逐个清掉。安全不是一次评审就结束的事它更像持续巡检换代和清理的速度决定了系统暴露面的下限。
