基础知识：对称加密与非对称加密的基本原理、常见算法及适用场景

在Model Encryption密钥管理体系中，加密算法是整个安全架构的基石。密钥管理策略的制定、密钥生命周期的规划以及密钥使用方式的决策，都直接取决于对加密算法本质特性的理解。本章将系统梳理对称加密与非对称加密的核心原理、主流算法（AES、RSA、ECC）的技术特征，并结合实际工程场景剖析其适用边界。理解这些基础概念，是后续设计密钥轮换策略、混合加密方案以及硬件安全模块（HSM）集成方案的前提。

2.1 对称加密：原理与工程特征

核心原理

对称加密使用同一个密钥完成数据的加密和解密操作。发送方使用密钥K将明文M转换为密文C，接收方使用相同的密钥K将密文C还原为明文M。其安全性完全依赖于密钥K的保密性，一旦密钥泄露，整个加密体系即告失效。在数学表达上，对称加密可表示为：C = E(K, M)，M = D(K, C)，其中E为加密函数，D为解密函数。

对称加密的核心优势在于计算效率极高。现代CPU普遍内置AES指令集（如AES-NI），使得硬件加速下的加解密吞吐量可达数GB/s级别。这一特性使对称加密成为大数据量加密场景的唯一现实选择。然而，对称加密也面临一个经典难题——密钥分发问题：在分布式系统中，如何安全地将密钥传递给通信双方，本身就需要一个安全的信道，这就形成了"先有鸡还是先有蛋"的循环困境。

常见算法：AES（高级加密标准）

AES是目前全球应用最广泛的对称加密算法，由美国国家标准与技术研究院（NIST）于2001年发布，取代了早期的DES算法。AES支持128位、192位和256位三种密钥长度，分别对应10轮、12轮和14轮加密变换。其内部采用SubBytes（字节代换）、ShiftRows（行移位）、MixColumns（列混合）和AddRoundKey（轮密钥加）四种操作，在硬件和软件上均有极高的实现效率。

适用场景与判断方法

对称加密适用于以下典型场景：

• 批量数据加密：数据库表空间加密、文件系统加密（如LUKS）、对象存储加密。
• 传输层数据保护：TLS记录协议中实际传输数据的加密。
• 本地存储加密：笔记本电脑全盘加密、移动设备数据保护。
• 高速实时加密：视频流加密、实时通信加密。

判断是否选用对称加密，可遵循以下流程：

1. 评估数据量：若单次加密数据量超过1KB，优先考虑对称加密。
2. 评估性能要求：若加解密延迟要求低于毫秒级，对称加密是唯一选择。
3. 评估密钥分发条件：若通信双方已通过其他安全方式共享了密钥，则对称加密完全适用。
4. 评估合规要求：部分行业标准（如PCI-DSS）明确要求使用AES-256。

常见误区

2.2 非对称加密：原理与工程特征

核心原理

非对称加密使用一对数学关联但不可互推的密钥：公钥（Public Key）和私钥（Private Key）。公钥可以公开分发，用于加密数据或验证签名；私钥必须严格保密，用于解密数据或生成签名。其数学基础通常是单向陷门函数——正向计算容易，反向求解在计算上不可行。例如RSA基于大整数分解难题，ECC基于椭圆曲线离散对数难题。

非对称加密解决了对称加密的密钥分发问题：接收方只需公开自己的公钥，任何发送方都可以使用该公钥加密数据，而只有持有对应私钥的接收方才能解密。这一特性使其成为密钥交换、数字签名和身份认证的基础设施。

常见算法：RSA与ECC

RSA算法由Rivest、Shamir和Adleman于1977年提出，是最经典的非对称加密算法。RSA的安全性基于大整数因子分解的困难性。其密钥生成过程为：选择两个大素数p和q，计算n=p×q，选取公钥指数e（通常为65537），计算私钥指数d满足e×d ≡ 1 mod φ(n)。RSA的密钥长度通常为2048位或3072位，对应安全强度约为112位和128位。

ECC算法（椭圆曲线密码学）由Miller和Koblitz于1985年独立提出。ECC的安全性基于椭圆曲线离散对数问题（ECDLP）。在相同安全强度下，ECC的密钥长度远短于RSA：256位ECC提供约128位安全强度，而RSA需要3072位才能达到同等水平。ECC的数学运算更为复杂，但密钥短、计算量小、存储空间省，特别适合资源受限的物联网设备和移动终端。

适用场景与判断方法

非对称加密适用于以下场景：

• 密钥交换：如TLS握手阶段的密钥协商，使用ECDHE或RSA密钥交换。
• 数字签名：代码签名、文档签名、区块链交易签名。
• 身份认证：SSH登录认证、TLS客户端证书认证。
• 数字信封：先用非对称加密对称密钥，再用对称密钥加密实际数据。

选择RSA还是ECC，可参考以下判断路径：

1. 若系统需要兼容旧有基础设施（如传统CA证书），选择RSA。
2. 若系统面向新建设计且对性能、存储有要求，优先选择ECC。
3. 若涉及硬件安全模块（HSM）或智能卡，需确认硬件对ECC的支持程度。
4. 若需满足特定合规标准（如GM/T 0003-2012），需遵循标准指定的算法。

常见误区

2.3 混合加密：工程实践中的最优解

核心原理

混合加密（Hybrid Encryption）结合了对称加密的高效性和非对称加密的密钥管理优势。其基本流程为：发送方首先生成一个随机的对称密钥（会话密钥），使用该密钥加密实际数据；然后使用接收方的公钥加密这个会话密钥；接收方收到密文后，先用私钥解密得到会话密钥，再用会话密钥解密数据。这种方案在TLS/SSL、HTTPS、PGP等协议中被广泛采用。

操作流程

发送方：
1. 生成随机会话密钥 K_s（如AES-256密钥）
2. 使用 K_s 加密明文 M → 密文 C = AES_Encrypt(K_s, M)
3. 使用接收方公钥 PK_r 加密 K_s → 加密密钥 EK = RSA_Encrypt(PK_r, K_s)
4. 发送 (C, EK) 给接收方

接收方：
1. 使用私钥 SK_r 解密 EK → 得到 K_s = RSA_Decrypt(SK_r, EK)
2. 使用 K_s 解密密文 C → 得到明文 M = AES_Decrypt(K_s, C)

案例拆解：TLS 1.3 握手中的密钥管理

以TLS 1.3协议为例，其握手过程充分体现了混合加密的设计思想。在TLS 1.3中，客户端和服务端通过ECDHE（椭圆曲线Diffie-Hellman密钥交换）协商出共享密钥，该密钥随后通过HKDF（基于HMAC的密钥派生函数）派生出会话密钥。整个过程中，非对称加密（ECDHE）负责密钥协商，对称加密（AES-GCM）负责实际数据传输。

具体参数示例：客户端发送ClientHello，携带支持的椭圆曲线（如P-256）和随机数；服务端回复ServerHello，携带选定的曲线参数和自身公钥；双方各自计算共享密钥，并通过HKDF-SHA256派生4个密钥：客户端加密密钥、客户端解密密钥、服务端加密密钥、服务端解密密钥。后续所有应用数据均使用AES-128-GCM或AES-256-GCM加密。

常见误区与总结