1. AES密码算法到底解决了什么问题

第一次接触AES的人，多半是在某个登录接口、文件加密工具或者数据库字段加密的需求里撞见它的。你搜“aes加密”，跳出来一堆“对称加密”“分组密码”“S盒”“IV初始向量”之类的词，看着都认识，连起来就不知道从哪下手。我当年也是这样，拿着一个java.security.InvalidKeyException: Wrong algorithm: AES or Rijndael required的报错，愣是查了一下午才发现是算法名称字符串写错了。

先把话说清楚：AES全称Advanced Encryption Standard，中文叫高级加密标准，是一种对称分组密码算法。对称的意思是加密和解密用同一把密钥；分组的意思是它一次处理固定长度的数据块，AES的块长固定是128位，也就是16个字节。密钥长度有三种：128位、192位、256位。这三个版本分别叫AES-128、AES-192、AES-256，它们的安全强度不同，但加解密流程的骨架是一样的。

它能做什么？最典型的就是把一段明文变成密文，只有拿着同一把密钥的人才能还原。你平时用的HTTPS连接、手机全盘加密、压缩包密码、数据库敏感字段加密，底层大概率都有AES在干活。它适合谁来学？我的判断是：只要你在做后端开发、移动端开发、运维、安全测试，或者只是想让自己的配置文件里别明文躺着数据库密码，AES都值得你花时间搞明白。它不是什么高不可攀的密码学理论，而是一个你迟早要用的工程工具。

这篇文章我不打算照本宣科讲数学推导，而是按一个实际使用者的视角，把AES的工作模式、IV、填充、密钥管理、常见报错这些真正会卡住你的地方讲透。你看完应该能做到：知道什么场景该选哪种模式，能自己写出一个可用的加解密函数，遇到报错知道往哪个方向排查。

2. AES算法的核心设计与关键参数拆解

2.1 分组密码的基本工作方式

AES处理数据的方式很像流水线：把明文切成一块一块的16字节，每块单独走一遍加密流程。但这里有个问题，如果每块都用同样的方式独立加密，相同的明文块会产生相同的密文块，攻击者一眼就能看出数据的规律。所以实际使用中，AES从来不裸奔，它要配合工作模式一起用。

工作模式决定了多块数据之间怎么关联。常见的有ECB、CBC、CFB、OFB、CTR、GCM这几种。ECB是最简单的，每块独立加密，但也是最不安全的，因为相同明文块加密结果一样，能看出图片轮廓那种经典例子就是ECB搞出来的。CBC引入了IV，让每块加密前先和前一块的密文做异或，这样相同明文也会得到不同密文。GCM则是在CTR基础上加了认证功能，既能加密又能校验数据有没有被篡改。

我个人的经验是：新项目一律优先选GCM，它同时提供机密性和完整性，省得你再单独加HMAC。如果对方系统只支持CBC，那就用CBC，但一定要保证IV是随机的，并且每次加密都换新的IV。

2.2 密钥长度怎么选

AES-128、AES-192、AES-256，选哪个？很多人第一反应是“当然选最长的”。但实际工程里要考虑性能和兼容性。

AES-128的密钥空间是2的128次方，以目前的计算能力，暴力破解是不现实的。AES-256更安全，但加密速度会慢一些，大概慢20%到40%不等，具体看硬件有没有AES指令集加速。如果你的CPU支持AES-NI指令集，那点性能差异基本可以忽略。

我的建议很直接：普通业务用AES-128就够了，合规要求高或者数据生命周期特别长的用AES-256。别在128和256之间纠结太久，真正决定安全性的往往不是密钥长度，而是你的密钥有没有泄露、IV有没有复用、模式选得对不对。

2.3 S盒是什么，为什么它这么重要

S盒是AES里唯一一个非线性变换部件，全称Substitution Box，替换盒。你可以把它理解成一张固定的256字节查找表：输入一个字节，查表输出另一个字节。这个设计的目的就是打乱数据，让输入和输出之间没有简单的线性关系。

