AES加密算法原理详解与Python/Node.js实战实现指南

1. 项目概述：为什么AES是绕不开的加密基石

在数字世界里，数据安全就像空气和水，平时感觉不到，一旦出问题就是灾难。无论是你手机里的一张照片，还是银行App里的一次转账，背后都离不开加密算法的默默守护。而在众多加密算法中，AES（高级加密标准）无疑是当今应用最广泛、最受信赖的对称加密算法，没有之一。它早已渗透到我们数字生活的方方面面，从Wi-Fi密码（WPA2/WPA3）到HTTPS协议（TLS），从文件加密到数据库存储，AES的身影无处不在。

我之所以想深入聊聊AES的原理与实现，是因为发现很多开发者对它存在一种“熟悉的陌生感”。大家可能每天都在用各种库调用AES.encrypt()，但对它内部到底如何运转、为什么选择特定的模式、密钥长度背后的考量却知之甚少。这种“黑盒”使用方式，在遇到诸如“加密后的数据为什么每次都不一样？”、“该选CBC还是GCM模式？”、“IV（初始化向量）到底该怎么管理？”这类实际问题时，往往会让人束手无策。理解原理，不是为了造轮子，而是为了在关键时刻能做出正确的选择，写出更安全、更健壮的代码。接下来，我将结合在Python和Node.js环境下的实战，带你穿透API的封装，直抵AES的核心。

2. AES加密算法核心原理深度拆解

2.1 从DES到AES：对称加密的演进之路

要理解AES，得先看看它取代的前任——DES（数据加密标准）。DES诞生于1970年代，其56位的密钥长度在当时的计算能力下是安全的，但随着硬件性能的指数级增长，暴力破解56位密钥逐渐成为可能。为此，出现了3DES（三重DES），通过三次加密来增强安全性，但代价是效率低下。于是，在1997年，美国国家标准与技术研究院（NIST）发起了一场全球性的竞赛，旨在寻找DES的替代者。经过多轮严苛的密码学分析，由两位比利时密码学家Joan Daemen和Vincent Rijmen设计的Rijndael算法最终胜出，并在2001年被正式确立为AES标准。

AES之所以胜出，关键在于它在安全性、性能和实现灵活性之间取得了绝佳的平衡。它不像RSA那样依赖大数分解的数学难题，而是基于“代换-置换网络”（Substitution-Permutation Network, SPN）结构，这种结构清晰、规整，非常利于软件优化和硬件实现。你可以把它想象成一个设计精妙的流水线工厂：数据（明文）被切分成固定大小的块，进入流水线，经历多轮（Round）的标准化处理，每一轮都包含几个特定的“工序”（字节代换、行移位、列混合、轮密钥加），最终产出成品（密文）。这个过程的可逆性，则构成了解密流程。

2.2 AES算法的核心操作步骤详解

AES处理的数据块固定为128位（16字节），密钥长度则可以是128位、192位或256位，分别对应AES-128， AES-192， AES-256。密钥越长，安全性理论上越高，但加解密运算量也会相应增加。大多数常规场景，AES-128已足够安全；对安全性要求极高的场景（如国家机密信息），则会考虑AES-256。

一轮完整的AES加密包含以下四个步骤，这些步骤在多轮中循环执行：

1. 字节代换（SubBytes）：这是AES中唯一的非线性变换，是安全性的重要来源。它通过一个预先计算好的S盒（Substitution-box）进行查表操作，将状态矩阵中的每一个字节替换成另一个字节。这个S盒的设计非常精妙，能提供良好的混淆特性，使得明文和密文之间的关系变得极其复杂。在实现上，我们通常直接使用一个256字节的查找表，效率极高。

2. 行移位（ShiftRows）：这是一个线性变换，目的是提供扩散性。它将状态矩阵的每一行进行循环左移，第0行不移位，第1行左移1个字节，第2行左移2个字节，第3行左移3个字节。这个操作打破了列与列之间的独立性，让一个字节的变化能更快地扩散到整个状态矩阵。

