一、系列简介
你每天打的 HTTPS 请求,背后跑着 TLS 1.3 握手——ECDHE 密钥交换、AES-GCM 加密、Ed25519 签名,整套流程在 100 毫秒内完成。你登录 GitHub 用的 OAuth 2.0,授权码经过 PKCE 保护,Access Token 是 JWT,签名密钥存在 KMS 里轮换。你存在数据库里的用户密码,经过 bcrypt 哈希、加盐、慢哈希迭代——这些全是密码学。问题是,大部分工程师对这些”黑盒”的理解停留在”调库”层面,一旦遇到密钥泄露、证书过期、JWT 伪造、TLS 降级攻击,就束手无策。
本系列从密码学三大分支(对称加密、非对称加密、哈希)出发,逐步深入到数字签名、TLS 1.3、PKI 证书体系、OAuth 2.0/OIDC、JWT 安全、零信任架构、密钥管理,再探索前沿方向(同态加密、后量子密码),最后以安全工程实践、攻击案例分析和全链路综合实战收尾。16 章内容覆盖从”调库工程师”到”安全架构师”的完整知识链路。
核心观点
- 密码学不是”调库”——不理解原理,你连参数都配不对:AES-GCM 的 nonce 重复一次就完蛋,RSA 的 padding 选错签名就能被伪造,JWT 的 alg=none 攻击只需要一行代码
- 安全是系统工程,不是单点技术:TLS 保护传输、KMS 保护密钥、OAuth 保护授权、零信任保护边界——
- 密码学攻击是检验安全设计的唯一标准:BEAST、Heartbleed、ROBOT、Logjam——每个攻击都暴露了”理论上安全、实现上脆弱”的鸿沟
- 后量子迁移不是未来,是现在:NIST 已标准化 Kyber/Dilithium,“先加密、后解密”的 harvest-now-decrypt-later 攻击正在发生
本系列假设你具备基本的网络协议知识(HTTP/TCP)和编程经验。OAuth 2.0 和 OIDC 部分与姊妹系列「Web 协议深潜」中的 OAuth2 与 OIDC 协议 互补,本系列侧重密码学视角(PKCE 的安全性证明、JWT 的签名与加密),Web 系列侧重协议流程与部署实践。
二、场景驱动阅读路线
不想按部就班从第 1 章读到第 16 章?以下 5 条路线从你日常遇到的真实问题出发,按”问题在哪→密码学怎么解决→底层原理是什么”的顺序串联章节。每条路线可独立阅读,前置依赖已在路线内标注。
路线总览
路线A:我的数据安全吗?
场景:数据库被拖库了、备份文件泄露了、日志里明文存着密钥——你需要理解数据保护的完整链路:用什么加密、密钥怎么管、哈希怎么防篡改。
| 顺序 | 章节 | 为什么读这章 |
|---|---|---|
| 1 | Ch1 密码学全景 | 建立全景认知:三大分支各解决什么问题、威胁模型怎么建模 |
| 2 | Ch2 对称加密 | 核心:AES-GCM/ChaCha20-Poly1305 是数据加密的主力——但 nonce 重复、密钥派生错误都是致命漏洞 |
| 3 | Ch4 哈希与 MAC | 完整性保护:SHA-256 验证数据没被篡改、HMAC 验证消息来源、bcrypt 保护密码 |
| 4 | Ch11 密钥管理 | 密钥是加密系统的命门——KMS/HSM、信封加密、密钥轮换策略 |
路线逻辑:先理解加密工具(Ch1→Ch2),再学完整性保护(Ch4),最后解决”密钥放哪”这个最现实的问题(Ch11)。很多团队加密做得很好,但密钥明文放在配置文件里——等于没加密。
路线B:HTTPS 是怎么工作的?
场景:你每天都在用 HTTPS,但 TLS 握手发生了什么?ECDHE 怎么交换密钥?证书链怎么验证?0-RTT 有什么安全风险?这条路线带你从加密算法一路追踪到证书信任链。
| 顺序 | 章节 | 为什么读这章 |
|---|---|---|
| 1 | Ch1 密码学全景 | 全景认知:密码学在 HTTPS 中的角色 |
| 2 | Ch2 对称加密 | TLS 数据通道用 AES-GCM 或 ChaCha20-Poly1305——AEAD 是 TLS 1.3 的加密核心 |
| 3 | Ch3 非对称加密 | TLS 密钥交换用 ECDHE——理解椭圆曲线才能理解前向安全 |
| 4 | Ch5 数字签名 | 证书签名用 RSA-PSS 或 Ed25519——签名算法选错,证书就不安全 |
| 5 | Ch6 TLS 1.3 | 核心:TLS 1.3 握手流程、0-RTT、密钥派生——HTTPS 安全的完整实现 |
| 6 | Ch7 证书与 PKI | 证书信任链、CA 层次、OCSP、Let’s Encrypt——HTTPS 信任的根基 |
路线逻辑:从加密原语出发(Ch2→Ch3→Ch5),理解 TLS 协议如何组合这些原语(Ch6),最后理解信任链如何建立(Ch7)。HTTPS 的安全不是某一个算法的功劳,而是对称加密+非对称加密+签名+证书链的协同。
路线C:如何实现用户认证?
场景:你要给系统加登录功能。“用 JWT 吧”——但 JWT 的签名算法怎么选?密钥怎么轮换?OAuth 2.0 的授权码流程为什么比隐式流程安全?PKCE 解决了什么问题?
| 顺序 | 章节 | 为什么读这章 |
|---|---|---|
| 1 | Ch1 密码学全景 | 全景认知:认证在密码学中的位置 |
| 2 | Ch3 非对称加密 | JWT 签名用 RSA/ECDSA——理解非对称加密才能理解签名验证 |
| 3 | Ch5 数字签名 | 签名是认证的基石——RSA-PSS/ECDSA/EdDSA 各有适用场景 |
| 4 | Ch8 OAuth 2.0 与 OIDC | 核心:授权码+PKCE 是目前最安全的 OAuth 流程——OIDC 在授权层上叠加身份层 |
| 5 | Ch9 JWT 安全 | JWT 不是银弹——JWS/JWE/JWK 的正确用法、常见漏洞(alg=none、密钥混淆、重放) |
路线逻辑:先理解签名的密码学基础(Ch3→Ch5),再学习 OAuth 2.0 的授权架构(Ch8),最后深入 JWT 的安全实践(Ch9)。很多认证漏洞不是协议问题,而是实现问题——JWT 的 alg=none 攻击就是典型。
路线D:量子计算来了怎么办?
场景:Shor 算法能破解 RSA 和 ECC,Grover 算法能削弱对称加密——量子计算对密码学的威胁不是科幻,是工程问题。NIST 已经标准化了后量子算法,迁移路径怎么规划?
| 顺序 | 章节 | 为什么读这章 |
|---|---|---|
| 1 | Ch1 密码学全景 | 全景认知:当前密码学的安全假设 |
| 2 | Ch3 非对称加密 | RSA/ECC 的安全基于大数分解和离散对数——Shor 算法直接打破这两个假设 |
| 3 | Ch12 同态加密 | 同态加密是隐私计算的方向——CKKS/BFV 允许在密文上计算 |
| 4 | Ch13 后量子密码 | 核心:NIST PQC 标准——Kyber(KEM)、Dilithium(签名)、迁移路径与混合方案 |
路线逻辑:先理解当前非对称加密的安全假设(Ch3),再了解隐私计算前沿(Ch12),最后掌握后量子迁移方案(Ch13)。harvest-now-decrypt-later 攻击意味着你现在加密的数据,如果不用后量子算法,十年后可能被解密。
路线E:我的系统会被攻击吗?
场景:TLS 配置正确吗?有没有降级风险?密钥实现在侧信道上泄露了吗?BEAST、Heartbleed、ROBOT 这些攻击在历史上是怎么发生的?安全工程怎么系统性地防御?
| 顺序 | 章节 | 为什么读这章 |
|---|---|---|
| 1 | Ch1 密码学全景 | 全景认知:威胁模型与安全原则 |
| 2 | Ch6 TLS 1.3 | TLS 是攻击面最大的密码学协议——理解 TLS 才能理解大部分网络攻击 |
| 3 | Ch14 安全工程实践 | 核心:STRIDE 威胁建模、安全开发生命周期、渗透测试方法论 |
| 4 | Ch15 密码学攻击 | 历史攻击案例——BEAST/Heartbleed/ROBOT/Logjam、侧信道攻击、实现漏洞 |
路线逻辑:先理解 TLS 这个最大攻击面(Ch6),再学习安全工程的方法论(Ch14),最后通过历史攻击案例理解”理论上安全≠实现上安全”(Ch15)。每个攻击案例都是一次安全设计的教训。
路线F:我想动手实践!
场景:理论看懂了,但一动手就懵——怎么生成 ECC 密钥?怎么签发 JWT?TLS 握手到底长什么样?这条路线串联所有实践环节,从简单到复杂,每一步都有可运行的代码和真实输出。
| 顺序 | 章节 | 实践内容 |
|---|---|---|
| 1 | Ch2 对称加密 | 凯撒密码 → XOR → AES-CBC → AES-GCM 渐进式实现 |
| 2 | Ch3 非对称加密 | OpenSSL RSA/ECC 密钥生成、ECDH 密钥交换、混合加密 |
| 3 | Ch4 哈希与 MAC | SHA-256/SHA-3 计算、HMAC 签名验证、长度扩展攻击、bcrypt |
| 4 | Ch5 数字签名 | RSA-PSS/ECDSA/Ed25519 签名验证、证书链验证 |
| 5 | Ch6 TLS 1.3 | s_client 分析握手、TLS 1.2 vs 1.3 对比 |
| 6 | Ch7 证书与 PKI | 从零构建 PKI:Root CA → 中间 CA → 终端证书 → CRL |
| 7 | Ch8 OAuth 2.0 与 OIDC | PKCE 生成器、授权码流程模拟、JWT 解码 |
| 8 | Ch9 JWT 安全 | alg=none 攻击、算法混淆攻击、ES256 签发验证、密钥轮换 |
| 9 | Ch17 TLS 握手实战 | 综合:自建 CA → 签发证书 → TLS 服务器 → 抓包分析 |
| 10 | Ch18 认证协议实战 | 综合:OAuth2 + JWT 认证系统、密钥轮换、安全测试 |
路线逻辑:先在各理论章节的实践环节中掌握单个组件(Ch2-9),再用两个综合性实战章节(Ch17-18)把所有组件组装成完整的系统。实践路线的核心原则是:每个理论章节都有对应的动手环节,不是看完就忘,而是看完就做。
路线交叉参考
同一章节在不同路线中的关注点不同:
| 章节 | 路线A 关注点 | 路线B 关注点 | 路线C 关注点 | 路线D 关注点 | 路线E 关注点 |
|---|---|---|---|---|---|
| Ch1 | 威胁模型 | HTTPS 角色 | 认证位置 | 安全假设 | 威胁模型 |
| Ch2 | 数据加密核心 | AEAD 加密通道 | — | — | — |
| Ch3 | — | ECDHE 密钥交换 | JWT 签名基础 | RSA/ECC 脆弱性 | — |
| Ch4 | 完整性+密码哈希 | — | — | — | — |
| Ch5 | — | 证书签名 | 签名是认证基石 | — | — |
| Ch6 | — | TLS 握手核心 | — | — | 最大攻击面 |
| Ch7 | — | 证书信任链 | — | — | — |
| Ch8 | — | — | OAuth 核心流程 | — | — |
| Ch9 | — | — | JWT 漏洞防御 | — | — |
| Ch10 | — | — | — | — | — |
| Ch11 | 密钥是命门 | — | — | — | — |
| Ch12 | — | — | — | 隐私计算方向 | — |
| Ch13 | — | — | — | PQC 迁移核心 | — |
| Ch14 | — | — | — | — | 安全工程方法论 |
| Ch15 | — | — | — | — | 攻击案例分析 |
| Ch16 | — | — | — | — | — |
| Ch17 | — | TLS 握手综合实战 | — | — | — |
| Ch18 | — | — | OAuth2+JWT 综合实战 | — | — |
三、知识导图
以下导图展示 16 章知识之间的网络关系。与线性目录不同,这里强调跨层的连接——TLS 同时依赖对称加密(数据通道)、非对称加密(密钥交换)、签名(证书验证)三种原语的协同;OAuth 2.0 的安全性依赖 TLS 传输层保护 + JWT 签名保护 + PKCE 信道绑定三重保障。
概念关系图
章节网络关系图
知识关联参考表
按六层模型组织:原语层(密码学基础)→ 构造层(安全构造)→ 协议层(应用协议)→ 基础设施层(运行时支撑)→ 前沿层(未来方向)→ 攻防层(检验与实战)。同一行的条目之间存在直接的知识依赖。
| 原语 | 构造 | 协议 | 基础设施 | 前沿 | 攻防 | 实践 |
|---|---|---|---|---|---|---|
| AES-GCM/ChaCha20 | TLS 数据通道 | OAuth 2.0 传输保护 | KMS 密钥存储 | — | BEAST/CRIME 攻击 | 凯撒→AES-GCM 渐进实验 |
| ECDHE 密钥交换 | TLS 握手 | OIDC id_token 签名 | HSM 密钥保护 | Kyber KEM 替代 | Logjam 降级攻击 | OpenSSL RSA/ECC 密钥生成 |
| RSA-PSS/EdDSA | X.509 证书签名 | JWT JWS 签名 | 密钥轮换策略 | Dilithium 签名替代 | ROBOT 攻击 | RSA-PSS/ECDSA/Ed25519 签名验证 |
| SHA-256/SHA-3 | HMAC 消息认证 | PKCE code_verifier | 信封加密 | — | 碰撞攻击实践 | SHA-256/3 + HMAC + 长度扩展攻击 |
| bcrypt/Argon2 | 密码哈希存储 | 用户密码保护 | 加盐与迭代参数 | — | 彩虹表防御 | bcrypt 密码哈希 + cost 对比 |
| — | CKKS/BFV 同态 | 隐私计算 | — | 全同态加密 | — | — |
四、系列大纲
以下是按章节编号排列的完整目录。建议结合上方的场景驱动阅读路线和知识导图选择适合你的阅读顺序。
| 章节 | 标题 | 核心内容 |
|---|---|---|
| 0 | 系列导读 | 系列定位、场景路线、知识导图、开发环境、参考资料 |
| 1 | 密码学全景 | 对称/非对称/哈希三大分支、威胁模型、安全原则 |
| 2 | 对称加密 | AES/ChaCha20、GCM/AEAD、填充攻击、密钥派生 |
| 3 | 非对称加密 | RSA/ECC、ECDH/ECDSA、密钥长度选择、数学基础 |
| 4 | 哈希与 MAC | SHA-2/SHA-3、HMAC、碰撞攻击、密码哈希(bcrypt/Argon2) |
| 5 | 数字签名 | RSA-PSS/ECDSA/EdDSA、证书链、签名安全性证明 |
| 6 | TLS 1.3 | 握手流程、0-RTT、密钥派生、与 TLS 1.2 对比 |
| 7 | 证书与 PKI | X.509、CA 层次、OCSP/CRL、Let’s Encrypt、证书锁定 |
| 8 | OAuth 2.0 与 OIDC | 授权码/PKCE、四种流程对比、OIDC 身份层、安全最佳实践 |
| 9 | JWT 安全 | JWS/JWE/JWK、alg=none 攻击、密钥混淆、重放防御 |
| 10 | 零信任架构 | BeyondCorp、mTLS、服务网格、持续验证、策略引擎 |
| 11 | 密钥管理 | KMS/HSM、信封加密、密钥轮换、密钥生命周期 |
| 12 | 同态加密 | CKKS/BFV、隐私计算、同态加密在 ML 中的应用 |
| 13 | 后量子密码 | NIST PQC 标准、Kyber/Dilithium、迁移路径、混合方案 |
| 14 | 安全工程实践 | STRIDE 威胁建模、安全开发生命周期、渗透测试、安全审计 |
| 15 | 密码学攻击 | BEAST/Heartbleed/ROBOT/Logjam、侧信道攻击、实现漏洞 |
| 16 | 综合实战 | OAuth2+JWT+TLS+mTLS 全链路安全认证系统、密钥轮换与审计 |
五、开发环境搭建
以下环境搭建步骤基于 Ubuntu 22.04 LTS。其他发行版的包名和路径可能不同,请参考各项目官方文档。部分实验涉及密钥生成和证书操作,建议在隔离环境中进行,切勿在生产环境直接操作。
密码学工具架构
OpenSSL 环境
# 安装 OpenSSL(3.x 版本,支持 Ed25519/Ed448)sudo apt install openssl
# 验证版本openssl version# OpenSSL 3.0.2 15 Mar 2022
# 生成 RSA-2048 密钥对openssl genrsa -out rsa-private.pem 2048openssl rsa -in rsa-private.pem -pubout -out rsa-public.pem
# 生成 Ed25519 密钥对(推荐用于签名)openssl genpkey -algorithm Ed25519 -out ed25519-private.pemopenssl pkey -in ed25519-private.pem -pubout -out ed25519-public.pem
# 生成 ECDH 密钥对(用于密钥交换)openssl ecparam -name prime256v1 -genkey -noout -out ecdh-private.pem
# AES-256-GCM 加密/解密openssl enc -aes-256-gcm -salt -in plaintext.txt -out ciphertext.bin -pass pass:your-keyopenssl enc -aes-256-gcm -d -in ciphertext.bin -out decrypted.txt -pass pass:your-key
# SHA-256 哈希openssl dgst -sha256 -hex message.txt
# RSA-PSS 签名与验证openssl dgst -sha256 -sign rsa-private.pem -sigopt rsa_padding_mode:pss -out signature.bin message.txtopenssl dgst -sha256 -verify rsa-public.pem -sigopt rsa_padding_mode:pss -signature signature.bin message.txt证书与 PKI 环境
# 生成自签名 CA 证书openssl req -x509 -new -nodes -key ca-key.pem -sha256 -days 3650 -out ca-cert.pem \ -subj "/C=CN/ST=Beijing/O=MyCA/CN=My Root CA"
# 生成服务端 CSR 并签发证书openssl req -new -key server-key.pem -out server.csr \ -subj "/C=CN/ST=Beijing/O=MyOrg/CN=myapp.example.com"openssl x509 -req -in server.csr -CA ca-cert.pem -CAkey ca-key.pem \ -CAcreateserial -out server-cert.pem -days 365 -sha256
# 查看证书详情openssl x509 -in server-cert.pem -text -noout
# 验证证书链openssl verify -CAfile ca-cert.pem server-cert.pem
# 安装 certbot(Let's Encrypt 客户端)sudo apt install certbot# 或使用 snapsudo snap install --classic certbot
# 获取证书(standalone 模式)sudo certbot certonly --standalone -d example.com
# 查看证书有效期echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -datesJava keytool(用于 Java 生态)
# 生成 Java 密钥库keytool -genkeypair -alias myapp -keyalg RSA -keysize 2048 \ -validity 365 -keystore keystore.jks -storepass changeit
# 导出证书keytool -exportcert -alias myapp -keystore keystore.jks \ -rfc -file myapp-cert.pem -storepass changeit
# 导入 CA 证书到信任库keytool -importcert -alias myca -file ca-cert.pem \ -keystore truststore.jks -storepass changeit -noprompt
# 查看密钥库内容keytool -list -v -keystore keystore.jks -storepass changeitWireshark TLS 抓包
# 安装 Wiresharksudo apt install wireshark tshark
# 命令行抓取 TLS 握手包sudo tshark -i eth0 -f "tcp port 443" -w tls-handshake.pcap
# 解析 TLS 握手(需要配置密钥日志文件)# 在启动应用前设置环境变量export SSLKEYLOGFILE=/tmp/sslkeys.log# 然后在 Wireshark 中:Edit → Preferences → Protocols → TLS → Pre-Master-Secret log filename
# 用 tshark 过滤 TLS ClientHellotshark -r tls-handshake.pcap -Y "tls.handshake.type == 1" -T fields \ -e tls.handshake.extensions_server_name -e ip.dstTLS 配置审计
# 安装 sslyzepip install sslyze
# 扫描目标站点的 TLS 配置sslyze --certinfo --openssl_ccs --openssl_heartbleed --robot \ --sslv3 --tlsv1 --tlsv1_1 --tlsv1_2 --tlsv1_3 example.com:443
# 使用 nmap 检查支持的加密套件nmap --script ssl-enum-ciphers -p 443 example.com
# 使用 testssl.sh(更全面的检测)git clone https://github.com/drwetter/testssl.sh.gitcd testssl.sh./testssl.sh example.comOpenSSL 3.x 是当前推荐版本,支持 Ed25519/Ed448、AES-GCM、ECDH 等现代算法。如果你用的是 OpenSSL 1.1.1,部分后量子算法和 Ed25519 可能需要额外编译。密钥日志文件(SSLKEYLOGFILE)仅用于开发调试,切勿在生产环境启用。
六、本系列的实践方法论
本系列遵循 原理 → 构造 → 协议 → 攻击 → 防御 的学习方法:
- 原理:理解密码学原语的数学基础和安全假设——AES 的分组密码工作模式、ECC 的椭圆曲线离散对数、SHA-3 的海绵构造
- 构造:看原语如何组合成安全构造——签名 = 哈希 + 非对称加密、TLS = 密钥交换 + 对称加密 + 签名验证
- 协议:理解协议如何使用构造——OAuth 2.0 的授权码流程为什么安全、JWT 的 JWS Compact Serialization 怎么工作
- 攻击:通过攻击案例理解安全边界——BEAST 利用 CBC 模式可预测 IV、ROBOT 利用 RSA PKCS#1 v1.5 填充预言机
- 防御:系统性地加固——密钥轮换、证书锁定、零信任、STRIDE 威胁建模
每章的「动手实践」部分都遵循这一方法论。先理解原理,再动手构造,然后尝试攻击自己构造的系统,最后加固防御。密码学最忌讳”调库就完事”——你至少要能解释每个参数的安全含义。
密码学实验中生成的密钥和证书仅供学习使用,切勿用于生产环境。部分攻击实验(如 BEAST、ROBOT)需要特定版本的 OpenSSL,请严格在隔离环境中操作。本系列在每章都会标注相关安全风险。
七、推荐参考资料
经典教材
| 书籍 | 作者 | 特点 |
|---|---|---|
| 《Real-World Cryptography》 | David Wong | 实战导向,覆盖现代密码学全栈,代码示例丰富 |
| 《Serious Cryptography》 | Jean-Philippe Aumasson | 深入原理,AES/SHA/ECC 的数学基础讲得最清楚 |
| 《The Art of Exploitation》 | Jon Erickson | 攻击视角,理解缓冲区溢出、格式化字符串等底层漏洞 |
| 《Applied Cryptography》 | Bruce Schneier | 密码学百科全书,协议设计参考 |
| 《Cryptography Engineering》 | Ferguson, Schneier, Kohno | 工程实践,如何正确使用密码学原语 |
官方文档与标准
| 文档 | 链接 | 说明 |
|---|---|---|
| RFC 8446: TLS 1.3 | datatracker.ietf.org | TLS 1.3 协议完整规范 |
| RFC 6749: OAuth 2.0 | datatracker.ietf.org | OAuth 2.0 授权框架 |
| RFC 7519: JWT | datatracker.ietf.org | JSON Web Token 标准 |
| NIST FIPS 197: AES | csrc.nist.gov | AES 标准规范 |
| NIST PQC Standardization | csrc.nist.gov | 后量子密码标准化进程 |
| OWASP Cheat Sheet Series | cheatsheetseries.owasp.org | Web 安全速查手册 |
开源工具
技术博客与资源
- NIST Computer Security Resource Center — 密码标准与指南的权威来源
- IACR ePrint Archive — 密码学最新论文预印本
- Matthew Green’s Blog — 密码学工程实践
- Trail of Bits Blog — 安全审计与密码学分析
- SSL Labs — TLS 配置在线检测
准备好开始了吗?从 密码学全景 开始你的密码学与安全工程之旅吧!
参考
- RFC 6749 — The OAuth 2.0 Authorization Framework
- RFC 7519 — JSON Web Token (JWT)
- RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3
- datatracker.ietf.org
- datatracker.ietf.org
- datatracker.ietf.org
- csrc.nist.gov
- csrc.nist.gov
- cheatsheetseries.owasp.org
- OpenSSL
- liboqs
- certbot
- cfssl
- testssl.sh
- jwt.io
- NIST Computer Security Resource Center
- IACR ePrint Archive
- Matthew Green’s Blog
- Trail of Bits Blog
- SSL Labs
支持与分享
如果这篇文章对你有帮助,欢迎支持作者或分享给更多人
部分信息可能已经过时