为什么S盒关键？因为如果整个算法都是线性的，那攻击者可以用线性代数的方法反推密钥。S盒提供了非线性，让这种攻击变得极其困难。AES的S盒是经过精心设计的，满足一系列密码学性质，比如差分均匀性、非线性度等。你不需要背这张表，但要知道它的存在，因为有些报错和实现细节会跟它有关。

2.4 IV初始向量到底是什么

IV，Initialization Vector，初始向量。这个词在搜“aes加密iv是什么”的时候出现频率极高。简单说，IV就是给加密过程加的一个随机起点，让同样的明文在每次加密时产生不同的密文。

拿CBC模式举例：第一块明文先和IV做异或，然后再走加密流程。第二块明文和第一块的密文异或，以此类推。如果IV固定不变，那相同明文每次加密结果都一样，攻击者就能通过观察密文变化来推断信息。所以IV的核心要求是：随机、不可预测、每次加密都不同。

IV需要保密吗？不需要。IV可以跟密文一起传输，通常就拼接在密文前面。但它必须是随机的，不能用固定值，也不能用可预测的序列。我见过有人图省事把IV写死成全零，这等于把CBC退化成了ECB，安全性大打折扣。

2.5 填充是怎么回事

AES的块长是16字节，但你的明文长度不一定是16的整数倍。比如你要加密“hello”这5个字节，差11个字节才够一块，怎么办？这就需要填充。

最常用的填充方式是PKCS#7（在AES语境下也叫PKCS#5）。规则很简单：缺几个字节就补几个字节，每个填充字节的值等于填充的长度。比如缺11个字节，就补11个0x0B。解密后检查最后一个字节的值，就知道要去掉多少填充。

这里有个坑：如果明文刚好是16字节的整数倍，PKCS#7会额外补一整块16个0x10。这不是bug，是规范要求，否则解密时无法区分末尾的0x10是数据还是填充。很多人自己实现填充逻辑时忘了这一点，导致解密出错。

3. 手把手实现一个可用的AES加解密流程

3.1 选型决策：模式、密钥、IV、填充一次定清楚

在动手写代码之前，先把这几个参数定下来，不然后面改起来很麻烦。我一般按这个顺序决策：

如果你用的是Java，Cipher.getInstance("AES/GCM/NoPadding")就是GCM模式，不需要额外填充。如果是CBC，就写AES/CBC/PKCS5Padding。注意Java里PKCS5Padding和PKCS7Padding在AES场景下是一回事，因为AES块长固定16字节。

3.2 密钥生成与管理的实操要点

密钥不能硬编码在代码里，这是铁律。我见过太多项目把密钥写成字符串常量提交到代码仓库，这跟把钥匙插在门上没区别。

正确的做法是：密钥存在环境变量、配置中心或者密钥管理服务里。生成密钥时要用安全的随机源，不要用Random，要用SecureRandom。下面是一段Java生成AES密钥的代码：

KeyGenerator keyGen = KeyGenerator.getInstance("AES"); keyGen.init(256, new SecureRandom()); SecretKey secretKey = keyGen.generateKey(); byte[] keyBytes = secretKey.getEncoded(); // 把keyBytes用Base64编码后存到安全的地方

如果你需要从密码派生密钥，比如用户输入一个口令，那就用PBKDF2或者Argon2这类密钥派生函数，加盐迭代足够多次。千万别直接拿口令的哈希当AES密钥。

3.3 完整加解密代码示例与逐行说明

下面这段代码用AES/GCM/NoPadding实现加解密，Java环境可直接跑：