3. 列混合（MixColumns）：这是另一个提供强扩散性的线性变换。它对状态矩阵的每一列进行独立的矩阵乘法运算（在伽罗瓦域GF(2^8)上）。这个操作让单个字节的变化在一步内就能影响到该列的四个字节。需要注意的是，在最后一轮加密中，会省略列混合步骤。

4. 轮密钥加（AddRoundKey）：这是最简单的一步，将当前的状态矩阵与当前轮的轮密钥进行逐比特的异或（XOR）操作。轮密钥是从初始的主密钥通过密钥扩展算法派生出来的一系列子密钥。这一步将密钥直接混入数据中。

加密开始时，会先进行一次初始的轮密钥加（AddRoundKey）。然后，对于AES-128，会执行9轮完整的上述四步操作（第1-9轮），最后第10轮则只执行SubBytes， ShiftRows和AddRoundKey（省略MixColumns）。解密过程则是加密过程的逆序，使用逆变换和逆序的轮密钥。

注意：对于绝大多数应用开发者而言，我们不需要手动实现这些底层变换。现代编程语言和操作系统都提供了经过高度优化（甚至使用CPU指令集加速）的AES实现。理解原理的意义在于，当我们需要选择加密模式、处理填充、或管理密钥和IV时，能做出明智的决策。

2.3 密钥扩展：从一把钥匙到一串钥匙

AES加密的每一轮都需要一个不同的轮密钥。密钥扩展算法的作用，就是将用户输入的初始密钥（128/192/256位）扩展成一系列用于各轮加密的轮密钥。这个过程也是可逆的，用于在解密时生成相同的轮密钥序列。

扩展算法同样基于一些变换，包括字循环、字节代换（使用S盒）和与轮常数异或。它的设计确保了密钥的每一位都影响了多个轮密钥，提供了更好的密钥雪崩效应。在代码实现中，我们通常调用库函数来完成密钥扩展，但了解其过程有助于理解为什么AES的密钥管理如此重要——初始密钥的丝毫差异，都会导致生成完全不同的轮密钥序列，从而得到截然不同的密文。

3. 加密模式与填充：让AES适应真实世界

原始的AES算法（称为ECB模式）有一个致命缺陷：相同的明文块会被加密成相同的密文块。这对于一张包含大面积纯色区域的图片来说，加密后依然能看出轮廓，安全性大打折扣。因此，在实际应用中，我们必须使用更安全的加密模式。

3.1 主流加密模式对比与选型指南

1. ECB（电子密码本）模式：最基本的方式，每个数据块独立加密。绝对不推荐用于加密任何有意义的数据，因为它无法隐藏数据模式。仅适用于加密随机数据，如加密一个密钥本身。

2. CBC（密码分组链接）模式：这是过去最常用的模式之一。它在加密当前明文块之前，先与前一个密文块进行异或操作。对于第一个块，则需要一个**初始化向量（IV）**来替代“前一个密文块”。IV不需要保密，但必须是随机的、不可预测的，且每次加密都应更换。CBC模式能提供良好的保密性，但它是串行处理的，不利于并行计算，且对错误传播敏感（一个密文块出错，会影响后续所有块的解密）。

3. CTR（计数器）模式：它将一个计数器（每次加密递增）用AES加密，然后将结果与明文进行异或得到密文。这实际上是将AES转换成了一个流密码。CTR模式的优点非常突出：支持并行加密和解密、不需要填充（因为它是流模式）、错误传播有限（一个密文位出错，只影响明文的对应位）。它的IV在这里通常被称为Nonce（一次性数字），需要确保同一密钥下永不重复。

4. GCM（伽罗瓦/计数器模式）：这是目前最推荐用于新项目的模式。它在CTR模式的基础上，增加了GMAC消息认证码，同时提供了**加密和认证（Authenticated Encryption）**功能。这意味着它不仅能防止窃听，还能检测密文是否被篡改。GCM效率高，支持并行，同样不需要填充。在TLS 1.2和1.3中，GCM是核心的加密套件之一。

选择模式的简单原则：

• 通用数据加密，且需要认证：首选GCM。
• 需要并行加密或解密，且场景简单：可选CTR。
• 兼容旧系统或特定协议要求：可能使用CBC，但务必妥善管理IV。
• 任何时候都不要使用 ECB来加密有模式的数据。

