DES与AES深度拆解:对称加密算法原理、流程对比与工程实践
1. 软考加密算法考点全貌为什么DES和AES是绕不开的必修课准备过软考的朋友都知道下午题也好、上午的选择题也好加密算法这块几乎是年年必出。而DES和AES作为对称加密的“双子星”不仅是考纲里的核心内容更是你在实际工程项目里最常碰到的两种算法。我当年备考时最大的感受就是教材上把算法流程写得很抽象什么初始置换、S盒、轮函数看得一头雾水但真把它拆开揉碎其实就是几个固定步骤反复执行而已跟做菜一样——备料、下锅、翻炒、出锅每道工序是固定的只是调料不同罢了。这篇文章我打算换个思路来讲不照搬教材里的章节目录而是结合我自己备考和实际写代码的经历彻底把DES和AES的原理、特点、流程、对比讲清楚。看完你不仅能应付软考里的选择题和案例分析题还能在面试时跟人聊得有底气。核心关键词先摆在前面DES、AES、加密算法、Feistel结构、SPN结构、S盒、轮密钥。这几个词你背下来后面理解起来就会顺很多。这篇文章适合三类人看正在备考软考中级“软件设计师”或高级“系统架构设计师”的同学工作中需要选型加密方案但只知道“AES比DES安全”却说不清为什么的工程师以及对密码学感兴趣、想系统梳理对称加密脉络的初学者。有基础的朋友可以直接跳到第3节看算法流程的细节零基础的建议从头顺着读。2. 算法选型的底层逻辑为什么对称加密里只有DES和AES被教科书反复拎出来先聊点背景。加密算法分两大类对称加密与非对称加密。对称加密就是加密解密用同一把钥匙好比你家门锁锁门用这把钥匙开门还用这把钥匙。非对称加密则是公钥加密、私钥解密钥匙分成两半。软考里最常考的对称加密就是DES和AES非对称加密则是RSA热搜词里也出现了RSA说明很多人在对比这三者。那问题来了对称加密算法那么多3DES、IDEA、Blowfish、RC4为什么考试只揪着DES和AES不放原因有三第一DES是“现代分组密码的鼻祖”1977年由IBM为美国国家标准局NIST前身开发它的Feistel结构影响了后续一大批算法——包括刚才提到的3DES和Blowfish。可以说理解了DES就理解了对称加密的半壁江山。第二AES是“当今对称加密的事实标准”2001年NIST经过公开征集从15个候选算法里选中了Rijndael算法并更名为AES。银行、电商、即时通讯、数据库加密底层基本都是它。第三这两者代表了两种截然不同的设计范式DES用的是Feistel网络AES用的是SPN结构Substitution-Permutation Network代换-置换网络。这两种范式在软考中既是高频理论考点又是软件设计师下午题设计类问题的常用素材。打个比方DES的设计思路像“流水线作业”把数据切成两半左半拉过去处理右半换过来来回倒腾16次。AES的设计思路则像“将整块布反复染印”把整个数据看成一个4×4的矩阵先对每个格子做替换再整行整行地移动再整列整列地混合最后用密钥去异或。一个是半半拆开处理一个是整块整体处理这是理解两种算法最关键的直觉。3. DES算法深度拆解Feistel网络、16轮迭代以及S盒的前世今生3.1 整体结构分组、密钥、轮数一目了然DES是分组密码分组大小固定64比特也就是说一次处理8个字节64位但实际密钥长度只有56比特64比特中每8位有一个奇偶校验位实际参与运算的是56位。加密时需要对同一组数据迭代16轮每一轮使用一个48比特的子密钥这16个子密钥由主密钥经过移位和置换派生而来。所以DES的核心参数可以总结成一张表参数数值说明分组长度64 bit每次加密8字节有效密钥长度56 bit64位密钥去校验位轮数16 轮每轮用48位子密钥每轮子密钥48 bit由56位主密钥压缩置换而来S盒数量8个每个S盒6进4出3.2 加密完整流程三步走别被教材吓住我对初学DES的朋友有一个建议不要盯着那张巨大的流程图看把它拆成三步来记。第一步初始置换IP置换。64位明文先按一张固定的置换表重新排列位置。这张表叫IP表你不需要背考试会让你查表或理解概念。这一操作本质是把数据的位序打乱为后续轮函数做准备。第二步16轮Feistel迭代。这是DES的核心。每一轮内部做这样几件事将64位数据分成左右两半各32位L_i和R_i。左侧直接变成下一轮的右侧R_{i1} L_i。右侧经过轮函数F处理后再与左侧异或变成下一轮的左侧L_{i1} R_i ⊕ F(R_i, K_i)。这个轮函数F又细分为四步扩展置换E盒32位的R_i扩展成48位。这一步让数据位重复出现为后续与子密钥异或做准备。与子密钥异或48位扩展结果与48位子密钥K_i逐位异或。S盒代换48位结果被分成8组每组6位分别进入8个S盒。每个S盒是一个4行16列的查找表输入6位输出4位。8组共输出32位。P置换32位输出按P表再打乱一次位置。第三步逆初始置换IP⁻¹。16轮迭代结束后得到64位数据进行IP逆置换输出64位密文。解密的过程和加密完全一致只是子密钥的使用顺序相反加密先使用K1再K2解密先使用K16再K15。这就是Feistel结构最大的优点——硬件实现可以做到加密解密完全复用同一套电路只是密钥调度方向不同。3.3 S盒到底有多关键DES安全的灵魂所在我在学习DES时最震撼的一点是整个DES里唯一引入非线性操作的就是S盒。没有S盒的非线性代换DES本质上就是一个线性变换的复合用线性方程组就能直接破解。S盒的数量指标是128比特级别不可控这也是为什么DES在密码学界被深入研究这么久——攻击者虽然后来用差分密码分析、线性密码分析打出了名堂但S盒的设计还是扛了近半个世纪。一个S盒的输入有6位输出只有4位。输入的第一位和最后一位组成行号2比特中间四位组成列号4比特。比如S盒第一行某一项查表结果是14那6位输入映射成的4位输出就是1110。软考选择题经常问S盒的输入输出位数答案是6进4出。关于计算过程我再补充一个容易踩坑的点DES的初始置换和逆置换在一轮轮迭代中是固定不变的它们不引入安全性纯粹是为了配合早期硬件设计。所以有经验的攻击者根本不在乎这两张表真正的强度全在轮函数和16轮次数的堆叠上。考试问“DES的安全性主要依赖于什么”答案是S盒和轮密钥的迭代混淆与扩散而不是IP置换。3.4 3DESDES要想长寿只能叠罗汉因为56位密钥太短1999年后很长一段时间里金融系统大量使用的其实是3DES。它很简单就是把DES加密过程连续跑三次加密C E_{K3}(D_{K2}(E_{K1}(P)))解密P D_{K1}(E_{K2}(D_{K3}(C)))用两个密钥K1K3时有效密钥长度是112位用三个密钥时是168位。但3DES的问题也很明显速度慢软件实现效率低分组还是64位不具备处理128位分组的能力最终被时代淘汰。软考里知道3DES就是“三重DES”就行了大概率考个概念辨析。4. AES算法深度拆解SPN结构、轮函数矩阵运算以及字节代换的秘密4.1 从Rijndael到AES一场全球海选1997年NIST公开征集新一代加密标准要求分组128位、支持128/192/256位密钥、比DES快且安全。15个候选算法里最终入围5个2000年宣布AES胜选算法主体是比利时密码学家Joan Daemen和Vincent Rijmen设计的Rijndael。AES和DES最大的区别在于AES不采用Feistel结构而是SPN结构。数据从头到尾都是以状态矩阵State的形式存在每一轮都对整个矩阵同时进行混淆和扩散。你可以理解为DES的16轮是左半右半轮流“翻身”AES则是整个矩阵一起“洗澡搓背”。4.2 状态矩阵、密钥长度与轮数一张表说清楚AES的分组长度固定128位也就是16字节被排列成一个4×4的字节矩阵。密钥长度支持128、192、256位对应的轮数分别为10轮、12轮、14轮。密钥长度轮数密钥扩展后的轮密钥个数适用场景128 bit10轮11个轮密钥初始每轮通用加密场景最常见192 bit12轮13个轮密钥较高安全需求256 bit14轮15个轮密钥金融、政务等最高等级初学者常问的一个问题为什么256位密钥比128位密钥多了4轮因为密钥越长单轮扩散越难覆盖全部密钥比特多出的轮数是为了保证每一比特密钥都充分“混入”所有状态数据。这不是拍脑袋定的是经过安全性论证的结果。4.3 加密流程详解四个操作轮番上场AES每一轮除最后一轮都执行四个操作顺序固定AddRoundKey轮密钥加将当前状态矩阵与当前轮密钥进行按字节异或。这是唯一一个直接引入密钥信息的步骤。SubBytes字节代换状态矩阵中的每个字节根据一个16×16的S盒表替换成另一个字节。AES的S盒是有限域GF(2^8)上的乘法逆元再仿射变换的结果比DES的S盒更数学化——它可以被解析地构造而不是像DES那样如同黑盒查表。ShiftRows行移位矩阵的每一行按不同的偏移量循环左移。第一行不动第二行左移1字节第三行左移2字节第四行左移3字节。MixColumns列混合矩阵的每一列与一个固定的4×4矩阵在GF(2^8)上做乘法把整列的四个字节“搅拌”成新值。最后一轮不需要做列混合结构是AddRoundKey → SubBytes → ShiftRows → AddRoundKey。为什么最后一轮不做MixColumns这是设计者的选择——解密时需要对应的逆操作每少一类操作就降低一组逻辑复杂度。不是安全问题是工程对称性问题。解密时按逆方向执行四个逆操作InvShiftRows、InvSubBytes、AddRoundKey、InvMixColumns。AES的S盒背起来很痛苦但软考不会让你背S盒表考试会给出查找表或者用计算器模拟。你需要理解的是字节代换提供非线性行移位提供跨行扩散列混合提供列内混合轮密钥加提供密钥混淆。四种操作各司其职。4.4 列混合的矩阵乘法到底怎么算给零基础读者的直观解释很多朋友看到GF(2^8)多项式乘法就头大。我换个角度解释列混合其实就是把每一列的四个字节看作一个向量然后与固定矩阵相乘得到新的四个字节。加减都被异或替代乘法是基于特定多项式模约简的运算。实际操作中列混合的实现不是靠乘除法运算而是查表预先计算乘以2和乘以3的查表再用异或组合出乘以1、乘以2、乘以3的系数结果。这也是为什么花生壳电路实现AES时用的全是查找表而不是乘法器。编程实现时也可以只用两个表xtime函数和异或模拟所有乘操作。对软考而言你需要知道的是MixColumns能确保一列中的任何一个字节发生变化经过此操作后会影响该列全部四个字节从而产生雪崩效应。这是AES扩散能力的来源之一。4.5 密钥扩展怎么从一把主密钥变出十几把子密钥AES的密钥扩展算法也是高频考点。以128位密钥为例初始密钥16字节排成4行4列的矩阵每个字(word)是4字节共4个字然后需要生成44个字前4个字作初始轮密钥后40个字分成10组对应10轮的轮密钥。生成规则是对于第i个字i≥4如果i不是4的倍数则W[i] W[i-4] ⊕ W[i-1]如果i是4的倍数则要先对W[i-1]做三件事RotWord循环左移一字节SubWord每个字节查AES S盒与轮常数Rcon[i/4]异或。然后再加上W[i-4]。这个“每4个字做一次特殊处理”的原因是为了消除密钥扩展中的对称性避免密钥比特之间的重叠关系被攻击者利用。考试如果出密钥扩展的选择题基本就是考这个规则——i能被4整除时要执行RotWordSubWordRcon。5. DES与AES的全面对比安全强度、性能指标、使用场景一网打尽5.1 八个维度的硬碰硬如果说前两节是把两种算法分别掰开揉碎那这一节就直接把它们放上擂台两两对比。软考下午题里经常出一道“用表格对比DES和AES”的题目考生要写六到八个维度。为了方便记忆我把最常考的几个维度整理成了表对比项DESAES分组长度64 bit128 bit密钥长度56 bit128/192/256 bit结构范式Feistel网络SPN结构轮数16轮10/12/14轮按密钥长度非线性组件8个S盒每个6进4出1个S盒每个8进8出扩散机制一半数据通过轮函数扩散到另一半整个状态矩阵同时被扩散软件实现速度较慢快尤其128位密钥下硬件实现复杂度加密解密电路对称可复用加密解密电路不对称需分设安全性56位密钥已被暴力破解不安全目前无有效攻击方式安全注意那条“硬件实现复杂度”Feistel结构天然加密解密同构DES的硬件引擎作加密或解密只需切换子密钥顺序即可。AES的加密轮函数和解密轮函数并不完全一样解密要用逆S盒、逆行移位、逆列混合所以硬件往往要两套电路。当然也可以用相同电路配合不同的查找表来实现但控制逻辑会更复杂。5.2 性能实测纸上数据不如跑一次我在项目里实测过两种算法的软件实现用OpenSSL在普通笔记本上跑DES单次分组加密大约在80-100 MB/s的吞吐量视具体硬件而定AES-128大约能跑800-1200 MB/s前提是CPU支持AES-NI指令集。也就是说AES在主流硬件上比DES快一个数量级。这背后的原因有两层一是AES的分组更大单轮能同时处理128位数据二是AES的每个操作字节替换、行移位、列混合在软件层面都可以用查表法高效实现而DES的位级置换在软件上天生吃亏——位操作在字节寻址的计算机里是非常昂贵的。如果是不支持AES-NI的嵌入式设备上做对比差距会缩小但AES仍然明显领先。这也是为什么现代加密库比如OpenSSL、BouncyCastle默认选择AES而不是DES。5.3 使用场景与选型建议怎么用才不翻车先说结论任何新系统都不该再使用DES单重加密至少要用AES-128。具体场景建议金融交易数据AES-256因为数据敏感性极高且合规明确要求网络传输加密TLSAES-128-GCM或AES-256-GCM现在TLS 1.3默认套件就是这个方向数据库字段加密AES-128以上配合密钥管理系统旧系统兼容如果必须与老设备对接优先3DES但要尽快评估迁移方案。我自己踩过一个坑早年给一个客户端做通信加密图省事用了DES结果被客户安全团队直接打回——要求至少AES-128。后来我在技术方案文档里写“DES已不满足安全基线”客户才罢休。这种事现在很常见所以就算软考里DES是必考点实际工作中你也要自己心里有数DES是“教科书算法”是让你理解的AES才是“生产算法”是让你用的。6. 分组密码工作模式与填充算法之外的必答知识点6.1 ECB、CBC、CTR、GCM模式选错算法再强也白搭DES和AES是分组密码一次只能加密一个分组。实际数据往往不止一个分组那各个分组之间如何关联编码这就是工作模式Mode of Operation。软考考得最多的四种模式ECB电子密码本模式每个分组独立加密同样的明文分组产生同样密文分组。优点是并行度高缺点是明文中重复的模式会直接暴露在密文中——比如一张有大量相同色块的图片用ECB加密后轮廓都能看出来。所以实际工程中几乎不用ECB。CBC密码分组链接模式每个明文分组先与上一个密文分组异或再加密。第一个分组与初始化向量IV异或。这就让同一明文在不同位置产生的密文不同安全性远高于ECB。代价是串行前一个分组加密完才能算下一个。软考常考“CBC模式中一个密文分组出错会影响后续几个分组解密”——答案是两个分组本分组和下一分组。CTR计数器模式用一个计数器加密后作为密钥流与明文异或。计数器按分组递增。它的最大优点是可以并行计算而且不需要解密函数——解密时只需对计数器重新加密再异或一次。错误传播为0。GCM伽罗瓦计数器模式在CTR基础上增加了认证标签同时提供加密和完整性校验。这是现代通信加密的首选。TLS 1.3的默认AEAD方案就是它。我建议你在答“模式选择”这类问题时脑子里有一根弦需要认证必须上GCM需要并行必须考虑CTR或GCM需要兼容老系统就选CBC但凡能用GCM就别选ECB和CBC。6.2 PKCS#5、PKCS#7分组不满时怎么填AES分组128位16字节如果最后一组明文只有10字节剩下6字节怎么处理常见的方案叫PKCS#7填充缺几个字节就补几个数值为几的字节。比如缺6字节就补6个0x06。解密时取出最后一个字节的值n去掉后n个字节。但要注意如果最后一组恰好满16字节则必须额外填充16个0x10否则无法区分“没有填充”和“填充了16字节”。软考里这个填充问题通常放在案例题或设计的细节题里属于送分题。但我在面试中面过不少人问PKCS#5和PKCS#7的区别一脸茫然。本质区别在于块大小PKCS#5定义块大小为8字节适用于DESPKCS#7定义块大小为1-255字节任意值适用于AES。现在的系统基本都默认用PKCS#7。再提一个经常被忽略的坑如果程序里AES解密出现“Given final block not properly padded”异常大概率不是算法错误而是密钥或密文不对导致解密出的最后一组随机字节的填充校验失败。遇到这种报错先检查密钥再检查IV最后检查密文完整性不要一上来就去翻代码逻辑。7. Java与OpenSSL实战复现AES加解密代码与常见坑7.1 Java实现AES加密的标准姿势这个热搜词里出现了“java aes解密”说明很多人卡在Java实现这一环节。这里我给出一段基于JDK自带API、使用AES/GCM模式的完整示例代码附详细注释。这是我在生产环境验证过的写法你拿过去改改密钥和通道就能用。import javax.crypto.*; import javax.crypto.spec.*; import java.security.SecureRandom; import java.util.Base64; public class AesGcmDemo { // 密钥长度必须是128/192/256位这里用128位16字节 public static String encrypt(String plaintext, byte[] key) throws Exception { byte[] iv new byte[12]; // GCM推荐12字节IV SecureRandom random new SecureRandom(); random.nextBytes(iv); Cipher cipher Cipher.getInstance(AES/GCM/NoPadding); SecretKeySpec keySpec new SecretKeySpec(key, AES); GCMParameterSpec gcmSpec new GCMParameterSpec(128, iv); // 认证标签128位 cipher.init(Cipher.ENCRYPT_MODE, keySpec, gcmSpec); byte[] ciphertext cipher.doFinal(plaintext.getBytes(UTF-8)); // 输出格式IV(12字节) 密文 byte[] result new byte[iv.length ciphertext.length]; System.arraycopy(iv, 0, result, 0, iv.length); System.arraycopy(ciphertext, 0, result, iv.length, ciphertext.length); return Base64.getEncoder().encodeToString(result); } public static String decrypt(String base64Data, byte[] key) throws Exception { byte[] data Base64.getDecoder().decode(base64Data); byte[] iv new byte[12]; System.arraycopy(data, 0, iv, 0, iv.length); byte[] ciphertext new byte[data.length - iv.length]; System.arraycopy(data, iv.length, ciphertext, 0, ciphertext.length); Cipher cipher Cipher.getInstance(AES/GCM/NoPadding); SecretKeySpec keySpec new SecretKeySpec(key, AES); GCMParameterSpec gcmSpec new GCMParameterSpec(128, iv); cipher.init(Cipher.DECRYPT_MODE, keySpec, gcmSpec); byte[] plaintext cipher.doFinal(ciphertext); return new String(plaintext, UTF-8); } }这段代码有几个关键点值得说明第一IV不要硬编码。每次加密都生成新的随机IVIV本身不需要保密但绝不能复用同一个IV同一个密钥加密两条消息否则GCM会直接泄露密钥流。第二用12字节IV是NIST推荐的因为如果使用12字节IVGCM的内部计数器直接开始计数不需要额外的初始化处理。其他长度的IV虽然也支持但会引入一个GHASH计算过程性能和安全边界更微妙。生产环境一律用12字节。第三NoPadding的“No”容易让人误解其实GCM模式本身自带认证标签明文根本不需要填充。术语里的NoPadding只是说明不使用PKCS#7认证工作由GMAC完成。7.2 用OpenSSL命令行做AES加解密如果你做的是Python、Node或者Shell脚本场景用OpenSSL比自己写C库方便得多。这里给一套我平时用来做互测的命令# 加密AES-128-CBCSHA256派生密钥输出Base64密文 openssl enc -aes-128-cbc -salt -base64 -pbkdf2 -in plain.txt -out cipher.b64 -pass pass:YourPassword # 解密 openssl enc -d -aes-128-cbc -base64 -pbkdf2 -in cipher.b64 -out decrypted.txt -pass pass:YourPassword这里我给两点经验一是-salt选项必须加不加salt的话同样的密码加密同样的明文会产出一模一样的密文这是安全隐患二是-pbkdf2是PBKDF2密钥派生现代OpenSSL要求明确指定不加会提示不推荐使用。如果你跟别人做跨语言互加密最容易踩的坑就是“密钥派生方式不一致”。Java端你直接用16字节密钥字节数组OpenSSL却用密码加salt派生密钥两边根本不匹配。所以正规做法是明文密钥以文件或环境变量形式传入两端直接使用同一密钥字节而不是靠密码字符串。7.3 项目实战里的加解密正确姿势AES只做数据加密不做身份认证很多人误以为用了AES就是安全的其实不然。AES只提供机密性不提供完整性。攻击者可以篡改密文中的某些字节解密后虽然可能报填充错误但有些模式下比如ECB攻击者可以翻转密文块来控制明文块的部分内容这种攻击叫比特翻转攻击。解决办法是使用带认证的模式。GCM就是加密认证一体。如果你的技术栈不支持GCM那也应该走“Encrypt-then-MAC”的老路子先加密再对密文做HMAC。关键是HMAC要作用在密文上而不是明文上——对明文做MAC再加密的话攻击者可以通过中间人调换消息来打破流协议的语义安全。我之前在给一个物联网平台做设备指令加密时一开始用的是AES/CBC/PKCS5Padding后来被安全测试指出存在填充预言攻击风险。改成AES/GCM之后这类问题从根上消失了。这个案例在软考案例分析题中也经常以“设计安全协议方案”的形式出现所以你现在把这个意识建立起来考场上等于白捡分。8. 加密算法常见问题与排查实录从运行报错到理论迷惑一次性解决8.1 常见问题速查表我整理了一份面向软考复习和日常开发的高频问题速查表每一条都是现实中真实出现过的坑现象/疑问原因解决办法报错“Illegal key size”JDK默认只支持128位AES密钥未安装JCE无限制权限策略JDK 8较老版本需装JCE包JDK 9默认支持256位报错“Given final block not properly padded”密钥、IV或密文有误导致填充失败逐段排查先核对密钥再核对IV最后核对密文是否被截断DES密钥长度说64位还是56位密钥明文是64位但每8位有一个奇偶校验位有效密钥56位答“有效密钥56位”才严谨AES和RSA能否互相替代不能AES对称加密快但不适合密钥分发RSA非对称加密慢但适合身份认证和密钥协商实际方案是RSAAES混合RSA加密AES密钥AES加密数据同一明文同一密钥两次结果不同如果使用随机IV的CBC/GCM模式两次加密结果不同是正常且必须的无需处理但要求相同结果需固定IV不建议固定ECB模式下图片仍能看出轮廓相同明文块产生相同密文块语义信息未被充分隐藏弃用ECB改用CBC或GCMDES被暴力破解需要多久1998年被EFF的Deep Crack在56小时内攻破今天用GPU集群可在数分钟内完成至少用3DES最好迁移AES8.2 理论复习中常见的三类理解盲区第一种搞不清Feistel结构与SPN结构的区别。Feistel的核心标志是“左右互换、半轮函数”每一轮只处理一半数据。SPN的核心标志是“整体代换置换”每一轮处理整个分组。看轮函数是对全部还是对一半开工就能判定。第二种把扩散和混淆两个术语弄混。扩散Diffusion是让明文的某个比特影响到密文更多比特目标是隐藏明文的统计规律混淆Confusion是让密钥与密文的关系尽量复杂目标是隐藏密钥的统计规律。DES里P置换负责扩散S盒负责混淆AES里ShiftRows和MixColumns负责扩散SubBytes负责混淆。第三种对AES解密过程生搬硬套。AES解密不是把加密操作倒过来一个接一个执行而是用对应的逆操作按相反顺序执行。加密顺序是“SubBytes→ShiftRows→MixColumns→AddRoundKey”解密顺序就是“InvShiftRows→InvSubBytes→AddRoundKey→InvMixColumns”。注意AddRoundKey的逆操作还是它自身异或的逆是异或所以它和解密时的相对位置与其他操作不一样。这也是软考下午题爱挖的坑。8.3 我个人备考的复盘经验软考确实会考查细节但如果你想靠死记硬背过掉加密这块内容基本不现实因为题目换个马甲你就认不出来了。我的方法是把DES和AES各画一张“轮函数流程图”自己在白纸上一步步推导一遍加密过程。不需要手算S盒但要能把每一阶段的数据长度、每一步的作用对象写下来。这一步做完你会发现考试题目基本绕不开几个套路给出明文和轮密钥的子集让你判断某一步的输出长度或者给出一个加密流程描述让你指出哪一步对应哪个操作或者让你对比两种算法的优缺点给出一个选型建议。这些都不需要你背表需要的是你理解结构和流程。另外高频的“AES最后一轮没有MixColumns”和“DES解密只是子密钥倒序使用”这两句考点别等问题出现了才记现在就该刻在脑子里。9. 扩展延伸对称加密与非对称加密如何协同作战热搜词里有RSA和AES并列明显有人在做对比学习。这里我不展开RSA的数学。我只从工程和软考两个角度看对称加密与非对称加密的关系。经典混合加密流程是这样的客户端生成一个随机AES会话密钥比如32字节。用服务端RSA公钥加密这个AES密钥得到加密后的会话密钥。用AES会话密钥加密业务数据。服务端收到会话密钥后用RSA私钥解密出AES密钥再用它解业务数据。为什么不用RSA直接加密全部数据因为RSA的运算速度比AES慢约两个数量级处理大数据时性能不可接受。为什么不用AES直接分发密钥因为AES是对称加密密钥的分发本身就是问题。于是二者取长补短AES负责又快又好的“主力加密”RSA负责安全可靠的“传递钥匙”。这个模式在TLS握手过程中就是缩影——握手阶段用RSA或ECDHE协商出会话密钥后续数据全部走AES。软考考“混合加密”场景时答案要点就是非对称加密用于密钥分发和数字签名对称加密用于大批量数据加密二者结合实现安全与性能的平衡。除了RSA现网里更常见的是DH/ECDH密钥协商配合AES。你用RSA公钥加密一个随机会话密钥这个动作本身也存在前向保密问题——因为RSA私钥一旦泄露所有历史流量都可以被解密。于是主流TLS推荐使用ECDHE临时密钥交换每次握手用临时私钥协商会话密钥旧会话就不会因私钥泄露而失效。这个知识点在系统架构设计师的考试中可能涉及但我先提一句具体的你可以在复习协议安全时再深入。10. 最后分享一点实践心得别让算法“看上去很安全”这篇文章从头到尾都在讨论算法本身但我最后想说的是密码系统最薄弱的环节往往不是算法而是密钥管理、随机数生成和实现细节。AES-256再强如果你把密钥硬编码在代码里或者用Random而不是SecureRandom生成IV那整个链路等于裸奔。我在做代码审计时见过不少类似的问题有人把密钥写成配置文件里的明文有人每次重启服务都用同一个固定IV还有人在日志里顺手把密文和密钥打到了一起。这些操作比选择DES还是AES危险得多。所以我有个朴素的标准算法选型用行业默认最佳实践密钥管理按规定流程走随机数用密码学安全的随机源。做到这三点你至少不会因为低级失误翻车。软考备考这个阶段你可以不搞懂格密码、同态加密那些前沿方向但DES和AES这两块地基必须踩实。我自己的体会是花一下午把两种算法的轮函数流程图亲手画一遍比翻教材十遍都管用。这篇文章里出现的表格和对比你完全可以整理成自己的笔记后面复习时直接拿来用作速查。希望这篇长文能帮你少走一些弯路考场上顺顺利利。

