1. 项目概述这套算法体系到底在解决什么问题接手过几个带用户体系和数据交换的项目之后我最大的感受是密码学算法不是数学课上的抽象概念而是每个开发者迟早要面对的工程选型。APP登录、Web后台、小程序、服务间接口通信绕不开“身份认证”“数据传输加密”“完整性校验”“密码存储”这四件事。处理这些事用的就是对称加密、非对称加密、哈希函数、消息认证码这几类最常见的基础算法。这篇文章不堆数学公式直接讲清楚每个算法能干什么、不能干什么、怎么选、怎么落地适合刚接触信息安全的后端和客户端开发也适合所有被“到底该选哪个加密算法”困扰的人。1.1 加密算法不是黑魔法是工程选型问题很多人一提RSA、AES就发怵其实我们不需要把椭圆曲线方程式背下来关键是搞清楚每个算法服务于什么安全目标。我做个粗浅类比对称加密像一把钥匙开一把锁加解密速度快但钥匙怎么安全送到对方手里是个问题非对称加密像带公共投信口的邮箱公钥是公开的投信口私钥是只有你有的取信钥匙解决了钥匙分发难题但运算速度慢哈希函数像给数据取指纹任何人都能对同样内容算出同样的指纹但无法从指纹反推内容所以非常适合做完整性校验和密码存储。选算法的本质是选安全目标和性能权衡。要机密性选对称加密要解决密钥分发选非对称加密要校验数据有没有被改过选哈希要确认消息确实来自某个持有密钥的对方选MAC。实际项目从来不是单用一个算法而是把它们组合成一个方案。比如HTTPS握手过程先通过非对称或DH类算法协商出临时对称密钥再用AES加密真正的业务数据同时用SHA系列做哈希校验整个流程就是一个标准的算法组合样板。1.2 四类算法的整体框架先给一个全局视角后面每一类单独展开。四类算法的核心区别在于“是否使用同一个密钥”和“是否可逆”。算法类别代表算法核心用途主要特点对称加密AES、SM4数据机密性速度快密钥管理难非对称加密RSA、ECC密钥分发、数字签名速度慢安全性高哈希函数SHA-256、SM3完整性校验单向不可逆消息认证码HMAC身份认证、防篡改哈希函数 共享密钥这个表格建议直接存下来做技术方案评审时特别好用。很多人一开始搞混“加密”和“哈希”以为哈希也是一种加密其实完全两码事加密可以解密还原哈希的天然设计就是不可还原。理解了这张表后面的细节就只是往框架里填肉。2. 对称加密速度快但模式和密钥管理是两道坎对称加密是所有加密算法里效率最高的适合加密大数据量。它的核心难点不在算法本身而在“模式怎么选”和“密钥怎么管”。下面从AES展开再说说合规场景常见的SM4。2.1 AES 的基本规格和适用场景AES是当前最主流的对称加密标准分组长度固定128位密钥长度支持128、192、256位。密钥越长越抗暴力破解但性能开销也越大。普通业务场景用AES-128足够安全性要求高的系统直接上AES-256也常见。我自己的习惯是没有特殊合规要求就用AES-128-GCM既有足够安全强度性能也不会拖后腿。AES的分组加密特性决定了它需要“工作模式”来处理超过16字节的数据。这就像你用一块固定大小的模具去压饼干一次压一块多出来的要换个方式继续压。模式选错再强的算法也会被攻破所以模式选择比算法本身更需要上心。2.2 ECB、CBC、GCM 三种模式对比ECB模式是最原始的做法每个明文块独立加密相同的明文块永远产生相同的密文块。听起来没问题但实际后果很严重——我见过加密后的图片数据在ECB模式下还能隐约看出原始图案轮廓因为像素颜色相同的区域密文也相同。这个模式没有任何语义安全性新项目绝对不要用。CBC模式做了改进每个明文块先与上一个密文块做异或再加密这样相同的明文块在不同位置会产生不同密文。但它有两个要求第一个块需要IV初始化向量IV必须随机且每次加密都不能重复另外需要PKCS7之类的填充方案因为明文长度不一定刚好是分组的整数倍。CBC只保证机密性不保证完整性如果直接用CBC加密网络数据攻击者可能通过翻转密文位来篡改明文这是经典的比特翻转攻击。GCM模式是目前最推荐的。它是认证加密模式一次加密操作同时输出密文和认证标签Auth Tag解密时会校验标签数据被篡改会直接报错。安全性、性能、易用性都优于CBC很多现代协议和库的默认推荐就是它。我在自己项目里一律AES-GCM省心也安全。注意GCM模式对nonce随机数要求极高同一个密钥下nonce绝对不能重复。重复一次攻击者就能恢复出加密密钥。所以实际项目中nonce要么用安全的随机数生成器要么用计数器严格递增绝不能拍脑袋写个时间戳或固定值。2.3 国密 SM4 在合规场景中的应用国内政务、金融行业有合规要求时经常会遇到SM4。SM4分组长度固定128位密钥长度128位设计思路和AES类似。从工程实现上看SM4的加解密API、模式选择、填充方式都和AES保持一致只是算法替换。所以如果你已经把AES的代码写好了切SM4的成本并不高。不过提醒一句SM4本身只是算法合规的关键是整个密码体系都走国密包括SM2、SM3、SM4组合使用以及算法实现是否经过检测认证。个人开发者大部分场景用AES就够了涉及政务类项目再按对方具体要求来。别一听“国密”就觉得高大上它本质就是一组标准和规范实现起来没那么玄。3. 非对称加密慢但解决了密钥分发难题对称加密最大的痛点是把密钥安全地发给对方。非对称加密用一对钥匙解决这个问题公钥公开私钥私有。别人用你的公钥加密数据只有你的私钥能解开你用私钥签名别人用公钥验证。3.1 RSA 的参数选择与局限性RSA的安全性基于大整数分解的困难程度。密钥长度低于1024位已经确认不安全2048位是目前最低标准对安全性敏感的系统建议上4096位。我见过不少老项目还在用1024位RSA只能说赶紧迁移否则一旦密钥被分解所有加密数据都等于裸奔。RSA有两个经常被忽略的工程限制。第一加密长度受密钥长度限制2048位密钥配合OAEP填充一次最多只能加密约190字节明文所以不能用它直接加密大文件或大报文第二解密运算非常慢大量数据逐一用RSA加密会当场卡死。正确用法是“混合加密”随机生成一个AES密钥用RSA加密这个短密钥真实数据用AES处理。这样既解决密钥分发又保留了对称加密的速度。填充方案同样有讲究。RSA加密应用OAEP填充不要用PKCS1v15签名应用PSS填充不要用裸的私钥运算。这些细节在安全审查里都会被揪出来标准库默认参数往往就是安全推荐值不要轻易改动。3.2 ECC 与 Ed25519 在现代签名中的地位ECC椭圆曲线加密在相同安全强度下密钥长度远小于RSA。256位ECC约等于3072位RSA的安全强度而且运算效率更高。过去几年ECC在证书、签名、密钥交换中被广泛采用主流库对它的支持也非常成熟。签名领域我最推荐的是Ed25519属于EdDSA算法族。它的优势很实际密钥和签名都很短验证速度快实现上天然抵抗一系列侧信道攻击而且生成签名过程中几乎不会踩到老式ECDSA那些“随机数重复导致私钥泄露”的坑。我自己做API签名、软件更新包签名首选就是Ed25519代码少、出错概率低。我遇到不少同学问“RSA是不是要被淘汰了”其实不是淘汰而是场景分化老系统兼容、加密少量数据、证书体系里RSA仍然大量存在新系统做签名、做密钥交换时ECC和Ed25519的优势更明显。两者不是对立关系而是看具体场景选型。3.3 混合加密是实际项目的主流形态混合加密不是某种算法而是一种组合策略随机生成对称密钥用非对称算法加密这个对称密钥再用对称算法加密业务数据。你打开任何一个现代加密通信协议内部基本都是这个套路。HTTPS的TLS握手就是典型客户端和服务端通过椭圆曲线或RSA协商出会话密钥后续大量数据全部走AES。为什么头疼因为真实业务数据可能几十兆、几百兆非对称加密搞不定而对称密钥本身只有16到32字节用非对称加密毫无压力。所以“非对称管密钥分发对称管数据加密”这句话值得每个开发者牢牢记住。做项目时如果有人问“怎么用RSA加密用户上传的文件”答案不是硬上RSA而是先把这个混合思路讲明白。4. 哈希与MAC保护完整性守住密码底线哈希算法是四类算法里最容易被低估的。很多系统出安全问题不是在加解密环节而是在密码存储和完整性校验上用错了哈希。这一部分必须认真对待。4.1 哈希函数的特性与常见算法状态哈希函数有三个关键特性确定性同一输入永远同一输出、单向性从哈希值无法反推原文、雪崩效应输入改一个字节输出面目全非。这三个特性让它天然适合做“是否被篡改”的校验比对两个哈希值是否一致就能知道数据有没有被动过。常见的哈希算法现状算法输出长度安全状态使用建议MD5128位已破解禁用SHA-1160位已存在碰撞攻击禁用SHA-256256位安全推荐SHA-512512位安全推荐SM3256位安全合规场景推荐MD5和SHA-1在新项目里一律不要用。有人会说“MD5做文件校验、做缓存键应该没事吧”做非安全用途可以但你自己要明确这个边界只要带一点防篡改、抗碰撞需求就必须上SHA-256以上。我见过某项目用MD5算文件的完整性校验值攻击者完全可以构造出相同MD5值的恶意文件校验形同虚设。4.2 密码存储的正确姿势这是全网程序员的经典重灾区。很多系统把用户密码直接做一次MD5或SHA-256就存库一旦数据库泄露攻击者用彩虹表或字典可以批量还原出密码。正确做法是“加盐 慢哈希”让每次密码哈希都带上随机盐值并且让计算过程故意变慢提高暴力破解成本。目前推荐顺序是Argon2优先其次bcrypt或scrypt。如果标准库条件受限Python的hashlib也提供PBKDF2虽然不是最优但比裸哈希强太多。核心原则有三个每个用户的盐必须随机且不同盐和哈希值一起存库验证时重新计算再比较永远不要自己写字符串比较来判断哈希相等要用库提供的恒时比较函数避免时序攻击。4.3 HMAC给消息盖一个有密钥的“印章”HMAC是“带密钥的哈希”在SHA-256等哈希函数基础上引入共享密钥。除了能验证数据完整性还能确认消息确实来自持有密钥的对方。打个比方普通哈希是贴一张任何人都能伪造的封条HMAC是贴一张只有你和对方才有印章的封条。HMAC在项目里最常见的三个场景Webhook回调验签、服务间API签名、JWT签名。每次回调数据过来服务端用共享密钥重新计算HMAC再比对匹配就说明数据没被改且来源可信。这里有个实操细节比较HMAC结果必须用恒时比较函数如hmac.compare_digest用普通的“”比较会引入时序侧信道可能被攻击者逐位猜出正确值。5. 实操把前面讲的算法落到代码里理论讲完了上点能直接跑的东西。我用Python环境演示AES-GCM、RSA混合加密、密码哈希这几个最常用的场景所有代码都可以直接抄去改。5.1 环境准备与库选型Python生态里涉及密码学有三套常用方案hashlib是标准库只有哈希和HMACcryptography库功能最全AES、RSA、ECC、签名、KDF都覆盖pycryptodome也常用但API风格偏老。我推荐cryptography安装一行命令接口现代默认参数也是安全推荐值。pip install cryptography如果只是算哈希用内置hashlib就行不需要额外依赖。后面示例里涉及加解密的一律用cryptography涉及哈希的一律用hashlib。5.2 AES-GCM 加解密示例这是日常最核心的一段代码。用cryptography的AESGCM接口一次调用同时完成加密和认证。import os from cryptography.hazmat.primitives.ciphers.aead import AESGCM # 生成128位密钥生产环境放在环境变量或密钥管理服务不要写死在代码里 key AESGCM.generate_key(bit_length128) aesgcm AESGCM(key) # nonce必须随机且每次唯一长度12字节是推荐值 nonce os.urandom(12) message b这是一段机密业务数据 aad bchannel:order # 可选关联数据会参与认证但不加密 ciphertext aesgcm.encrypt(nonce, message, aad) print(密文:, ciphertext.hex()) # 解密时如果数据被篡改会直接抛异常 plaintext aesgcm.decrypt(nonce, ciphertext, aad) print(解密:, plaintext.decode(utf-8))这段代码有几个点需要解释清楚。nonce是12字节的随机数每次加密都必须换新的AAD关联数据不会加密但会参与认证标签计算适合放消息头、路由信息这类需要被看到又不许被改的内容。加密结果里最好把nonce和密文拼在一起存储或传输否则解密时找不到nonce。5.3 RSA 加密与签名示例RSA一般用来加密AES密钥或小数据。下面演示加密一段短消息以及生成签名。from cryptography.hazmat.primitives.asymmetric import rsa, padding from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives.serialization import Encoding, PublicFormat, PrivateFormat # 生成2048位RSA密钥对 private_key rsa.generate_private_key(public_exponent65537, key_size2048) public_key private_key.public_key() # RSA加密OAEP填充 aes_key os.urandom(16) # 要传输的对称密钥 ciphertext public_key.encrypt( aes_key, padding.OAEP( mgfpadding.MGF1(algorithmhashes.SHA256()), algorithmhashes.SHA256(), labelNone ) ) plaintext private_key.decrypt(ciphertext, padding.OAEP( mgfpadding.MGF1(algorithmhashes.SHA256()), algorithmhashes.SHA256(), labelNone )) print(还原AES密钥:, plaintext.hex() aes_key.hex()) # 签名PSS填充 signature private_key.sign( b待签名的数据, padding.PSS(mgfpadding.MGF1(hashes.SHA256()), salt_lengthpadding.PSS.MAX_LENGTH), hashes.SHA256() ) public_key.verify( signature, b待签名的数据, padding.PSS(mgfpadding.MGF1(hashes.SHA256()), salt_lengthpadding.PSS.MAX_LENGTH), hashes.SHA256() ) print(验签通过)公钥指数65537是标准推荐值没有特殊理由不要改。注意RSA加密最多只能加密密钥长度除以8再减去填充长度2048位OAEP大约190字节所以务必只用于短数据。签名和加密用的填充不能混加密用OAEP签名用PSS。5.4 密码哈希与校验示例密码存储用慢哈希。标准库能直接跑的是PBKDF2生产环境建议进一步换Argon2或bcrypt库。import hashlib import secrets password 用户输入的明文密码.encode(utf-8) # 每个用户一个随机盐16字节起步 salt secrets.token_bytes(16) # PBKDF2-HMAC-SHA256迭代10万次次数根据硬件性能调整 digest hashlib.pbkdf2_hmac(sha256, password, salt, 100_000) stored salt digest # 盐和哈希一起存库 # 验证时重新计算再恒时比较 salt stored[:16] re_digest hashlib.pbkdf2_hmac(sha256, password, salt, 100_000) print(密码校验通过 if secrets.compare_digest(re_digest, stored[16:]) else 密码错误)PBKDF2的迭代次数不是随便设的。基准目标是让一次验证大约耗时100毫秒左右这样用户感知不明显但攻击者离线爆破海量口令的成本暴涨。secrets模块是Python安全随机数的正确打开方式random模块的伪随机不能用于生成盐值和密钥。6. 常见问题与排查技巧实录代码跑通只是第一步实战里真正耗时间的往往是那些“看着没问题但就是不对”的毛病。这部分整理我的排查记录。6.1 高频问题速查表症状可能原因解决方案解密报错或乱码字符串和bytes混用、编码不一致统一编码传输用base64用ECB模式加密图片后能看出轮廓模式本身不安全换成GCM或CBCRSA加密大文件直接报错明文超出填充上限改用混合加密RSA只加密AES密钥GCM解密偶尔报错nonce重复使用或AAD不一致nonce每次随机AAD参数保持一致密码库被脱库后大量账号被破解裸哈希存储、无盐、弱口令慢哈希随机盐强制复杂度两段代码算出来的哈希不一致明文编码方式不同加密前统一encode(utf-8)第二行问题是我在真实项目里遇到过的当时同事拿AES-ECB加密一批PDF文档结果密文文件还能看出原文档的版面结构就是因为ECB模式下相同排版区域产生相同密文块。这事情不发生在文字数据上不明显一旦换成图像、结构化数据就原形毕露。6.2 我踩过的坑和排查思路第一个坑是IV和nonce的复用。早期我图省事在一个服务实例里把nonce设为固定值结果线上同时有上千个客户端通信全部用同一个nonce这等于把AES-GCM的防线直接拆掉。后来排查才发现nonce复用后同一个密钥加密不同明文攻击者可以做位异或操作还原明文关系。正确做法是每加密一次生成一次随机nonce或者维护一个持久化计数器严格递增。第二个坑是密钥硬编码。曾经某个项目把AES密钥写在代码常量里代码库权限稍微放开就全泄露了而且到了要轮换密钥的时候才发现所有历史数据都是用旧密钥加密的迁移工程量巨大。现在我的习惯是代码里只留密钥引用真实值放环境变量或专用的密钥管理服务并且建立定期轮换机制。密钥轮换时要考虑老数据解密所以设计数据格式时必须带上密钥版本号。第三个坑与算法版本有关。有段时间项目同时混用了pycryptodome和cryptography两个库两边的AES默认参数不同导致加解密互相不认。排查很久才发现是库之间填充逻辑不一致。所以我现在的原则是一个项目统一一个密码学库不要在业务代码里混用多家实现。7. 选型建议与一点个人心得最后说点我在实际操作中的体会。密码学算法的选择往往不是“哪个更强”的问题而是“哪个更合适”。你做一个内部管理系统AES-128-GCM搭配RSA-2048做密钥分发已经足够你做一个面向大量用户的支付或社交应用就要认真考虑Ed25519签名、Argon2密码哈希、完整的密钥轮换机制。这个选型表可以帮你快速起步数据传输加密AES-256-GCM密钥协商用ECDH或TLS接口签名与验签Ed25519老系统兼容时用RSA-PSS密码存储Argon2或bcrypt盐随机且独立消息防篡改HMAC-SHA256比较用恒时函数合规要求政务/金融SM4 SM2 SM3组合再分享一个小技巧把算法选型整理成团队文档里的“密码学决策表”每个场景写清楚使用什么算法、什么参数、最小密钥长度、禁止选项。新人接手后直接照着表做比翻遍代码猜方案高效得多。我自己的项目里一直维护着这样一张表每次评审代码就拿出来对着检查踩坑概率直线下降。别自己发明算法也别觉得自己写的加解密比标准库更强。密码学最大的坑从来不是算法太难而是以为自己会了。老老实实用成熟标准、成熟库、成熟参数把精力放到密钥管理和方案组合上你的系统就已经超过绝大多数同类项目了。