3.2 填充方案的必要性与实现

对于CBC等需要处理固定大小分组的模式，当明文长度不是16字节的整数倍时，就需要进行填充（Padding）。常见的填充方案有PKCS#7（也叫PKCS#5）。它的规则很简单：如果需要填充N个字节，那么每个填充字节的值都是N。例如，如果最后一个块差3个字节，就填充0x03 0x03 0x03。解密时，读取最后一个字节的值，就知道需要移除多少填充字节。

这里有一个关键陷阱：如果明文恰好是分组长度的整数倍，是否需要填充？答案是：需要。在这种情况下，需要额外填充一个完整的分组（16个字节，每个字节值为0x10），以便解密程序能正确识别并移除填充。很多加密库（如Python的cryptography）会自动处理这一点，但如果你自己实现，必须注意。

而像CTR、GCM这类流模式，因为是将密钥流与明文按位异或，所以天然支持任意长度的数据，无需填充。

4. Python环境下的AES实战实现

4.1 环境准备与库的选择

Python中进行AES加密，主流且推荐的选择是cryptography库。它由PyCA组织维护，背后是专业的密码学专家，API设计清晰，默认使用安全的最佳实践，能有效避免很多新手陷阱。相比于古老的pycryptodome，cryptography更现代，与OpenSSL集成更好。

首先安装它：

pip install cryptography

4.2 使用cryptography库实现AES-GCM加密

下面我们实现一个完整的、生产环境可参考的AES-GCM加密解密示例。GCM模式需要提供一个nonce（类似IV），加密后会生成一个认证标签（tag），解密时需要同时提供密文、nonce和tag进行验证。

from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes from cryptography.hazmat.primitives import padding from cryptography.hazmat.backends import default_backend import os def aes_gcm_encrypt(key: bytes, plaintext: bytes, associated_data: bytes = None) -> tuple: """ 使用AES-GCM模式加密数据。 参数: key: 密钥，必须是16(AES-128), 24(AES-192)或32(AES-256)字节。 plaintext: 需要加密的明文。 associated_data: 关联数据（可选），用于认证但不加密。 返回: (nonce, ciphertext, tag) 三元组。 """ # 生成一个随机的12字节nonce（推荐长度） nonce = os.urandom(12) # 构建Cipher对象 cipher = Cipher(algorithms.AES(key), modes.GCM(nonce), backend=default_backend()) encryptor = cipher.encryptor() # 如果有关联数据，先更新它（用于认证） if associated_data: encryptor.authenticate_additional_data(associated_data) # 加密数据 ciphertext = encryptor.update(plaintext) + encryptor.finalize() # 获取认证标签 tag = encryptor.tag return nonce, ciphertext, tag def aes_gcm_decrypt(key: bytes, nonce: bytes, ciphertext: bytes, tag: bytes, associated_data: bytes = None) -> bytes: """ 使用AES-GCM模式解密数据。 参数: key: 密钥，与加密时相同。 nonce: 加密时使用的nonce。 ciphertext: 密文。 tag: 加密生成的认证标签。 associated_data: 加密时使用的关联数据（如果有）。 返回: 解密后的明文。 抛出异常: InvalidTag: 如果认证失败（数据被篡改或密钥错误）。 """ cipher = Cipher(algorithms.AES(key), modes.GCM(nonce, tag), backend=default_backend()) decryptor = cipher.decryptor() # 如果有关联数据，先更新它（必须与加密时一致） if associated_data: decryptor.authenticate_additional_data(associated_data) # 解密数据 plaintext = decryptor.update(ciphertext) + decryptor.finalize() return plaintext # 示例用法 if __name__ == "__main__": # 生成一个256位的随机密钥（32字节） key = os.urandom(32) secret_message = b"This is a top secret message that needs AES-GCM encryption." print(f"原始明文: {secret_message}") # 加密 nonce, ciphertext, tag = aes_gcm_encrypt(key, secret_message, b"metadata_v1") print(f"Nonce (hex): {nonce.hex()}") print(f"密文 (hex): {ciphertext.hex()}") print(f"Tag (hex): {tag.hex()}") # 解密 try: decrypted = aes_gcm_decrypt(key, nonce, ciphertext, tag, b"metadata_v1") print(f"解密成功: {decrypted}") assert decrypted == secret_message except Exception as e: print(f"解密失败或认证错误: {e}") # 模拟篡改攻击：修改一个字节的密文 tampered_ciphertext = bytearray(ciphertext) tampered_ciphertext[0] ^= 0x01 try: decrypted = aes_gcm_decrypt(key, nonce, bytes(tampered_ciphertext), tag, b"metadata_v1") except Exception as e: print(f"密文被篡改，认证失败（符合预期）: {type(e).__name__}")