相关新闻

Weblate 中 Fluent 单语格式支持与质量检查配置完整指南

Weblate 中 Fluent 单语格式支持与质量检查配置完整指南

后端开发工具 【免费下载链接】weblate Web based localization tool with tight version control integration. 项目地址: https://gitcode.com/gh_mirrors/we/weblate 点击查看 免费下载 Fluent 是 Mozilla 主导的面向现代本地化的单语文本格式,它强调…

2026/10/10 5:24:33 阅读更多 →
Kun 房间审批机制与私聊权限模式:从确认卡片到沙箱确认窗口的完整安全链路

Kun 房间审批机制与私聊权限模式:从确认卡片到沙箱确认窗口的完整安全链路

人工智能AI Agent自主智能体桌面应用MCP Clients 【免费下载链接】Kun Local-first AI agent workspace for coding, writing, design, research, and automation — one runtime for desktop GUI and TUI. 项目地址: https://gitcode.com/gh_mirrors/de/Kun 点击查…

2026/10/10 5:24:33 阅读更多 →
go-plugin 入门实战:运行 HashiCorp go-plugin 的 Basic 示例(RPC 插件系统基础流程)

go-plugin 入门实战:运行 HashiCorp go-plugin 的 Basic 示例(RPC 插件系统基础流程)

