Java加密与加签：从AES、RSA到国密SM4/SM2的源码级解析与实战

原创

于 2026-06-22 12:41:12 发布 · 309 阅读

1. 项目概述：为什么数据安全是Java开发者的“护城河”？

在当今这个数据驱动的时代，我们开发的每一个应用，处理的每一条用户信息、每一笔交易记录，本质上都是在与“信任”打交道。用户信任我们，才敢把手机号、身份证、银行卡号交给我们；业务方信任我们，才敢把核心的交易链路和资金流转托付给我们的系统。这份信任的基石，就是数据安全。而加密与加签，正是构筑这道“护城河”最核心、最基础的两块砖石。我见过太多项目，业务逻辑写得天花乱坠，性能优化做到极致，却在数据安全上栽了跟头——一个接口被恶意调用导致资金损失，一份配置文件泄露导致数据库被拖库，这些事故的根源，往往就是对加密和加签的理解停留在“会用API”的层面，而不知其所以然。

作为Java开发者，我们几乎每天都会接触到 javax.crypto 、 java.security 这些包，调用 Cipher.getInstance(“AES”) 或者 Signature.getInstance(“SHA256withRSA”) 。但你是否真正思考过：为什么AES加密需要初始化向量（IV）？RSA签名和验签的流程到底在验证什么？ MessageDigest 计算出的摘要，和数字签名里的摘要是一回事吗？这次，我们不满足于仅仅调用API，而是要深入JDK源码和主流安全库的内部，像侦探一样，把加密与加签的每一个步骤、每一个字节的变化都拆解清楚。这不仅是应对面试中“请说说加密和加签的区别”这种问题的需要，更是为了在关键时刻，你能胸有成竹地设计出真正安全、可靠的系统架构，成为团队里那个让人放心的“安全守门员”。

2. 核心概念辨析：加密、摘要、签名，别再傻傻分不清

在深入源码之前，我们必须把几个最容易混淆的概念彻底厘清。很多开发者习惯性地把“加密”挂在嘴边，但实际上可能指的是完全不同的操作。

2.1 加密：为了机密性，把明文变成“天书”

加密的核心目标是 机密性 ，即确保信息不被未授权的第三方读取。它需要一个密钥，通过加密算法，将可读的明文转换为不可读的密文。接收方用对应的密钥解密后，才能恢复明文。根据密钥的使用方式，主要分为两类：

对称加密 ：加密和解密使用同一把密钥。就像你用同一把钥匙锁门和开门。它的优点是速度快，适合加密大量数据。最常见的算法是 AES 。这里的关键是，密钥本身必须通过安全的方式共享，密钥一旦泄露，加密就形同虚设。
非对称加密 ：使用一对密钥，公钥和私钥。公钥可以公开，用于加密；私钥必须严格保密，用于解密。反过来，用私钥加密（通常称为“私钥签名”），用公钥解密（验证）。最常见的算法是 RSA 。它的优点是解决了密钥分发问题，但速度慢，通常不用于直接加密大量数据，而是用来加密对称加密的密钥。

注意：很多人误以为HTTPS中的“加密”全程使用了RSA。实际上，主流做法（如TLS 1.2/1.3）是客户端用RSA公钥加密一个随机生成的“预主密钥”发给服务端，双方再基于这个“预主密钥”推导出相同的对称会话密钥，后续通信全部使用对称加密（如AES）。这是一个典型的混合加密系统。

2.2 摘要：为了完整性，给数据生成“指纹”

摘要，也叫哈希或散列，其核心目标是 完整性 。它不需要密钥，通过一个单向的哈希函数（如MD5、SHA-256、国密SM3），将任意长度的数据映射为一个固定长度的、唯一的“指纹”（摘要值）。这个过程的特性是：

单向性 ：无法从摘要反推出原始数据。
抗碰撞性 ：极难找到两个不同的数据产生相同的摘要。
雪崩效应 ：原始数据哪怕只改动一个比特，产生的摘要也会截然不同。

摘要本身不提供机密性，也不防篡改。攻击者可以同时修改数据和其摘要。因此，摘要常作为数字签名的基础。

2.3 加签与验签：为了不可否认性和完整性

加签（签名）是 非对称加密技术 + 摘要技术 的结合体，其核心目标是 完整性 和 不可否认性 。

发送方 ：先对原始数据计算摘要，然后用自己的私钥对这个摘要进行加密。这个“加密后的摘要”就是数字签名，随原始数据一起发送。
接收方 ：收到数据和签名后，做两件事：a) 用同样的算法对收到的数据计算摘要；b) 用发送方的公钥去解密那个签名，得到发送方计算的摘要。对比两个摘要，如果一致，则证明：数据在传输过程中未被篡改（完整性），且数据确实来自持有对应私钥的发送方（不可否认性）。

一个生动的比喻 ：你要寄一份重要的合同（数据）给合作伙伴。

只加密 ：你把合同锁进保险箱（加密），把钥匙（密钥）偷偷给合作伙伴。他能打开看到内容，但无法向法庭证明这合同一定是你寄的，因为钥匙可能被复制了。
只计算摘要 ：你把合同和合同的指纹（摘要）一起寄出。合作伙伴能核对指纹是否一致，确认合同没被掉包，但他同样无法证明指纹是你计算的。
加签：你计算合同的指纹，然后用你的私人印章（私钥）在指纹上盖个章（加密摘要）。你把合同和盖了章的指纹一起寄出。合作伙伴收到后，用你公开的印章样本（公钥）去验证那个章是不是真的，并且核对章里的指纹和合同当前的指纹是否一致。如果都匹配，那么法律上就能认定这份合同是你发出且未被篡改的。

3. 源码级解析：JDK中加密与加签的实现内幕

理解了概念，我们深入到Java标准库的源码层面，看看这些魔法是如何实现的。我们以 AES 加密和 SHA256withRSA 签名为例。

3.1 AES对称加密：Cipher类的核心流程

当你调用 Cipher.getInstance(“AES/CBC/PKCS5Padding”) 时，背后发生了什么？

1. SPI机制与算法查找 ： Cipher 类使用Java的 服务提供者接口 机制。 getInstance 方法会根据传入的算法字符串，在 java.security 配置文件中注册的提供者（如SunJCE, BouncyCastle）里查找具体的实现类。对于“AES”，默认的SunJCE提供者会返回一个 AESCipher 的实例。

2. 初始化：init方法里的关键 ：

// 简化的核心逻辑
public final void init(int opmode, Key key, AlgorithmParameterSpec params) {
    this.opmode = opmode; // Cipher.ENCRYPT_MODE 或 DECRYPT_MODE
    this.key = key;
    if (params != null) {
        // 例如，CBC模式需要IvParameterSpec
        this.iv = ((IvParameterSpec)params).getIV();
    }
    // 调用底层引擎的初始化
    engineInit(opmode, key, params);
}

密钥转换 ：你传入的 Key 对象（通常是一个 SecretKeySpec ），其内部的密钥字节数组会被检查长度（AES-128为16字节，192为24字节，256为32字节）。
参数处理 ：对于CBC模式，你必须提供 IvParameterSpec 。 IV（初始化向量）的作用是确保即使加密相同的明文，使用相同的密钥，也会产生不同的密文 ，防止攻击者通过模式分析破解。IV不需要保密，但必须不可预测，通常随机生成，并随密文一起传输。

3. 加密/解密：doFinal方法的块处理 ： AES是分组密码，一次处理一个固定大小的数据块（128位，16字节）。 doFinal 方法内部会处理填充

标签