关键点解析与实操心得：

1. 密钥管理：示例中密钥是随机生成的。在实际系统中，密钥必须安全存储，例如使用密钥管理服务（KMS）、硬件安全模块（HSM），或从用户密码通过密钥派生函数（如Argon2）派生。绝对不要将硬编码的密钥放在源代码或配置文件中。
2. Nonce管理：GCM的nonce必须是唯一的。对于给定的密钥，重复使用nonce会彻底破坏GCM的安全性。使用密码学安全的随机数生成器（如os.urandom）生成足够长的nonce（12字节是标准推荐），可以极大概率保证唯一性。
3. 关联数据（AAD）：这是一个非常实用的功能。你可以将一些不需要加密但需要确保完整性的数据（如数据包头部、协议版本号）通过authenticate_additional_data传入。解密时，如果这些数据被篡改，认证也会失败。这比先加密再计算HMAC要方便和高效。
4. 错误处理：解密失败会抛出InvalidTag异常。你必须捕获并妥善处理这个异常，绝不能简单地忽略。认证失败意味着数据不可信，应该记录安全日志并拒绝请求。

4.3 实现AES-CBC模式作为对比

虽然GCM是首选，但理解CBC的实现仍有价值，特别是在维护旧系统时。

def aes_cbc_encrypt(key: bytes, plaintext: bytes) -> tuple: """使用AES-CBC模式加密数据（含PKCS7填充）。""" # 生成随机IV（16字节） iv = os.urandom(16) # 创建填充器 padder = padding.PKCS7(algorithms.AES.block_size).padder() padded_data = padder.update(plaintext) + padder.finalize() # 加密 cipher = Cipher(algorithms.AES(key), modes.CBC(iv), backend=default_backend()) encryptor = cipher.encryptor() ciphertext = encryptor.update(padded_data) + encryptor.finalize() return iv, ciphertext def aes_cbc_decrypt(key: bytes, iv: bytes, ciphertext: bytes) -> bytes: """使用AES-CBC模式解密数据（含PKCS7去填充）。""" cipher = Cipher(algorithms.AES(key), modes.CBC(iv), backend=default_backend()) decryptor = cipher.decryptor() padded_plaintext = decryptor.update(ciphertext) + decryptor.finalize() # 去除填充 unpadder = padding.PKCS7(algorithms.AES.block_size).unpadder() plaintext = unpadder.update(padded_plaintext) + unpadder.finalize() return plaintext # 示例用法 key = os.urandom(32) # AES-256 message = b"Hello, this is a CBC mode example." iv, ciphertext = aes_cbc_encrypt(key, message) decrypted = aes_cbc_decrypt(key, iv, ciphertext) print(f"CBC解密结果: {decrypted}")

CBC模式注意事项：

1. IV必须是随机的：每次加密都必须使用新的、密码学安全的随机IV。使用固定IV或序列IV会严重削弱安全性。
2. 填充预言攻击：CBC模式在历史上曾遭受填充预言攻击（如POODLE攻击）。虽然现代库的实现通常有缓解措施，但这仍是CBC的一个理论弱点。确保使用TLS等上层协议的最新安全版本，或在应用层使用认证加密（如先用CBC加密，再用HMAC认证）。
3. 库自动处理填充：cryptography库的PKCS7填充器帮我们自动处理了填充和去填充，包括“完整块填充”的情况，这避免了手动实现的错误。