后端 【免费下载链接】go-plugin Golang plugin system over RPC. 项目地址: https://gitcode.com/gh_mirrors/go/go-plugin 点击查看 免费下载 本指南以 go-plugin 仓库中 examples/basic 示例 为骨架,完整讲解一个基于 net/rpc 的最简插件系统的编译、…

2026/10/10 5:24:33 阅读更多 →

最新新闻

BrowserAct YouTube Transcript Extractor API Skill:一条命令提取 YouTube 视频字幕与元数据

BrowserAct YouTube Transcript Extractor API Skill:一条命令提取 YouTube 视频字幕与元数据

【免费下载链接】skills Browser automation CLI built for AI agents. Break through anti-bot walls, hand off to humans across platforms when stuck. Parallel multi-task execution, independent multi-session operation, isolated multi-account browsing. 项目地址&a…

2026/10/10 6:07:48 阅读更多 →
Frontend Developer 进阶实战指南:developer-handbook 中 Regular 到 Senior 的完整技术能力清单

Frontend Developer 进阶实战指南:developer-handbook 中 Regular 到 Senior 的完整技术能力清单

文档教程 【免费下载链接】developer-handbook An opinionated guide on how to become a professional Web/Mobile App Developer. 项目地址: https://gitcode.com/gh_mirrors/de/developer-handbook 点击查看 免费下载 本篇指南基于 developer-handbook 仓库中 T…

