作者：林 | 系列：密码学 | 适合读者：后端开发 / 对密码学感兴趣的工程师

一、为什么要懂密码学

作为开发者，你可能每天都在用密码学而不自知：

• HTTPS 连接 → TLS 握手（非对称 + 对称加密）
• 用户密码存储 → BCrypt/Argon2（散列函数）
• JWT Token → HMAC-SHA256（消息认证码）
• 支付接口签名 → RSA/SM2（数字签名）
• 数据库敏感字段 → AES/SM4（对称加密）

密码学并非安全团队的专属，重点是每个后端工程师的基本功。本文用下限的篇幅把三大支柱讲清楚，后续每篇深入一个方向。

二、三大分类总览

核心区别一句话：

• Hash：单向压缩，不能解密，用于验证完整性
• 对称加密：一把钥匙，能加能解，用于加密数据
• 非对称加密：两把钥匙，公私配对，用于密钥交换和签名

三、散列函数（Hash）

3.1 特征

3.2 常见算法

3.3 代码示例

import java.security.MessageDigest;

// SHA-256
byte[] hash = MessageDigest.getInstance("SHA-256")
    .digest("hello".getBytes());

// SM3（需要 BouncyCastle）
byte[] sm3Hash = MessageDigest.getInstance("SM3")
    .digest("hello".getBytes());

3.4 典型应用

四、对称加密（Symmetric Encryption）

4.1 原理

加密和解密使用同一把密钥：

作者：林 | 系列：密码学 | 适合读者：后端开发 / 安全工程师

一、什么是散列函数

散列函数（Hash Function）将任意长度的输入映射为固定长度的输出，且这个过程不可逆。

输入（任意长度）       →  散列函数  →  输出（固定长度）
"hello"              →  SHA-256  →  2cf24dba5fb0a30e...（64 hex = 256 bit）
"hello world"        →  SHA-256  →  b94d27b9934d3e08...（64 hex = 256 bit）
整本《红楼梦》(2MB)   →  SHA-256  →  固定 64 hex 字符

1.1 密码学安全散列的四个性质

二、主流算法对比

2.1 算法一览

2.2 MD5：为什么不能再用

MD5 的碰撞攻击已经非常成熟：

作者：林 | 系列：密码学 | 适合读者：后端开发 / 安全工程师

一、对称加密基础

对称加密使用同一把密钥进行加密和解密。当前主流的两个分组密码算法：

两者安全性等价（AES-128 ≈ SM4），区别在于合规要求：信创项目用 SM4，其他场景用 AES。

二、加密模式：比算法本身更重要

分组密码一次只能处理一个固定长度的数据块（16 字节）。当明文超过 16 字节时，加密模式决定了如何处理多个分组。

模式选错，算法再强也白搭。

2.1 ECB：千万别用

ECB（Electronic Codebook）每个分组独立加密：

作者：林 | 系列：密码学 | 适合读者：后端开发 / 安全工程师

一、非对称加密原理

对称加密用一把钥匙，非对称加密用一对钥匙：

公钥（Public Key）：可以公开，任何人都能拿到
私钥（Private Key）：必须保密，只有自己持有

加密：用对方的公钥加密 → 只有对方的私钥能解
签名：用自己的私钥签名 → 任何人用公钥都能验证

非对称加密的数学基础是"单向陷门函数"，正向计算容易，反向计算极难，但持有特定信息（私钥）可以轻松反向。

二、三大主流算法

2.1 RSA

基于大整数分解难题：给定两个大素数 p、q，计算 n = p × q 容易；但给定 n，分解出 p 和 q 极难。

密钥生成：
  1. 选两个大素数 p, q（各 1024 bit）
  2. 计算 n = p × q（2048 bit）
  3. 计算 φ(n) = (p-1)(q-1)
  4. 选择 e（通常 65537），满足 gcd(e, φ(n)) = 1
  5. 计算 d = e⁻¹ mod φ(n)

  公钥 = (n, e)
  私钥 = (n, d)

加密：C = M^e mod n
解密：M = C^d mod n

RSA 的问题：密钥太长。2048 bit 才提供 112 bit 安全强度，4096 bit 才提供 128 bit。

作者：林 | 系列：密码学 | 适合读者：后端开发 / 安全工程师

一、问题：对称密钥怎么安全传递

对称加密速度快，但面临一个核心问题：通信双方怎么共享同一把密钥？

解决方案有两种：

• 数字信封：用非对称加密传递对称密钥
• 密钥协商：双方各出一部分，协商出共享密钥（不传输密钥本身）

二、数字信封

2.1 原理

发送方                                   接收方
  │                                       │
  │ 1. 随机生成对称密钥 K                   │
  │ 2. 用 K 加密业务数据：C = Enc(K, Data) │
  │ 3. 用接收方公钥加密 K：EK = Enc(PubB, K)│
  │ 4. 发送 (EK, C) ─────────────────────→│
  │                                       │
  │                 5. 用私钥解密：K = Dec(PriB, EK)
  │                 6. 用 K 解密数据：Data = Dec(K, C)
  │                                       │

好处：

作者:lin | 系列:密码学实战

一、问题背景:加密与检索的两难

数据库安全的成熟实践是:敏感字段落盘前加密。比如用户的手机号、身份证号、姓名,写入数据库时用 AES 加密成一串乱码。

但业务马上就会遇到一个问题:

-- 加密前,模糊查询很自然
SELECT * FROM users WHERE name LIKE '%张%';