import javax.crypto.Cipher; import javax.crypto.SecretKey; import javax.crypto.spec.GCMParameterSpec; import javax.crypto.spec.SecretKeySpec; import java.security.SecureRandom; import java.util.Base64; public class AesGcmDemo { private static final int GCM_IV_LENGTH = 12; private static final int GCM_TAG_LENGTH = 128; public static String encrypt(String plaintext, byte[] key) throws Exception { byte[] iv = new byte[GCM_IV_LENGTH]; new SecureRandom().nextBytes(iv); Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding"); SecretKeySpec keySpec = new SecretKeySpec(key, "AES"); GCMParameterSpec gcmSpec = new GCMParameterSpec(GCM_TAG_LENGTH, iv); cipher.init(Cipher.ENCRYPT_MODE, keySpec, gcmSpec); byte[] ciphertext = cipher.doFinal(plaintext.getBytes("UTF-8")); // IV拼接在密文前面一起返回 byte[] combined = new byte[iv.length + ciphertext.length]; System.arraycopy(iv, 0, combined, 0, iv.length); System.arraycopy(ciphertext, 0, combined, iv.length, ciphertext.length); return Base64.getEncoder().encodeToString(combined); } public static String decrypt(String encryptedBase64, byte[] key) throws Exception { byte[] combined = Base64.getDecoder().decode(encryptedBase64); byte[] iv = new byte[GCM_IV_LENGTH]; System.arraycopy(combined, 0, iv, 0, GCM_IV_LENGTH); byte[] ciphertext = new byte[combined.length - GCM_IV_LENGTH]; System.arraycopy(combined, GCM_IV_LENGTH, ciphertext, 0, ciphertext.length); Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding"); SecretKeySpec keySpec = new SecretKeySpec(key, "AES"); GCMParameterSpec gcmSpec = new GCMParameterSpec(GCM_TAG_LENGTH, iv); cipher.init(Cipher.DECRYPT_MODE, keySpec, gcmSpec); byte[] plaintext = cipher.doFinal(ciphertext); return new String(plaintext, "UTF-8"); } }

几个关键点说明一下。GCM的IV推荐长度是12字节，不是16字节，这是GCM规范的建议，用12字节性能更好。认证标签长度设128位，也就是16字节，这是最常用的值。IV拼接在密文前面是常见做法，解密时先取出前12字节当IV，剩下的就是密文加认证标签。

3.4 CBC模式的实现与IV处理

如果对方系统只支持CBC，代码稍有不同：

Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding"); byte[] iv = new byte[16]; new SecureRandom().nextBytes(iv); IvParameterSpec ivSpec = new IvParameterSpec(iv); cipher.init(Cipher.ENCRYPT_MODE, keySpec, ivSpec);

CBC的IV是16字节，跟块长一致。同样把IV拼在密文前面传输。注意CBC本身不提供完整性校验，如果你需要防篡改，得额外加HMAC，并且要遵循“先加密后MAC”的顺序，否则会有安全漏洞。

4. 常见报错与踩坑排查实录

4.1 Wrong algorithm报错怎么定位

java.security.InvalidKeyException: Wrong algorithm: AES or Rijndael required这个报错我遇到过好几次，原因基本都是一个：你传给SecretKeySpec的算法名称不对。比如你写成了"Aes"或者"AES "带了空格，或者你拿DES的密钥来初始化AES的Cipher。

排查步骤很简单：第一，检查new SecretKeySpec(keyBytes, "AES")里的字符串是不是精确的"AES"，大小写敏感。第二，检查你的密钥长度是不是合法值，AES只接受16、24、32字节的密钥，你给个20字节它也会报类似的错。第三，确认你没有把Base64编码后的字符串直接当密钥字节用，要先解码。

4.2 解密失败与填充错误

javax.crypto.BadPaddingException: Given final block not properly padded这个报错，新手看到就慌。它通常意味着以下几种情况之一：密钥不对、IV不对、密文被截断或篡改、填充方式不匹配。

我的排查顺序是：先确认加密和解密用的是同一把密钥，把密钥的Base64打印出来对比一下。然后确认IV是不是正确传递了，CBC模式下IV错了第一块解密就会乱。再检查密文有没有在传输过程中被URL编码、换行符之类的东西破坏。最后确认两边的填充模式一致，一边PKCS5一边NoPadding肯定不行。

GCM模式下如果密文被篡改，会抛AEADBadTagException，这是认证失败，说明数据完整性被破坏了，不是填充问题。

4.3 IV复用导致的严重问题