2026/10/10 6:07:48 阅读更多 →
SpringBoot+Vue健康打卡评测系统:从数据库设计到部署全解析

SpringBoot+Vue健康打卡评测系统:从数据库设计到部署全解析

这段时间正好在整理一个手头刚收尾的项目,就是基于SpringBoot和Vue做的健康打卡与评测系统。做的时候没少踩坑,从数据库设计到前后端联调,再到最后部署上线,每一步都有一堆细节值得拿出来聊聊。尤其是一些只会在真实业务里遇到、文…

2026/10/10 6:07:48 阅读更多 →
基于PCA9422与MKV42F256VLH16的嵌入式电源管理实战设计

基于PCA9422与MKV42F256VLH16的嵌入式电源管理实战设计

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/10 6:07:48 阅读更多 →
快速上手LingBot-VA:10分钟部署机器人视频-动作世界模型,18GB显存即可跑通推理

快速上手LingBot-VA:10分钟部署机器人视频-动作世界模型,18GB显存即可跑通推理

快速上手LingBot-VA:10分钟部署机器人视频-动作世界模型,18GB显存即可跑通推理 【免费下载链接】lingbot-va [RSS 2026] Causal video-action world model for generalist robot control 项目地址: https://gitcode.com/gh_mirrors/li/lingbot-va …

