上周评审一个加密传输方案负责接口对接的同学当场问我老哥咱们到底用对称加密还是非对称加密你先给我个准话。这个问题几乎每次做安全设计都会被问一次但说实话它本身没有标准答案——因为任何一套正经的加密方案里对称加密和非对称加密从来不是二选一而是搭伙干活。这篇就把它们的原理、各自的强项与软肋以及SM1、SM2、SM3这类国产算法在实际工程里怎么串联一次讲清楚。想给接口加签名、做防篡改或者单纯想搞懂HTTPS那套底层机制的读者都值得花十分钟看完。先把结论放在这儿对称加密负责快非对称加密负责安全地分配密钥哈希算法负责完整性证明。三者配合才是现代密码体系的核心姿势。下面从头拆。1. 工程里最常见的困惑对称和非对称到底怎么选1.1 一个每天都在发生的选型对话我做技术这几年被问到最多的问题不是加密原理是什么而是我该用哪个。很多刚接触安全领域的开发同学上来就搜AES、RSA、SM2、SM3看完更乱了RSA能加密也能签名AES也能加密SM2也能加密到底选哪个先给一个最简单的判断框架看数据量。几KB以内的敏感字段比如手机号、身份证、银行卡号用非对称加密也可以硬扛。几MB甚至几GB的文件、消息流、数据库整表加密必须用对称加密。原因是非对称加密的运算开销比对称加密高了大概两到三个数量级加密大文件时会卡到你怀疑人生。1.2 从密钥数量看本质单钥体系与双钥体系的成本差异对称加密英文叫Symmetric Cryptography核心特征是加密和解密用同一把密钥。你拿钥匙锁门也得用同一把钥匙开门。所以问题来了通信双方怎么安全地拿到这把共同的钥匙如果A和B各在网络两端不能见面那把密钥通过网络传输时被人截获怎么办非对称加密解决的就是这个密钥配送难题。它生成一对钥匙公钥公开私钥保密。用公钥加密的数据只有私钥能解用私钥签名的数据只有公钥能验。注意这里面有个极其容易混淆的点公钥能加密但公钥不能解密私钥能签名但私钥不能用来做常规的加密传输给其他人解。签名和加密是两套方向相反的操作后面我会细说。记住一句话对称加密便宜量大管饱非对称加密贵但能解决信任和分发问题。你需要的从来不是二选一而是组合。2. 两类加密的运作机制从一把钥匙和一对钥匙讲起2.1 对称加密的底层逻辑替换和置换的反复叠加对称加密看起来简单一个密钥加密一个密钥解密但它内部做的事情一点都不简单。以分组密码为例AES、SM1、SM4都属于这一类。它们做的本质上是两件事替换Substitution和置换Permutation。替换就是把输入字节按照S盒映射成另一个字节置换就是把字节的位置打乱。一次替换加一次置换叫一轮现代对称算法会把这套操作重复十几轮。每一轮都用不同的轮密钥而轮密钥又是由主密钥通过密钥扩展算法生成的。这么搞的目的只有一个让密文和明文之间建立起极度复杂的依赖关系哪怕明文只改了一个bit密文也会面目全非。这种性质叫雪崩效应。在模式上工程中常用的是CBC和GCM或国密的GCM变体。CBC把每个分组跟上一个分组的密文做异或再加密解决同样的明文块会得到同样的密文块这个统计暴露问题。GCM则在加密的同时算出认证标签相当于加密和完整性校验合并成一步性能更好更推荐。2.2 非对称加密的底层逻辑陷门函数非对称加密的原理可以概括为一个方向上极其容易反方向上极其困难但拥有额外信息时反方向又变得容易。这个数学结构叫陷门函数。RSA的陷门基于大整数分解两个大素数乘起来很容易但把乘积分解回两个素数几乎不可能。SM2和ECC类算法则基于椭圆曲线离散对数问题知道基点G和私钥d算出公钥Q dG很容易反过来知道Q和G还原d在曲线上几乎没法做。这就是公钥能公开的原因暴露公钥不意味着暴露私钥因为逆向计算在数学上不可行。不可行是有条件的取决于密钥长度。RSA-2048的安全强度大约相当于SM2的256位椭圆曲线。SM2最大的优点是密钥短、签名短、运算快这也是它成为国密主流非对称算法的重要原因。2.3 哈希算法为什么聊加密总绕不开它严格来说SM3、SHA-256这类哈希算法不是加密因为它是单向的算完没法还原。但它跟加密配合得非常紧先哈希原文得到摘要再对摘要做签名签名消息很短速度自然快接收方重新算哈希比对摘要验证签名顺带还能证明原文没被篡改。打个比方加密是给信件上锁哈希是给信件贴封条。封条不是锁但它能证明信封有没有被拆开过。HTTPS、数字证书、SM2签名、区块链几乎所有安全协议里都有哈希这一层。3. 国密三件套SM1、SM2、SM3定位、差异和工程含义熟悉热搜词的朋友应该注意到了最近对称加密实验和SM1、SM2、SM3这几个词关联很紧。为什么因为国内很多金融、政企、关基行业的系统做安全改造时要求优先采用国家密码管理部门认可的算法简称国密算法。整套体系里最常被提到的就是SM1、SM2、SM3。3.1 SM1对称加密硬件专属和参数不公开的真相SM1是一种分组对称加密算法分组长度128位密钥长度128位。很多人第一次看资料会问SM1算法是啥网上怎么找不到代码这恰恰是它最大的特点算法细节不公开只能通过密码芯片、密码机、加密卡等硬件模块调用普通软件项目里没法直接实现。这意味着SM1的参数不公开不等于不安全更准确的说法是不靠公开算法细节来接受审查而是靠硬件模块的物理保护和严格的管理要求来保证安全。用SM1的场合基本都要求配套的密码设备有商用密码产品认证证书API接口由厂商SDK提供密钥从设备内部生成不出硬件。实验时想跑SM1通常得买个开发板或加密机体验和AES这类纯软件算法完全不一样。实际开发中如果项目不是强制要求必须用硬件SM1多数软件场景会用SM4——同样是国密对称算法128位密钥分组128位但算法公开、可以纯软件实现、性能和AES相当。见到很多系统写支持SM1其实底层是硬件密码机写支持SM4才是应用层软件直接干。3.2 SM2非对称算法签名、加密、密钥交换一鱼三吃SM2是基于256位椭圆曲线的非对称算法它一口气覆盖了三类功能数字签名、公钥加密、密钥交换。对应到工程里分别是身份认证与防抵赖、敏感数据加密传输、协商会话密钥。这三种操作虽然同属SM2但使用的参数、流程、输出格式各不相同调用接口的时候不能搞混。从安全强度上说SM2的256位密钥大致对标RSA-3072甚至更高但签名长度只有约64字节比RSA-2048的256字节签名短得多。这意味着SM2的签名传输开销小验签运算也快。我在实际对接国密网关时最直观的感受就是SM2签名速度比RSA快计算量低一截尤其在高并发证书验证场景下优势明显。3.3 SM3杂凑算法算法本身简单搭配起来门道多SM3的输出是256位摘要分组长度512位整体结构和SHA-256非常接近。它的定位就是完整性校验、消息认证、KDF密钥派生、SM2签名时的预哈希。单独看SM3并不复杂但工程里容易忽略的是SM3计算前的预处理和SM2签名流程的字节序、ASN.1编码规则。同样的原文你用GmSSL算出一个SM3摘要可能和某些厂商SDK算出来的hex不完全一样——多数情况下不是算法错了而是编码格式、填充方式或者字节序差异导致的。解决这个问题没有捷径对接时先把测试向量对齐用标准向量验证两边的SM3输出一致再往下走签名、验签联调。别一上来就拿真实业务数据联调否则出了问题很难定位是编码问题还是算法问题。3.4 三种算法怎么合成一套完整方案一个典型的国密HTTPS握手大致长这样客户端和服务端通过SM2密钥交换或SM2证书来完成双向身份认证协商出一个临时会话密钥后续所有业务数据用SM1或SM4对称加密传输每一条关键报文附带SM3摘要和SM2签名保证可审计、防篡改。三件套谁都不是主角但缺了谁都不转。这其实就是国密版TLS的底层模样。理解了对称加密负责数据、非对称加密负责密钥分发、哈希负责完整性校验再看任何加密协议都会觉得它眼熟。4. 两类算法在一次安全通信里的完整配合4.1 混合加密HTTPS到底在加密什么纯对称加密的问题前面说了密钥分发不安全。纯非对称加密的问题则更实际慢、密集计算消耗大。所以现代协议几乎都采用混合加密非对称算法负责传钥匙对称算法负责传货。以TLS握手为例简化后的流程是客户端请求连接拿到服务端证书证书里包含服务端的公钥。客户端生成一个随机数作为预主密钥用服务端公钥加密后发过去。服务端用私钥解密拿到预主密钥双方各自推导出会话密钥。之后的所有HTTP请求响应全部用会话密钥做对称加密比如AES-GCM或SM4-GCM。你打开浏览器看HTTPS标志看到的那把小锁背后就是这套流程。拿这个模型反推任何加密系统设计都会清晰很多。4.2 数字签名方向和加密相反千万别搞混加密和签名虽然都牵涉公钥私钥但方向完全相反。加密是公钥加密、私钥解密目的是保密签名是私钥签名、公钥验签目的是身份认证和防篡改。签名流程一般分三步对原文算SM3哈希得到摘要用私钥对摘要做签名运算得到签名值把原文和签名值一起发给接收方。验签时接收方重新算原文哈希用公钥验证签名值。只要原文被人改过一个bit哈希摘要就对不上验签直接失败。很多初学者会把用私钥加密、用公钥解密叫数字签名这话听着好理解但严格讲不对。私钥加密不具备普遍性因为私钥加密的结果任何持有公钥的人都能解开没有保密价值而签名要证明的是这消息确实来自私钥持有者所以签名和加密必须被当成两套独立操作来设计。给一个Python层面的参考逻辑用标准库做RSA签名是这么玩的from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives.asymmetric import padding, rsa private_key rsa.generate_private_key(public_exponent65537, key_size2048) public_key private_key.public_key() message bimportant payload signature private_key.sign( message, padding.PSS(mgfpadding.MGF1(hashes.SHA256()), salt_lengthpadding.PSS.MAX_LENGTH), hashes.SHA256(), ) # 验签 try: public_key.verify( signature, message, padding.PSS(mgfpadding.MGF1(hashes.SHA256()), salt_lengthpadding.PSS.MAX_LENGTH), hashes.SHA256(), ) print(验签通过) except Exception: print(验签失败)这段代码里的签名第一步其实内部也是先算摘要再对摘要做运算跟SM2签名流程在思想上一致。4.3 密钥管理比算法本身更容易翻车的环节算法选对了只是第一步密钥管理才是工程灾难重灾区。最常见的几个问题硬编码密钥、明文密钥文件、密钥不轮换、私钥权限开得过大、密钥备份方式不当。我见过一个项目把AES密钥直接写死在配置文件里然后整个配置文件提交到Git仓库。也见过SM2私钥按Base64硬编码在代码里换一次密钥要重新发版。这类问题算法再强也没用因为攻击者根本不用破解算法直接从代码里拿钥匙就行。正规做法是对称密钥和私钥统一放到密钥管理系统或硬件密码机里应用只通过接口使用密钥不接触明文私钥关键密钥定期轮换并确保轮换时业务侧有平滑过渡机制访问私钥要有审计、有权限分级。记住一个经验法则密钥管理虚标程度比算法本身虚标程度严重得多审计安全的时候先查密钥别急着查算法。5. 选型时真正要看的指标性能、强度、兼容性缺一不可5.1 性能对比对称加密为什么比非对称快那么多我做过一个压测用AES-128加密1MB数据耗时不到1毫秒用RSA-2048加密同样1MB数据按每次最多加密245字节算需要分成几千块每块一次公钥运算总耗时数十秒。这就是为什么没人用RSA加密大文件。SM2虽然比RSA快但椭圆曲线点乘运算仍然远慢于AES的轮变换。拿它加密大量数据同样不现实。所以做性能评估时不要把加密当成单一动作。先确定对称加密算法和模式比如SM4-GCM再确定非对称握手频率。握手是一次性的数据加密是持续的绝大多数系统的时间都花在对称加密上。非对称算法只有在握手、签名、验签这种低频操作里才显露存在感。5.2 安全强度对标怎么看密钥长度够不够不同算法之间不能直接比密钥长度但有安全强度的换算关系。下面这张表是我日常做方案时的参考算法密钥长度安全强度参考典型用途SM1128位约相当于AES-128硬件加密模块、金融数据加密SM4128位约相当于AES-128软件/硬件通用对称加密SM2256位约相当于RSA-3072签名、加密、密钥交换SM3256位摘要约相当于SHA-256完整性校验、摘要计算RSA2048位约相当于SM2-256略低传统证书体系、兼容存量系统AES128/256位128位当前仍安全国际通用对称加密选型原则很简单新的系统能上国密优先国密不能上的选AES-256和SHA-256兜底。RSA-2048在当前仍然没被攻破但新项目不建议再以它为主力非对称算法密钥太长、签名太大、运算偏慢未来还会面临安全强度不达标的合规压力。5.3 兼容性密钥格式和证书链的隐性成本算法本身不会让你失眠让你失眠的是生态兼容性。SM2证书、SM2签名值、SM3摘要在不同语言和平台上的编解码实现并不统一。Java的Bouncy Castle对国密支持较好但配置不熟的人容易踩坑OpenSSL原生不支持国密得用GmSSL或其他分支很多线上环境的Nginx没有编译国密模块导致HTTPS国密改造变成一场跨部门拉锯战。实际对接经验告诉我凡是涉及与外部系统做国密联调第一件事是交换测试向量和编解码样例双方把ASN.1编码、Base64规则、证书格式对齐。不要默认对方用的也是标准实现标准只在纸面上联调时只认字节。6. 我踩过的坑和给新人的几个实在建议6.1 坑一用非对称加密去传大字段早年有个项目产品经理要求所有敏感数据必须非对称加密结果数据库里一张用户表几十个字段全用RSA加密存储查询时逐字段解密接口平均响应时间从50毫秒飙到3秒。后来改成身份令牌用SM2签名会话密钥用SM2密钥交换协商字段级加密统一用SM4-GCM性能问题当场消失。这个案例我讲了很多次非对称加密负责解决信任和分发对称加密负责解决高效和大规模。不要因为听上去高大上就把非对称加密当成万能药。6.2 坑二只做加密不做完整性校验另一个项目对报文做了SM4加密但没有做任何完整性校验被中间人改了密文里的一段接收方解密后拿到乱码程序直接报错崩溃。后来在密文上叠加SM3摘要和SM2签名任何篡改在验签环节就会被发现根本到不了解密阶段。加解密从来不是孤立的保密、完整、认证要一起设计。凡是只提加密不考虑防篡改和身份认证的方案都是半成品。6.3 几个可以马上用的经验如果你现在就要设计一个带加密的接口我建议这样起步先用SM3或SHA-256对请求体算摘要再用SM2/RSA私钥对摘要做签名放到header里对端验签确认身份和数据完整。敏感响应体用SM4/AES-GCM对称加密会话密钥通过SM2密钥交换或证书公钥加密传输。对称密钥和私钥全部纳入密钥管理系统禁止出现在代码、配置文件和Git记录里。联调前先对齐测试向量确定字节序、编码格式、填充模式。压测时分别测对称加密吞吐和非对称握手TPS两个指标分开观察别混在一起。6.4 最后再说一点我自己做过很多次对称加密和非对称加密的选型评审最终发现真正难的不是算法本身而是把三种算法正确编排成一个完整的信任链条。对称算法、非对称算法、哈希算法这三兄弟各有各的本事谁也不能替代谁。SM1、SM2、SM3之所以常被放在一起研究就是因为它们在国密体系里天然构成了一套完整的配合关系。你不需要记住所有数学细节但一定要理解每个算法在协议里的位置对话内容多交给对称加密钥匙要安全送达交给非对称加密消息有没有被动过交给哈希。把这个模型刻在脑子里以后不管遇到AES、RSA、SM2还是别的什么新算法你都能一眼看穿它在整个安全方案里扮演的角色。