文章总结： 本文介绍了AES加密的六种常见模式ECB、CBC、CFB、CTR、GCM和XTS的原理、优缺点及适用场景。ECB不安全因相同明文产生相同密文；CBC通过IV提升安全性但需填充；CFB将块密码转为流密码无需填充；CTR支持并行处理；GCM在CTR基础上增加完整性校验；XTS专用于磁盘加密。文章提供了模式选择参考图，强调需根据具体场景选择最佳模式。 综合评分： 89 文章分类： 安全建设,应用安全

如何选择加密模式

谈思实验室

2026年7月9日 15:59 上海

在小说阅读器读本章

去阅读

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

在设计安全协议或其他使用加解密算法的场景中，经常会用到AES算法。关于在什么样的场景下使用AES可能不是一个值得深入讨论的问题，但是在如何选择加密模式的问题上，笔者认为需要反复思量。

想要区分不同加密模式的适用场景，首先需要对加密模式的原理有一定的了解。而要想了解加密模式，最合适的切入点便是最原始、最简单的ECB模式。

ECB模式全程电子密码本模式，其原理如上图所示。使用ECB模式，首先需要将明文分组，每个分组长度与密钥Key的长度相同，然后每个分组使用相同的密钥进行AES加密。在了解了ECB模式的基本原理之后，我们至少应该提出如下两个问题：

1）明文为什么要分组？

2）何为加密模式？

之所以要对明文进行分组，是因为AES只能加密固定长度的数据，为16个字节，128个比特位。所以我们对明文进行分组，就是将明文数据分割成固定的长度，以满足AES对输入数据的要求。这也引出了我们需要思考的第三个问题：

3）最后一个分组不足16个字节的时候怎么办？

答案是填充，将最后一个分组填充为16个字节长度，关于填充的方式，笔者打算写一篇专题进行讨论，但本文不打算就此展开。（实际上，当最后一个分组长度刚好为16字节时，也会进行填充，即增加一个分组的填充）

在回答完第一个问题和第三个问题之后，我们自然可以推导出第二个问题的答案——加密模式就是在进行加解密计算的过程中，对明文和相关信息进行处理的方式。

现在我们对分组加密模式有了初步的认识，但是这还远远不够，因为分组加密模式多达十几二十种，我们仅仅了解了最原始的ECB模式。话说至此，问题又来了：

4）为什么需要这么多的加密模式？ECB不够香吗？

ECB被取而代之的重要名目就是不够安全，因为每个分组的加密方式和Key完全相同，在明文相同的情况下，密文将会完全一样，这便是攻击者手里的刀，防御者眼里的沙子，当然需要改进，而CBC就是ECB的改进版本。

CBC全称密文分组链接模式，在CBC模式中，明文分组不会直接进行加密，而是经过一次异或之后再进入加密流程。第一个分组的明文与初始向量（IV）进行异或，然后使用AES加密，加密的结果与下一个明文分组异或，如此向下进行链式传导。因为在算法中引入了IV，相同的明文不再会得到相同的密文，安全性得到了很大的提升，CBC模式也因此成为最常用的分组加密模式。

CBC也不是万能膏药，哪里痛都能贴。比如如下几个痛点便是CBC也无法解决的：

• 加解密场景需要密文长度与明文相同
• 需要并行实现加解密
• 在保证机密性的同时，还需要保证完整性

看来，CBC不适用的场景还是蛮多的。针对第一个问题，我们可以使用CFB模式：

CBC与ECB模式一脉相承，它们都需要将明文分组成16字节的数据块，然后进行填充，即密文长度始终大于明文。为解决这个问题，CFB模式弃用了直接加密明文的方式，转而将加密作用在IV和Key上，再将结果与明文进行异或，所以这个时候明文不必再满足16字节的要求，因为异或运算的输入可以是任意长度，这就引出同时回答了本文关心的第五个问题：

5）CFB模式是如何将块密码转换成流密码的？

因为明文分组可以是任意长度，所以我们可以将明文分组长度设为1个字节，让加解密过程看起来像是流式运算。而最最重要的，此时明文不再需要填充了，密文长度完全与明文长度一致。

AES的运用场景之多决定了加密模式不会仅限于如上三种，当我们使用多处理器实现带硬件加速功能的SE芯片时，便会想到CTR模式，即计数器模式。