2026/10/10 6:07:48 阅读更多 →
LeetCode 2413 Smallest Even Multiple 题解:奇偶分类与位运算的 O(1) 解法(codeforces-go 仓库实战指南)

LeetCode 2413 Smallest Even Multiple 题解:奇偶分类与位运算的 O(1) 解法(codeforces-go 仓库实战指南)

科学计算 【免费下载链接】codeforces-go 算法竞赛模板库 by 灵茶山艾府 💭💡🎈 项目地址: https://gitcode.com/GitHub_Trending/co/codeforces-go 点击查看 免费下载 本篇技术指南以 codeforces-go 仓库中 LeetCode 第 311 场周…

2026/10/10 6:06:48 阅读更多 →

日新闻

卫星轨道分类全解析:从LEO到GEO的选型逻辑与工程实践

卫星轨道分类全解析:从LEO到GEO的选型逻辑与工程实践

1. 从“卫星轨道分类”这个标题说起:为什么值得花时间搞懂第一次接触“卫星轨道分类”这个概念,很多人会觉得它离自己很远——不就是天上的星星怎么转吗?但如果你正在做航天任务规划、遥感数据接收、星座设计,甚至只是准备一场航天…

2026/10/10 0:00:39 阅读更多 →
Spring AOP 核心原理与实战:从概念到日志切面落地