IV复用是AES使用中最危险的错误之一。在CBC模式下，如果两次加密用了相同的IV和相同的密钥，那相同明文块会产生相同密文块，攻击者可以据此推断出明文之间的关系。在CTR或GCM模式下，IV复用更致命，直接可能导致密钥流被还原，密文形同虚设。

我见过一个系统为了“性能优化”，把IV缓存起来重复使用，结果被安全审计直接标了高危。记住：每次加密都必须生成新的随机IV，这是没有商量余地的。

4.4 常见问题速查表

4.5 几个容易忽略的实操心得

第一个心得：密文传输时用Base64编码，别直接传字节数组，否则遇到网络传输、JSON序列化很容易出问题。Base64把二进制转成可打印字符，省心很多。

第二个心得：密钥轮换要有预案。你不可能永远用同一把密钥，但换密钥时旧数据还得能解密。常见做法是给密文加一个密钥版本号，解密时根据版本号选对应的密钥。

第三个心得：别自己实现AES。除非你是密码学专业出身，否则用标准库就行。自己实现的S盒查表、密钥扩展、列混合这些环节，很容易引入侧信道漏洞或者逻辑错误。标准库经过大量审查，比你自己写的靠谱得多。

第四个心得：测试向量要留好。NIST提供了一套AES的标准测试向量，你实现完加解密后拿这些向量跑一遍，能快速验证你的实现是否正确。特别是跨语言交互时，Java加密、Python解密这种场景，测试向量能帮你快速定位是哪边出了问题。

5. 对称与非对称加密的配合使用

5.1 对称加密和非对称加密的本质区别

搜“对称加密和非对称加密”的人，多半是在纠结什么时候用哪个。我用一句话概括：对称加密快，但密钥分发难；非对称加密慢，但解决了密钥分发问题。

AES是对称加密，加密和解密同一把密钥。优点是速度快，适合加密大量数据。缺点是你要把密钥安全地传给对方，这个“安全地传”本身就是个难题。

RSA、ECC这些是非对称加密，公钥加密私钥解密，或者私钥签名公钥验签。优点是公钥可以随便公开，不用怕被截获。缺点是速度慢，加密大文件不现实。

5.2 实际系统里怎么配合

实际系统里最常见的做法是混合加密：用非对称加密来保护对称密钥，用对称密钥来加密实际数据。比如TLS握手阶段用非对称加密协商出一个会话密钥，之后的数据传输都用对称加密。

具体到你的项目，如果只是加密数据库里的敏感字段，用AES就够了，密钥存在配置中心。如果要在不可信网络上传输数据，那就先用AES加密数据，再用对方的公钥加密AES密钥，一起发过去。对方收到后先用自己的私钥解出AES密钥，再解密数据。

5.3 公钥私钥的理解误区

很多人把公钥私钥理解成“公钥加密私钥解密”就完了，其实还有“私钥签名公钥验签”这个方向。前者保证机密性，后者保证完整性和不可否认性。这两个方向用的密钥不同，别搞混。

还有一个常见误区是认为非对称加密比对称加密安全。其实安全性取决于密钥长度和算法实现，不是加密类型。AES-256的安全强度跟RSA-3072大致相当，但AES快得多。

6. 密钥管理与工程实践建议

6.1 密钥不能硬编码，那放哪

密钥管理是AES使用中最容易被忽视的环节。代码里不写密钥只是第一步，接下来你要决定密钥存哪。小项目可以用环境变量，部署时注入。中等项目用配置中心，配合权限控制。大项目或者合规要求高的，用专门的密钥管理服务，支持密钥轮换、审计日志、访问控制。

不管用哪种方式，核心原则是：密钥和密文分开存储。密文在数据库里，密钥在另一个系统里，这样即使数据库被拖库，攻击者也拿不到密钥。

6.2 密钥轮换怎么做才不翻车

密钥轮换的难点在于旧数据。你换了新密钥，旧密文还得用旧密钥解密。我的做法是在密文前面加一个字节的密钥版本号，解密时先读版本号，再选对应的密钥。轮换时新数据用新密钥，旧数据保持不动，等业务上不需要了再批量重加密。