计数器模式通过递增一个加密计数器以产生连续的密钥流。其中，计数器即可实现为递增的函数，也可实现为随机函数。由于加密和解密过程中，计数器序列可以预生成，因此均可以进行并行处理，特别适合运用于多处理器的硬件上。CTR的另一个优点是密文中的错误位不会传播，解密时仅影响对应的明文位。

如果需要进一步保证密文的完整性，单纯只是用加密就不能解决问题了，而GCM模式就是用来满足这种需求的：

GCM可以理解为在CTR模式的基础上增加了一个GMAC算法，因此在生成的密文后将会附加一个Auth Tag，用来保证传输过程中的完整性。

到此为止我们一共介绍了五种常用的加密模式，最后我们将介绍的几乎是一个专用的加密模式——XTS，XTS基本专为存储加密设计，在磁盘加密的实现中运用广泛，比如linux上赫赫有名的dm-crypt机制，便是使用XTS实现。

关于XTS的原理我们将不再深入探讨，介绍它是因为加密磁盘的应用场景十分普遍，我们需要了解，但是却很少存在直接使用的场景。

关于原理的介绍且告一段落，笔者结合自己实际运用的经验和业内人士的分享，整理了一份最常用加密模式的对照表：

如上表格高度概括了ECB、CBC、CFB、CTR、XTS和GCM六种主流加密模式的原理、优缺点和应用范围，作为原理的总结。

相信绝大多数读者学习加解密算法的目的都是为了最终能够运用，也只有在实际运用中才能够真正领悟每种加密模式的特点，对其适用场景有更加深刻的理解。为了帮助大家进行选择，笔者作了一张加密模式选择的参考图：

该选择方案仅供参考，至于如何选择最佳的加密模式，还需要根据具体的场景和要求进一步判断。

来源：CSDN博主「车联网安全杂货铺」

https://blog.csdn.net/didaliping/article/details/121322141

end

谈思汽车媒体门户

精品活动推荐

AutoSec系列沙龙

专业社群

部分入群专家来自：

新势力车企：

特斯拉、理想、极氪、小米、零跑汽车、阿维塔汽车、智己汽车、小鹏、岚图汽车、蔚来汽车、吉祥汽车、赛力斯……

外资传统主流车企代表:

大众中国、大众酷翼、奥迪汽车、宝马、福特、戴姆勒-奔驰、通用、保时捷、沃尔沃、现代汽车、日产汽车、捷豹路虎、斯堪尼亚……

内资传统主流车企：

吉利汽车、上汽乘用车、长城汽车、上汽大众、长安汽车、北京汽车、东风汽车、广汽、比亚迪、一汽集团、一汽解放、东风商用、上汽商用……

全球领先一级供应商：

博世、大陆集团、联合汽车电子、安波福、采埃孚、科世达、舍弗勒、霍尼韦尔、大疆、日立、哈曼、华为、百度、联想、联发科、普瑞均胜、德赛西威、蜂巢转向、均联智行、武汉光庭、星纪魅族、中车集团、潍柴集团、地平线、紫光同芯、字节跳动、……

二级供应商(500+以上)：

中科数测、ETAS、BlackDuck、NXP、上海软件中心、Deloitte、奇安信、为辰信安、云驰未来、信长城、泽鹿安全、纽创信安、复旦微电子、天融信、奇虎360、中汽中心、中国汽研、上海汽检、加特兰微电子、浙江大学……

人员占比

公司类型占比

文章

不要错过哦，这可能是汽车网络安全产业最大的专属社区！

关于涉嫌仿冒AutoSec会议品牌的律师声明

一文带你了解智能汽车车载网络通信安全架构

网络安全：TARA方法、工具与案例

汽车数据安全合规重点分析

浅析汽车芯片信息安全之安全启动

域集中式架构的汽车车载通信安全方案探究

系统安全架构之车辆网络安全架构

车联网中的隐私保护问题

智能网联汽车网络安全技术研究

AUTOSAR 信息安全框架和关键技术分析

AUTOSAR 信息安全机制有哪些？

信息安全的底层机制

汽车网络安全

Autosar硬件安全模块HSM的使用

首发!小米雷军两会上就汽车数据安全问题建言：关于构建完善汽车数据安全管理体系的建议

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：谈思实验室 《如何选择加密模式》