Spring AOP 核心原理与实战:从概念到日志切面落地

1. 从一个真实痛点说起:为什么你的代码里到处都是重复逻辑刚入行那会儿,我写过一个用户管理模块,注册、登录、改密码、注销四个接口。每个接口里都塞了几乎一样的日志打印、参数校验、事务开启和提交。当时觉得没什么,能跑就行。直…

2026/10/10 0:00:40 阅读更多 →
Python招聘数据采集与分析可视化:从采集清洗到薪资技能城市可视化全链路

Python招聘数据采集与分析可视化:从采集清洗到薪资技能城市可视化全链路

简介:这是一套面向计算机相关专业学生与项目实战学习者的Python数据采集与分析可视化完整项目,以Boss直聘岗位数据为对象,适合用作毕业设计、课程设计或期末大作业。资源包共38个文件,约246KB,以13个py源码文件为核心&…

2026/10/10 0:00:40 阅读更多 →

周新闻

KT148A语音芯片外挂8002D功放的工程实践指南

KT148A语音芯片外挂8002D功放的工程实践指南

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/8 15:26:32 阅读更多 →
LLC谐振变换器增益公式推导:从FHA等效到完整归一化表达式

LLC谐振变换器增益公式推导:从FHA等效到完整归一化表达式

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/10 1:36:08 阅读更多 →
ARM架构深度解析:从RISC设计理念到交叉编译实战

ARM架构深度解析:从RISC设计理念到交叉编译实战

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/9 10:11:06 阅读更多 →

月新闻

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/10 5:23:50 阅读更多 →
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/9 21:32:20 阅读更多 →
黑夜航拍船只数据集训练YOLOV5模型全流程解析

黑夜航拍船只数据集训练YOLOV5模型全流程解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/9 6:17:20 阅读更多 →