-- 加密后,name 字段变成了 'a3f8b2c1d4e5...',LIKE 完全失效
SELECT * FROM users WHERE name LIKE '%a3f8%';  -- 这搜的是密文,不是张三

直接解密再搜索? 如果表有 1000 万行,每次查询都要全部解密再逐一比对,响应时间从毫秒级变成分钟级,完全不可接受。

保留明文索引? 那加密等于白做–索引泄露的信息量和明文几乎一样。

这就是**可搜索加密(Searchable Encryption, SE)**要解决的核心矛盾:如何在不暴露明文的前提下,高效地对加密数据做检索?

二、四种主流方案对比

方案一:桶索引(Bucket Index)

原理: 直接的思路–为每个关键词建立一个"桶",查询时直接定位到桶。

作者：林 | 系列：密码学 | 适合读者：后端开发 / 对前沿密码学感兴趣的工程师

一、前言

前六篇覆盖了工程中更常用的密码学技术。这篇聊几个"高级货"，它们目前在特定场景已有落地，未来几年会越来越重要：

二、格式保留加密（FPE）

2.1 什么是 FPE

FPE（Format-Preserving Encryption）：加密后的密文与明文格式完全相同。

普通 AES 加密：
  "13800001111" → "a3Kf8bQ2xR7m9p..." （Base64 乱码，长度也变了）

FPE 加密：
  "13800001111" → "15927463850"       （还是 11 位数字）
  "张三"        → "李七"              （还是 2 个汉字）
  "320106199001011234" → "410523198712255678" （还是 18 位身份证号格式）

2.2 为什么需要 FPE

存量系统改造时，数据库字段类型、长度、校验规则都不能改。用 AES 加密后字段变成了长 Base64 字符串，需要改表结构、改校验逻辑、改前端展示，改动太大。

作者：林 | 系列：国密实战 | 适合读者：Java 后端/架构师

一、背景与问题

随着《密码法》的实施和信创（信息技术应用创新）要求的推进，越来越多的政府、央企、金融项目要求使用国密算法替代 RSA/ECDSA。SM2 作为国密体系中的非对称加密算法，对标 RSA-2048 和 ECDSA P-256，已广泛应用于数字证书、签名验签、密钥交换等场景。

然而，在实际项目中接入 SM2 时，第一个拦路虎往往并非算法本身，重点是，密钥格式和证书解析。不同厂商输出的密钥格式不一致（hex、DER、PEM），PFX 证书里封装的 SM2 密钥对解析方式与 RSA 也有差异，稍不注意就会踩坑。

本文将系统梳理 SM2 密钥格式，并给出从 PFX 证书中提取 SM2 公私钥的完整 Java 实现。

二、SM2 算法简介

SM2 是国家密码管理局发布的椭圆曲线公钥密码算法，标准编号 GM/T 0003，包含：

SM2 使用的椭圆曲线参数为 sm2p256v1，其曲线方程为标准 Weierstrass 形式：y² = x³ + ax + b (mod p)。

作者：林 | 系列：国密实战 | 适合读者：Java 后端/架构师 + 前端开发者

一、背景与问题

在很多业务场景中，前端需要对请求参数进行签名，后端进行验签，以确保数据完整性和防篡改。传统方案多使用 RSA 签名，但在信创项目中，SM2 签名验签成为必选项。

典型场景：

• 前端提交表单数据，附带 SM2 签名
• 后端验签通过后才处理业务逻辑
• API 网关层面的请求签名校验
• 合同/文档电子签章

前后端对接 SM2 签名验签的核心挑战：

1. 库的选择：Java 端用什么库？前端用什么库？
2. 密钥格式约定：私钥和公钥的格式必须统一
3. userId 的一致性：SM2 签名有一个独特的 userId 参数，两端必须一致
4. hash 参数的一致性：是否对消息做预哈希，两端必须统一
5. 签名格式：r || s 拼接 vs DER 编码，两端必须约定

本文将给出 Java（Hutool）+ TypeScript（sm-crypto）的完整对接方案。

二、SM2 签名验签原理

2.1 签名过程

SM2 签名过程比 ECDSA 多了一个 Z 值（用户标识哈希）的计算。完整流程如下：

输入参数：

• 待签名消息 M
• 用户标识 ID（默认 "1234567812345678"）
• 私钥 d（256 位整数）
• 公钥 P = d × G = (xA, yA）

步骤：

作者：林 | 系列：国密实战 | 适合读者：Java 后端/架构师

一、背景与问题

在国企、央企、政府项目的接口对接中，数据传输的安全性要求通常采用数字信封（Digital Envelope）机制：使用非对称算法加密对称密钥，再用对称密钥加密业务数据。这既保证了密钥传输的安全性，又兼顾了大数据量加密的性能。

在国密体系中，这个组合就是 SM2 + SM4：

• SM4：对称加密算法，负责加密业务数据（高效）
• SM2：非对称加密算法，负责加密 SM4 密钥（安全）

1.1 为什么需要数字信封？

SM2 加密的数据长度受限，上限明文长度约为 256 字节（受椭圆曲线参数限制）。不适合直接加密业务数据。而 SM4 虽然性能好，但密钥需要安全传输。数字信封完美结合了两者的优势。

SM2 加密数据长度计算：密文长度 = 65（C1，临时公钥点）+ 32（C3，SM3 哈希）+ n = 97 + n bytes。其中 n 为明文长度。加密 16 字节 SM4 密钥时，密文为 97 + 16 = 113 字节。