5. Node.js环境下的AES实战实现

5.1 使用Node.js内置的crypto模块

Node.js的crypto模块是内置的，功能强大且无需额外安装。它提供了底层的createCipheriv和createDecipheriv函数，以及更现代的createCipheriv和createDecipheriv（注意：Node.js早期版本不安全的createCipher/createDecipher已被废弃，切勿使用）。

5.2 实现AES-GCM加密解密

const crypto = require('crypto'); /** * 使用AES-GCM加密 * @param {Buffer|string} plaintext - 明文 * @param {Buffer} key - 密钥 (16, 24, 或 32 字节) * @param {Buffer|string} [aad] - 附加认证数据（可选） * @returns {Object} 包含nonce, ciphertext, tag的对象 */ function aesGcmEncrypt(plaintext, key, aad = null) { // 将字符串输入转换为Buffer if (typeof plaintext === 'string') plaintext = Buffer.from(plaintext, 'utf8'); if (aad && typeof aad === 'string') aad = Buffer.from(aad, 'utf8'); // 生成12字节的随机nonce const nonce = crypto.randomBytes(12); // 创建cipher对象，指定算法为'aes-256-gcm'（根据密钥长度变化） const cipher = crypto.createCipheriv(`aes-${key.length * 8}-gcm`, key, nonce); // 设置附加认证数据 if (aad) { cipher.setAAD(aad); } // 加密 let ciphertext = cipher.update(plaintext); ciphertext = Buffer.concat([ciphertext, cipher.final()]); // 获取认证标签（默认为16字节） const tag = cipher.getAuthTag(); return { nonce, ciphertext, tag }; } /** * 使用AES-GCM解密 * @param {Buffer} ciphertext - 密文 * @param {Buffer} key - 密钥 * @param {Buffer} nonce - Nonce * @param {Buffer} tag - 认证标签 * @param {Buffer|string} [aad] - 附加认证数据（可选） * @returns {Buffer} 解密后的明文 * @throws 如果认证失败 */ function aesGcmDecrypt(ciphertext, key, nonce, tag, aad = null) { if (aad && typeof aad === 'string') aad = Buffer.from(aad, 'utf8'); const decipher = crypto.createDecipheriv(`aes-${key.length * 8}-gcm`, key, nonce); decipher.setAuthTag(tag); if (aad) { decipher.setAAD(aad); } let plaintext = decipher.update(ciphertext); plaintext = Buffer.concat([plaintext, decipher.final()]); // final()会验证tag，失败则抛出错误 return plaintext; } // 示例用法 const key = crypto.randomBytes(32); // AES-256 const message = "Sensitive data from Node.js"; const aad = "protocol_version_1.0"; console.log(`原始明文: ${message}`); // 加密 const { nonce, ciphertext, tag } = aesGcmEncrypt(message, key, aad); console.log(`Nonce (hex): ${nonce.toString('hex')}`); console.log(`密文 (hex): ${ciphertext.toString('hex')}`); console.log(`Tag (hex): ${tag.toString('hex')}`); // 解密 try { const decrypted = aesGcmDecrypt(ciphertext, key, nonce, tag, aad); console.log(`解密成功: ${decrypted.toString('utf8')}`); } catch (err) { console.error(`解密失败（认证错误）: ${err.message}`); } // 测试篡改 const tamperedCiphertext = Buffer.from(ciphertext); tamperedCiphertext[0] ^= 1; // 修改第一个字节 try { aesGcmDecrypt(tamperedCiphertext, key, nonce, tag, aad); } catch (err) { console.log(`密文被篡改，认证失败（符合预期）: ${err.message}`); }

Node.js实现要点：

1. 算法字符串：createCipheriv的第一个参数是算法字符串，格式为aes-<密钥长度>-<模式>，例如aes-256-gcm，aes-128-cbc。密钥长度是根据你传入的key的字节数自动判断的，但字符串必须匹配，否则会报错。
2. 认证标签：GCM模式必须调用cipher.getAuthTag()获取标签，并在解密时通过decipher.setAuthTag(tag)设置。decipher.final()方法会验证标签，失败则抛出错误。
3. Buffer操作：Node.js的crypto模块主要处理Buffer类型。注意字符串和Buffer之间的转换，确保编码一致（通常使用utf8）。

5.3 实现AES-CBC模式

const crypto = require('crypto'); function aesCbcEncrypt(plaintext, key) { if (typeof plaintext === 'string') plaintext = Buffer.from(plaintext, 'utf8'); const iv = crypto.randomBytes(16); const cipher = crypto.createCipheriv(`aes-${key.length * 8}-cbc`, key, iv); // 对于CBC，update和final的结果需要拼接 let ciphertext = cipher.update(plaintext); ciphertext = Buffer.concat([ciphertext, cipher.final()]); return { iv, ciphertext }; } function aesCbcDecrypt(ciphertext, key, iv) { const decipher = crypto.createDecipheriv(`aes-${key.length * 8}-cbc`, key, iv); let plaintext = decipher.update(ciphertext); plaintext = Buffer.concat([plaintext, decipher.final()]); return plaintext; } // 使用示例 const key = crypto.randomBytes(32); const message = "Data encrypted with CBC"; console.log(`CBC原始明文: ${message}`); const { iv, ciphertext } = aesCbcEncrypt(message, key); console.log(`CBC IV: ${iv.toString('hex')}`); const decrypted = aesCbcDecrypt(ciphertext, key, iv); console.log(`CBC解密结果: ${decrypted.toString('utf8')}`);

重要提示：Node.js的crypto模块在CBC模式下默认使用PKCS7填充（它称之为PKCS5），并且会自动处理。你不需要手动进行填充操作，这简化了代码，但你必须知道它正在发生。

6. 密钥管理、性能与最佳实践

6.1 密钥的生命周期管理

谈论加密而不谈密钥管理，就像建了最坚固的保险箱却把钥匙放在门口的地垫下。以下是一些核心原则：

1. 生成：必须使用密码学安全的随机数生成器（CSPRNG）生成密钥。Python的os.urandom()和Node.js的crypto.randomBytes()都是安全的。
2. 存储：
   • 绝对避免硬编码：永远不要将密钥写在源代码或配置文件中然后提交到代码仓库。
   • 使用环境变量或密钥管理服务：在生产环境中，通过环境变量（如process.env.ENCRYPTION_KEY）或专业的KMS（如AWS KMS, Google Cloud KMS, HashiCorp Vault）来注入密钥。
   • 加密存储：如果必须将密钥保存在磁盘上，应使用一个主密钥或基于密码的加密来保护它。
3. 轮换：定期更换加密密钥是一种良好的安全习惯。这意味着你需要一个系统来管理密钥版本，并使用新的密钥加密新数据。旧密钥仍需保留一段时间，用于解密历史数据。
4. 销毁：当密钥不再需要时，应安全地将其从内存和存储中清除（例如，在Python中覆盖包含密钥的字节数组）。

6.2 性能考量与优化建议

AES算法本身非常高效，尤其是在现代CPU普遍具备AES-NI指令集加速的情况下。性能瓶颈往往出现在模式选择和数据流处理上。

• 模式选择影响：GCM和CTR模式支持并行计算，在现代多核系统上性能优于串行的CBC模式。GCM虽然多了GMAC计算，但其并行性通常能带来更好的整体吞吐量。
• 避免小数据频繁加密：对于大量的小数据包，每次加密的初始化开销（如生成IV/Nonce）会变得显著。考虑将数据组合成更大的块进行加密，或使用连接池化的加密上下文（如果库支持）。
• 流式处理：对于大文件，不要一次性读入内存再加密。应使用流式接口（update方法），分块读取、加密、写入。
  • Python示例（文件加密）：

    from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes def encrypt_file(input_path, output_path, key): iv = os.urandom(16) cipher = Cipher(algorithms.AES(key), modes.CBC(iv), backend=default_backend()) encryptor = cipher.encryptor() with open(input_path, 'rb') as fin, open(output_path, 'wb') as fout: fout.write(iv) # 将IV写入文件头部 while chunk := fin.read(64 * 1024): # 64KB chunks encrypted_chunk = encryptor.update(chunk) fout.write(encrypted_chunk) fout.write(encryptor.finalize()) # 处理最后的填充块

• 硬件加速：确保你的运行环境支持AES-NI。在Linux上可以通过cat /proc/cpuinfo | grep aes检查。cryptography和Node.jscrypto默认都会利用该指令集。

6.3 常见陷阱与安全审计清单

在实际开发和代码审查中，请务必对照以下清单检查你的AES实现：

7. 进阶话题与场景化探讨

7.1 如何与RSA等非对称加密结合使用？

AES是对称加密，速度快，适合加密大量数据。RSA是非对称加密，速度慢，但能解决密钥分发问题。常见的混合加密系统结合了两者的优点：

1. 发送方随机生成一个一次性的AES会话密钥（比如256位）。
2. 发送方使用接收方的RSA公钥加密这个AES会话密钥。
3. 发送方使用这个AES会话密钥，通过GCM模式加密实际的消息。
4. 发送方将加密后的AES密钥和加密后的消息（连同nonce和tag）一起发送给接收方。
5. 接收方用自己的RSA私钥解密出AES会话密钥。
6. 接收方用AES会话密钥解密消息。

这样，既利用了RSA的非对称特性安全传输密钥，又利用了AES的高效来加密主体数据。TLS/SSL协议的核心思想正是如此。

7.2 在数据库字段加密中的应用

对数据库中的敏感字段（如身份证号、手机号）进行应用层加密时，AES是常见选择。需要注意：

• 模式选择：通常使用CBC或GCM。如果字段需要被索引或进行等值查询，这是一个难题，因为相同的明文必须加密成相同的密文（确定性加密），但这会泄露信息。一种折衷方案是使用“保序加密”或“可搜索加密”等特殊技术，但它们更复杂且有局限性。更常见的做法是只对存储加密，查询时先解密再过滤（性能有影响），或使用数据库自身的透明数据加密（TDE）功能。
• 密钥管理：数据库加密的密钥必须与数据库本身分开存储，由应用层管理。如果数据库备份被窃，没有密钥也无法解密数据。
• IV存储：IV需要和密文一起存储。通常将IV预置在密文字段的前面。

7.3 调试与问题排查实录

问题1：在Node.js中解密时报错“Error: Unsupported state or unable to authenticate data”。

• 可能原因1：GCM模式解密时，认证标签（tag）设置不正确或缺失。确保你从加密端获取了tag，并在解密时通过decipher.setAuthTag(tag)正确设置。
• 可能原因2：加密和解密使用的密钥、nonce或AAD不一致。仔细检查这些参数在两端是否完全一致（字节对字节）。
• 可能原因3：密文在传输或存储过程中被损坏。检查数据传输和存储的完整性。

问题2：Python解密时抛出“ValueError: Invalid padding bytes.”或“InvalidTag”异常。

• 对于CBC模式（Invalid padding）：通常是密钥、IV错误，或者密文被篡改。错误的密钥/IV会导致解密出的最后一个块的填充值不合理，从而在去填充时失败。
• 对于GCM模式（InvalidTag）：绝对是认证失败。原因同上，密钥、nonce、AAD不一致，或密文/tag被篡改。

排查步骤：

1. 隔离测试：编写一个最小的、独立的加密解密单元测试，使用固定的密钥和IV，确保基础功能正常。
2. 十六进制打印：在加密后和解密前，将密钥、IV/Nonce、密文、Tag等关键数据以十六进制形式打印出来，对比两端是否完全一致。一个字节的差异都会导致失败。
3. 检查编码：确保没有在字符串和字节之间转换时引入编码错误（如多余的BOM头）。在Python中坚持使用bytes类型进行操作，在Node.js中使用Buffer。
4. 版本兼容性：确保加密方和解密方使用的库版本、算法名称、默认参数（如标签长度）是兼容的。

理解AES的原理和最佳实践，能让你在纷繁复杂的加密需求面前保持清醒，选择合适的技术方案，并避开那些隐藏的深坑。安全无小事，加密的正确实现是守护数据的第一道，也是最重要的一道防线。