重加密是个耗时的操作，建议在低峰期做，并且做好回滚预案。别一次性全量重加密，分批来，每批验证通过再继续。

6.3 性能优化的边界

AES的性能其实不用太担心，现代CPU基本都有AES-NI指令集，加解密速度能到GB/s级别。真正影响性能的往往是IV生成、Base64编码、网络传输这些环节。

如果你确实遇到性能瓶颈，先确认有没有启用硬件加速。Java里默认会尝试用AES-NI，但某些老版本或者特定配置下可能没启用。另外，GCM模式比CBC模式性能更好，因为GCM可以并行处理。

但我要提醒一句：别为了性能牺牲安全性。我见过有人为了省IV生成的随机数开销，把IV固定成时间戳，这等于自废武功。性能优化要在安全底线之上做。

6.4 跨语言交互的注意事项

Java加密、Python解密，或者Go加密、Node.js解密，这种跨语言场景很容易出问题。核心检查点有三个：密钥字节是否一致、IV是否一致、填充方式是否一致。

我的经验是，先用同一套测试向量在两边分别跑，确认各自的加解密自洽，然后再做交叉测试。如果交叉测试失败，大概率是编码问题，比如Java的getBytes()默认编码跟Python的不一样，统一指定UTF-8能解决大部分问题。

另外，不同语言对GCM的IV长度默认值可能不同，Java默认12字节，有些库默认16字节，这个要显式指定，别依赖默认值。

6.5 安全审计中常见的AES问题清单

如果你在做安全审计或者代码review，下面这几个问题值得重点看：

• 有没有用ECB模式
• IV是不是固定的或者可预测的
• 密钥有没有硬编码
• 有没有用不安全的随机数生成器
• 填充方式是否一致
• 有没有做完整性校验
• 密钥长度是否达标
• 有没有密钥轮换机制

这份清单基本覆盖了AES使用中最常见的安全问题，逐条过一遍能排除大部分隐患。

7. 从AES延伸出去的知识点

7.1 国密算法SM1、SM2、SM3的定位

搜AES的人有时候也会看到SM1、SM2、SM3这些词。简单说一下它们的定位：SM1是对称加密算法，硬件实现，128位密钥，参数不公开。SM2是非对称算法，256位，用于签名、加密和密钥交换。SM3是杂凑算法，输出256位，类似SHA-256。

如果你在做国内合规项目，可能会被要求用国密算法替代AES。这时候要注意，SM1是硬件实现的，软件层面通常用SM4替代。SM4也是分组密码，块长128位，密钥128位，用法跟AES类似，但S盒和密钥扩展不同。

7.2 AES登录场景的典型实现

“aes登录”这个搜索词背后，通常是前端加密密码再传输的需求。做法是前端用AES加密用户密码，后端解密后验证。但这里有个问题：前端加密的密钥怎么给前端？如果密钥写在前端代码里，等于没有加密。

我的建议是：登录场景优先用HTTPS，传输层已经加密了，没必要再在应用层套一层AES。如果确实需要额外加密，那密钥不能硬编码在前端，应该由后端动态下发，并且配合时间戳和随机数防重放。

7.3 后续可以深入的方向

AES本身搞明白之后，你可以往这几个方向延伸：一是密码学基础，理解分组密码的设计原理和攻击模型；二是密钥管理基础设施，学习HSM、KMS这些工具的使用；三是协议层，看TLS、SSH这些协议怎么用AES；四是国密算法，了解SM4、SM2、SM3的实现和迁移方案。

我个人在实际操作中的体会是，AES的难点从来不在算法本身，而在工程实践中的参数选择、密钥管理和错误处理。把这几块搞扎实，比背S盒的构造原理有用得多。最后再分享一个小技巧：每次写完加解密代码，先拿NIST的测试向量跑一遍，再拿自己的业务数据跑一遍，两遍都过了再上线，能省掉很多半夜排查问题的麻烦。