Capability</th>	Podman</th>	Docker</th></tr></thead>
CHOWN</strong></td>	✔️</td>	✔️</td></tr>
DAC_OVERRIDE</strong></td>	✔️</td>	✔️</td></tr>
FSETID</strong></td>	✔️</td>	✔️</td></tr>
FOWNER</strong></td>	✔️</td>	✔️</td></tr>
MKNOD</strong></td>	❌</td>	✔️</td></tr>
NET_RAW</strong></td>	❌</td>	✔️</td></tr>
SETGID</strong></td>	✔️</td>	✔️</td></tr>
SETUID</strong></td>	✔️</td>	✔️</td></tr>
SETFCAP</strong></td>	✔️</td>	✔️</td></tr>
SETPCAP</strong></td>	✔️</td>	✔️</td></tr>
NET_BIND_SERVICE</strong></td>	✔️</td>	✔️</td></tr>
SYS_CHROOT</strong></td>	✔️</td>	✔️</td></tr>
KILL</strong></td>	✔️</td>	✔️</td></tr>
AUDIT_WRITE</strong></td>	❌</td>	✔️</td></tr> </tbody></table> 在容器化现有应用程序时时, 需要注意两者的差异; 对终端用户来说没有什么直接影响, 但建议启动容器时配置 `--security-opt=no-new-privileges</code> 以禁止容器进程获得额外权限, 或者直接禁用所有 Capabilities (--cap-drop=all</code>) 再按需添加 (--cap-add=CAP_NAME</code>), 防止类似 CAP_BPF</code> 这些后面才引入的高危 Capabilities 被意外添加.</p> </li> </ol>` 编写 Rootless 友好的 Dockerfile</h2> 总体和编写普通 Dockerfile 没什么区别, 但需要注意以下几点:</p> 指定 rootless USER</code>, 需要是数字 ID.</p> 推荐: USER=65532:65532</code>.</p> </li> 尽量使用 Distroless 镜像作为基础镜像.</p> 如果应用程序是完全静态编译的, 直接使用 scratch</code> (适合现代应用程序, 没有奇奇怪怪的依赖) 或 gcr.io/distroless/static</code> (适合传统应用程序, 仍然依赖系统 CA 之类的奇怪玩意).</p> 不同语言编写的项目的静态编译方法参考:</p> 对于 C / C++, 具体项目具体分析.</p> </li> 对于 Go, 可以配置 CGO_ENABLED=0</code>, 如果项目以及项目的依赖没有依赖 CGO 的话.</p> </li> 对于 Rust, 可以配置 target x86_64-unknown-linux-musl</code> (amd64) 或 aarch64-unknown-linux-musl</code> (arm64) 目标平台进行静态编译.</p> > rustup target add x86_64-unknown-linux-musl </span># ... </span>> cd /tmp </span>> cargo new test-static-build </span> Creating binary (application) `test-static-build` package </span>note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html </span>> cd test-static-build </span>> cargo build --release --target x86_64-unknown-linux-musl </span> Compiling test-static-build v0.1.0 (/tmp/test-static-build) </span> Finished `release` profile [optimized] target(s) in 1.22s </span>> ldd /data/Compile/cargo-target-dir/x86_64-unknown-linux-musl/release/test-static-build </span> statically linked </span></code></pre> 一般来说, 能编译为 x86_64-unknown-linux-gnu</code> 就能编译为 x86_64-unknown-linux-musl</code>, 除非依赖到某些奇奇怪怪的 C 库.</p> </li> …</p> </li> </ol> </li> 如果应用程序依赖于 glibc, 可以使用 gcr.io/distroless/base-nossl</code>; 如果应用程序还依赖于 OpenSSL (v3.X), 可以使用 gcr.io/distroless/base</code>.</p> </li> </ol> 一些问题:</p> 尝试运行容器时, 报告 “error while loading shared libraries: XXX: cannot open shared object file: No such file or directory” 错误.</p> 此即缺失依赖库问题.</p> 这种情况下, 使用 ldd 查看依赖库, 再参考相关库的安装方法直接从完整镜像复制文件即可, 如笔者在打包 Resilio Sync 时的做法:</p> #</span> ... </span></span>ARG </span>DEBIAN_BASE_VERSION=trixie-slim </span>ARG </span>DEBIAN_BASE_HASH=f6e2cfac5cf956ea044b4bd75e6397b4372ad88fe00908045e9a0d21712ae3ba </span>#</span> ... </span></span>FROM</span> --platform=linux/${TARGETARCH} debian:${DEBIAN_BASE_VERSION}@sha256:${DEBIAN_BASE_HASH} AS downloader </span>#</span> ... </span></span>RUN </span>set -e && \ </span>#</span> ... </span></span>&& \ </span>ARCH=$(dpkg --print-architecture) \ </span>&& \ </span>case "</span>${ARCH}"</span></span> in \ </span>amd64) LIBARCH="</span>x86_64-linux-gnu"</span></span> ;; \ </span>arm64) LIBARCH="</span>aarch64-linux-gnu"</span></span> ;; \ </span>) echo "</span>Unsupported architecture: ${ARCH}"</span></span> && exit 1 ;; \ </span>esac \ </span>&& \ </span>cp /lib/${LIBARCH}/libcrypt.so.1 /tmp/resilio-sync/lib/libcrypt.so.1 </span>#</span> ... </span></span>FROM</span> scratch </span>#</span> ... </span></span>ENV </span>LD_LIBRARY_PATH=/opt/resilio-sync/lib </span>#</span> ... </span></span></code></pre> (笔者评: Resilio Sync 怎么还在用 OpenSSL 1.1.X 啊, 硬要用就不能静态编译进程序里面么… C / C++ 的依赖灾难在这就体现了…)</p> </li> OpenSSL CA 问题.</p> 但凡最终应用程序报告 SSL 相关错误, 大抵是这里所述的问题.</p> 这种情况下, 可以在构建阶段安装 ca-certificates 包, 将 CA 文件复制到最终镜像中, 并正确配置环境变量, 如笔者在打包 qBittorrent 时的做法:</p> #</span> ... </span></span>ARG </span>ALPINE_BASE_VERSION=3.23.3 </span>ARG </span>ALPINE_BASE_HASH=25109184c71bdad752c8312a8623239686a9a2071e8825f20acb8f2198c3f659 </span>#</span> ... </span></span>FROM</span> alpine:${ALPINE_BASE_VERSION}@sha256:${ALPINE_BASE_HASH}</span> AS</span> downloader</span> </span>#</span> ... </span></span>RUN </span>set -e && \ </span> apk -U upgrade && apk add --no-cache \ </span> ca-certificates=20251003-r0 \ </span>#</span> ... </span></span>FROM scratch </span>#</span> ... </span></span>COPY</span> --from=downloader</span> /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt </span>#</span> ... </span></span>ENV </span>SSL_CERT_DIR=/etc/ssl/certs \ </span> SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt </span>#</span> ... </span></span></code></pre> (笔者评: 还是喜欢 Rustls + WebPKI, OpenSSL 这种岁月痕迹过于重的库, 唉…)</p> </li> </ol> </li> </ol> 使用 systemd 管理 Rootless Podman 容器</h2> 参考文档: https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html</a></p> Podman 不像 Docker 那样有守护程序, 需要以其他方式管理容器的自动启动等. Podman 提供了 Quadlet, 以通过 systemd 来管理 Podman 容器.</p> 下面是一个示例 Quadlet 文件:</p> [Unit] </span>Description=FreeNGINX Distroless Container Service </span>RequiresMountsFor=%t/containers </span> </span>[Container] </span># Specify the name of the container. </span>ContainerName=freenginx </span># * Specify the container image to use. </span>Image=ghcr.io/han-rs/container-ci-freenginx:latest </span># * Automatically pull the latest image. </span>AutoUpdate=registry </span># * Run the container in user namespace mode with the current user's ID. </span># * </span># * Don't modify this field unless you know what you're doing. </span>UserNS=keep-id:uid=65532,gid=65532 </span># * Use the host's network stack for better performance. </span>Network=host </span># * Publish ports from the container to the host. </span># * </span># * If Network=host is used, these options will be ignored. </span># * The format is [host_ip:]host_port:container_port[/protocol]. </span># * Please set these according to what you configured. </span># PublishPort=80:80 </span># PublishPort=443:443 </span># PublishPort=443:443/udp </span># * Persists configuration files. </span>Volume=%h/.local/share/freenginx/conf:/opt/freenginx/conf </span># * Persists logs. </span>Volume=%h/.local/share/freenginx/logs:/opt/freenginx/logs </span># * Persists SSL stuffs. </span>Volume=%h/.local/share/freenginx/ssl:/opt/freenginx/ssl </span># * Example of mounting a named volume. </span># Volume=cloudflared.volume:/opt/cloudflared/shared-volume </span># * Example of mounting a host directory. </span># Volume=/host/dir:/container/dir </span> </span>[Service] </span># * Always restart the container if it stops. </span>Restart=always </span># * Give the container more time to start. </span>TimeoutStartSec=900 </span># * Generate configuration extracting real IP from HTTP headers added by Cloudflare. </span># </span># * If you gate your servers behind Cloudflare, uncomment the following line. </span># ExecStartPre=%h/.local/share/freenginx/scripts/cloudflare-real-ip-helper.sh </span># * For Podman v5.4 or lower, we have to manually specify reload command. </span>ExecReload=/usr/bin/podman exec freenginx /opt/freenginx/sbin/nginx -s reload </span> </span>[Install] </span># * Enable the service to start at boot. </span>WantedBy=default.target </span></code></pre> 基本上, Podman Quadlet systemd 文件可以由 podman run</code> 命令逐参数转换而来, 官方文档也给出了对照表</a>, 编写并不困难.</p> 上面的例子基本上相当于:</p> podman</span></span> run -</span>d</span> --</span>restart</span>=</span>unless-stopped \ </span></span></span> --</span>restart</span>=</span>always \ </span></span></span> --</span>userns</span>=</span>keep-id:uid=65532,gid=65532 \ </span></span></span> --</span>network</span>=</span>host \ </span></span></span> -</span>v</span> ~</span></span>/.local/share/freenginx/conf:/opt/freenginx/conf \ </span></span></span> -</span>v</span> ~</span></span>/.local/share/freenginx/logs:/opt/freenginx/logs \ </span></span></span> -</span>v</span> ~</span></span>/.local/share/freenginx/ssl:/opt/freenginx/ssl \ </span></span></span> --</span>name</span>=</span>"</span>freenginx"</span></span> \ </span></span></span> --</span>replace</span> \ </span></span></span> ghcr.io/han-rs/container-ci-freenginx:latest</span> </span></code></pre> 配置完成后, 可以通过 systemctl --user ${CMD} ${CONTAINER_NAME}.service</code> 来管理该容器, 如:</p> > systemctl --user status freenginx.service </span>● freenginx.service - FreeNGINX Distroless Container Service </span> Loaded: loaded (/home/hantong/.config/containers/systemd/freenginx.container; generated) </span> Active: active (running) since Sat 2026-02-07 19:29:12 CST; 21h ago </span> Invocation: eda008ef44dc4e79b198a0c69a7ca32f </span> Process: 25667 ExecStartPre=/home/hantong/.local/share/freenginx/scripts/cloudflare-real-ip-helper.sh (code=exited, status=0/SUCCESS) </span> Main PID: 25696 (conmon) </span> Tasks: 134 (limit: 4915) </span> Memory: 467M (peak: 3.6G) </span> CPU: 16min 28.154s </span># ... </span></code></pre> 值得指出, 依托于 systemd, 像什么 ExecStartPre</code> 之类的钩子也可以使用了, 不再依赖容器本身去实现这些功能, 这允许容器打包者大幅度简化镜像:</p> > podman images </span>REPOSITORY TAG IMAGE ID CREATED SIZE </span>ghcr.io/han-rs/container-ci-freenginx latest f583dc3c0362 28 hours ago 3.95 MB </span>ghcr.io/han-rs/container-ci-resilio-sync latest af6cae8d5f91 47 hours ago 38.3 MB </span>ghcr.io/han-rs/container-ci-qbittorrent latest 2bf49e5c41e5 2 days ago 45.5 MB </span>ghcr.io/han-rs/container-ci-cloudflared latest a4bbf0388c6b 2 days ago 28 MB </span># ... </span></code></pre> 当然, 还有些注意事项和疑难杂症:</p> 自动启动</p> 需要执行 sudo loginctl enable-linger $USER</code>, 使得 rootless 用户的 systemd 服务能够在用户未登录时也能自动启动并驻留后台.</li> 不需要执行 systemctl --user enable **</code>, Podman 创建的服务被 systemd 视为 “瞬态” (transient) 的.</li> 需要在 Quadlet 配置文件 [Install]</code> 项添加 WantedBy=default.target</code> 使容器自动启动. (存疑</strong>: 是 default.target</code> 还是 multi-user.target</code>, 还是两者均使用? 笔者个人部署时仅使用前者.)</li> </ol> </li> 笔者本人在部署过程中遇到 network-online.target</code> 始终没有 active (systemctl is-active network-online.target</code> 提示 inactive) 的问题, 导致:</p> 容器自动启动会延滞于服务器启动完成很久之后;</li> 启动或重启服务等待很久 (默认 90s 超时), 但能成功;</li> …</li> </ol> 根本原因暂未清楚, 或许是 netplan</code> + systemd-networkd</code> 的问题? 等待进一步研究.</del></p> 参考 https://github.com/containers/podman/issues/24796#issuecomment-2527822425</a>, 给出暂时性的解决方案:</p> sudo sh -c "cat <<EOF > /etc/systemd/system/podman-network-online-dummy.service </span>[Unit] </span>Description=This service simply activates network-online.target </span>After=network-online.target </span>Wants=network-online.target </span> </span>[Service] </span>ExecStart=/usr/bin/echo Activating network-online.target </span> </span>[Install] </span>WantedBy=multi-user.target </span>EOF" </span>sudo systemctl daemon-reload </span>sudo systemctl enable --now podman-network-online-dummy.service </span># Check status </span># sudo systemctl status podman-network-online-dummy.service </span></code></pre> </li> </ol> 其他需要注意的是, 从 Podman v5 开始, podman generate systemd</code> 已经被弃用, 不再推荐使用.</p> 结语</h2> 总的来说, 如果不想折腾, 直接使用 rootful Docker 确实方便, root 解决一切权限问题, 但面对 “飞牛变肥牛”</a> 之类由于厂商漠视安全、产品存在大量安全漏洞不积极修复放任被在野攻击者利用的教训, 对于闭源应用或未得到广泛安全审计的开源应用, 还是建议使用 Rootless Podman 容器化隔离, 并配置 CPU 和内存用量限制; 即便是开源应用, 也建议使用 Rootless Podman 来隔离部署, 以防止由于配置错误或未知漏洞导致的安全问题.</p> 本文是笔者近日在个人存储服务器使用 Rootless Podman 隔离部署应用程序, 尤其是闭源应用程序的过程中总结的经验 (踩坑体验), 分享在此供读者参考, 相关成果开源在以下仓库中:</p> container-ci-freenginx</a></li> container-ci-qbittorrent</a></li> container-ci-cloudflared</a></li> container-ci-resilio-sync</a></li> </ol> 由于笔者水平和精力有限, 文章中难免出现纰漏, 欢迎评论区批评指正、交流分享.</p> 参考文献</h2> 官方文档, 包括但不限于:</p> 官方指引: https://github.com/containers/podman/blob/main/docs/tutorials/rootless_tutorial.md</a></li> 官方常见问题总结: https://github.com/containers/podman/blob/main/rootless.md</a></li> 用户命名空间模式: https://docs.podman.io/en/latest/markdown/podman-run.1.html#userns-mode</a></li> </ol> </li> How does rootless Podman work?</a></p> </li> 探索 Linux Namespace: Docker 隔离的神奇背后</a></p> </li> </ol> 了解和使用 GPG 2026-02-01T00:00:00+00:00 前言</h2> 本文出现的所有命令的示例均在 Debian 13 上操作 GPG (GnuPG</a>) 2.4.7 版本完成. 本文参考、借鉴、总结了大量资料, 在文末给出相关链接, 在此先表达感谢.</p> 基本概念与术语</h2> 密码学基础</h3> 建议阅读『从零开始了解 TLS 1.3 系列笔记 (六) —— 实用密码学之「对称加密、AEAD 与非对称密码学」』</a> 中的非对称密码学 (公钥密码学) 部分, 『从零开始了解 TLS 1.3 系列笔记 (五) —— 实用密码学之「密钥交换, Diffie–Hellman 与后量子加密」』</a> 中的后量子密码学部分, 此处不再赘述.</p> 应当了解:</p> 非对称密码学 (公钥密码学) 的基本概念;</li> RSA 和 ECC 公钥密码系统的基本概念, ECC 公钥密码系统中如 Curve25519 和 X25519 以及 Ed25519 的关系;</li> RSA 和 ECC 公钥密码系统的作用, 如数字签名等;</li> 常见的 EdDSA, 如基于 Curve25519 的 Ed25519, 基于 Curve448 的 Ed448;</li> 常见的 ECDSA, 如 NIST P-256 (secp256r1);</li> ECDSA 和 EdDSA 的区别.</li> </ol> GPG</h3> GPG (GnuPG</a>, GNU Privacy Guard) 是一款自由和开源软件 (FOSS), 通过对各类密码学原语的封装, 遵照 OpenPGP</a> 标准, 实现了加密 (E</strong>crypt)、签名 (S</strong>ign) 和认证 (A</strong>uthenticating) 功能, 以及密钥管理功能 (C</strong>ertify). PGP 早期为一具备类似功能的闭源专有程序1</a></sup>, 虽然如今称呼 PGP 等价于称呼 OpenPGP 了.</p> GPG 生成并管理以下几种公私钥对:</p> 主密钥对</p> 包含主私钥 (sec) 和主公钥 (pub).</p> 虽然可以让主密钥对提供上述全部功能, 但一般不推荐那么做. 相反, 我们推荐仅授予主密钥对以密钥管理功能, 完成密钥准备工作后即离线保存主私钥, 仅在需要时加载, 包括但不限于:</p> 添加或吊销子密钥;</li> 添加、更改或吊销密钥关联身份 (UID);</li> 添加或更改本身或其他子密钥的到期时间;</li> 为了网络信任目的为其他密钥签名, 等.</li> </ol> 后文我们再继续介绍.</p> </li> 子密钥对</p> 包含子私钥 (ssb) 和子公钥 (sub), 按前述用途可细分为 ssb S / A / E, sub S / A / E.</p> 我们推荐为不同用途分别生成子密钥对.</p> </li> </ol> 以下称 “主/子密钥” 时, 均指公钥和私钥的组合, 即密钥对.</p> 安装 GPG</h2> 不再赘述, 现代 Linux 发行版一般默认安装, Windows 系统下可以安装 Kleopatra</a>, 会捎带着安装命令行版本的 GPG. 下面的示例均使用命令行操作.</p> 准备 GPG 密钥</h2> 生成主密钥</h3> 执行 gpg --full-gen-key --expert</code> 进行交互式生成.</p> 选择密钥类型</h4> 出于性能原因, 我们推荐选择 ECC 密钥类型, 除非需要兼容老设备等才选择 RSA. 虽然, ECC 和 RSA 一样并不具备后量子安全性, 但后量子安全的算法目前尚未成熟, OpenPGP 尚未跟进相关进展.</p> 由于我们希望主密钥专用于管理子密钥, 即执行 Certify 的功能, 我们选择 “(11) ECC (set your own capabilities)”, 然后手动设置主密钥功能 (初始时自带 Sign</code> 和 Certify</code> 的功能, 输入 S</code> 关闭签名功能即可, 然后按 Q</code> 保存).</p> Please select what kind of key you want: </span> (1) RSA and RSA </span> (2) DSA and Elgamal </span> (3) DSA (sign only) </span> (4) RSA (sign only) </span> (7) DSA (set your own capabilities) </span> (8) RSA (set your own capabilities) </span> (9) ECC (sign and encrypt) default* </span> (10) ECC (sign only) </span> (11) ECC (set your own capabilities) </span> (13) Existing key </span> (14) Existing key from card </span>Your selection? 11 </span> </span>Possible actions for this ECC key: Sign Certify Authenticate </span>Current allowed actions: Sign Certify </span> </span> (S) Toggle the sign capability </span> (A) Toggle the authenticate capability </span> (Q) Finished </span> </span>Your selection? S </span> </span>Possible actions for this ECC key: Sign Certify Authenticate </span>Current allowed actions: Certify </span> </span> (S) Toggle the sign capability </span> (A) Toggle the authenticate capability </span> (Q) Finished </span> </span>Your selection? Q </span></code></pre> 选择 ECC 曲线</h4> 出于兼容性原因, 我们选择 Curve25519 而不是 Curve448; 出于安全考虑2</a></sup>, 不推荐 NIST 系列曲线、Brainpool 系列曲线或 secp256k1.</p> Please select which elliptic curve you want: </span> (1) Curve 25519 default </span> (2) Curve 448 </span> (3) NIST P-256 </span> (4) NIST P-384 </span> (5) NIST P-521 </span> (6) Brainpool P-256 </span> (7) Brainpool P-384 </span> (8) Brainpool P-512 </span> (9) secp256k1 </span>Your selection? 1 </span></code></pre> 配置有效期</h4> 出于安全考虑, 不建议配置密钥永不过期. 此处我们设置为 4 年.</p> Please specify how long the key should be valid. </span> 0 = key does not expire </span> <n> = key expires in n days </span> <n>w = key expires in n weeks </span> <n>m = key expires in n months </span> <n>y = key expires in n years </span>Key is valid for? (0) 4y </span>Key expires at Fri Feb 1 15:45:55 2030 CST </span>Is this correct? (y/N) y </span></code></pre> 配置 UID</h4> 用户 ID 用于将密钥和真人关联, 同一个主密钥下可以有多个 UID 适应多个身份.</p> GnuPG needs to construct a user ID to identify your key. </span> </span>Real name: Hantong Chen </span>Email address: public-service@7rs.net </span>Comment: 2026 </span>You selected this USER-ID: </span> "Hantong Chen (2026) <public-service@7rs.net>" </span> </span>Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O </span></code></pre> 额外说一句, 大部分情况下别真填自己的真名上去; 此外邮箱至少应该能够收邮件, 后面会用到; 公钥会包含电子邮件地址, 注意隐私和垃圾邮件问题.</p> 配置密码保护</h4> 输入密码, 按 Tab 移动到下一项, 再次输入密码, 按 Tab 移动到 <OK></code> 确认.</p> ┌─────────────────────────────────────────────────────────────┐ </span>│ Please enter the passphrase to │ </span>│ protect your new key │ </span>│ │ </span>│ Passphrases match. │ </span>│ │ </span>│ Passphrase: _______________________________________________ │ </span>│ │ </span>│ Repeat: ___________________________________________________ │ </span>│ ┌─────────────────────────────────────────────────────────┐ │ </span>│ │ │ │ </span>│ └─────────────────────────────────────────────────────────┘ │ </span>│ <OK> <Cancel> │ </span>└─────────────────────────────────────────────────────────────┘ </span></code></pre> 注意不要超时, 输入完毕后等待完成即可:</p> We need to generate a lot of random bytes. It is a good idea to perform </span>some other action (type on the keyboard, move the mouse, utilize the </span>disks) during the prime generation; this gives the random number </span>generator a better chance to gain enough entropy. </span>We need to generate a lot of random bytes. It is a good idea to perform </span>some other action (type on the keyboard, move the mouse, utilize the </span>disks) during the prime generation; this gives the random number </span>generator a better chance to gain enough entropy. </span></code></pre> 小结</h4> 现在, 我们的主密钥就已经生成完毕了:</p> gpg: revocation certificate stored as '/home/hantong/.gnupg/openpgp-revocs.d/6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2.rev' </span>public and secret key created and signed. </span> </span>pub ed25519 2026-02-02 [C] [expires: 2030-02-01] </span> 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2 </span>uid Hantong Chen (2026) <public-service@7rs.net> </span></code></pre> 请务必牢记密码, 后面所有用到私钥的地方都会要求输入密码.</p> 可以使用 gpg --list-keys --keyid-format long</code> 和 gpg --list-secret-keys --keyid-format long</code> 列出所有公钥和私钥:</p> > gpg --list-keys --keyid-format long </span># 略去部分输出 </span>pub ed25519/F95DD10B4BFF68A2 2026-02-02 [C] [expires: 2030-02-01] </span> 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2 </span>uid [ultimate] Hantong Chen (2026) <public-service@7rs.net> </span></code></pre> > gpg --list-secret-keys --keyid-format long </span># 略去部分输出 </span>sec ed25519/F95DD10B4BFF68A2 2026-02-02 [C] [expires: 2030-02-01] </span> 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2 </span>uid [ultimate] Hantong Chen (2026) <public-service@7rs.net> </span></code></pre> 可以看到:</p> 长 ID: 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2</code></li> 短 ID: F95DD10B4BFF68A2</code></li> 主密钥用途: “[C]”</li> 主密钥创建日期: “2026-02-02”</li> 主密钥有效期止: “2030-02-01”</li> UID: 信任状态 (完全信任, “ultimate”), Real Name (“Hantong Chen”), 备注 (“2026”) 和电子邮件 (“public-service#7rs.net”)</li> </ol> 生成子密钥</h3> PKI 体系有证书信任链的存在, GPG 的子密钥机制 (subkey) 承担了类似功能, 即仅当配置了信任主公钥, 才信任主密钥下的子密钥; 吊销主密钥则全部子密钥失去信任; 吊销单个子密钥不影响其他子密钥或主密钥.</p> 我们建议并在前述步骤中配置主密钥仅承担签发的功能, 接下来需要添加子密钥分别承担签名/认证/加密的功能.</p> 使用 gpg --expert --edit-key <key-id></code> 进入编辑模式, 下面是示例操作过程:</p> > gpg --expert --edit-key 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2 </span>gpg (GnuPG) 2.4.7; Copyright (C) 2024 g10 Code GmbH </span>This is free software: you are free to change and redistribute it. </span>There is NO WARRANTY, to the extent permitted by law. </span> </span>Secret key is available. </span> </span>sec ed25519/F95DD10B4BFF68A2 </span> created: 2026-02-02 expires: 2030-02-01 usage: C </span> trust: ultimate validity: ultimate </span>[ultimate] (1). Hantong Chen (2026) <public-service@7rs.net> </span> </span>gpg> addkey </span>Please select what kind of key you want: </span> (3) DSA (sign only) </span> (4) RSA (sign only) </span> (5) Elgamal (encrypt only) </span> (6) RSA (encrypt only) </span> (7) DSA (set your own capabilities) </span> (8) RSA (set your own capabilities) </span> (10) ECC (sign only) </span> (11) ECC (set your own capabilities) </span> (12) ECC (encrypt only) </span> (13) Existing key </span> (14) Existing key from card </span>Your selection? 10 </span>Please select which elliptic curve you want: </span> (1) Curve 25519 default </span> (2) Curve 448 </span> (3) NIST P-256 </span> (4) NIST P-384 </span> (5) NIST P-521 </span> (6) Brainpool P-256 </span> (7) Brainpool P-384 </span> (8) Brainpool P-512 </span> (9) secp256k1 </span>Your selection? 1 </span>Please specify how long the key should be valid. </span> 0 = key does not expire </span> <n> = key expires in n days </span> <n>w = key expires in n weeks </span> <n>m = key expires in n months </span> <n>y = key expires in n years </span>Key is valid for? (0) 4y </span>Key expires at Fri Feb 1 16:22:25 2030 CST </span>Is this correct? (y/N) y </span>Really create? (y/N) y </span>We need to generate a lot of random bytes. It is a good idea to perform </span>some other action (type on the keyboard, move the mouse, utilize the </span>disks) during the prime generation; this gives the random number </span>generator a better chance to gain enough entropy. </span> </span>sec ed25519/F95DD10B4BFF68A2 </span> created: 2026-02-02 expires: 2030-02-01 usage: C </span> trust: ultimate validity: ultimate </span>ssb ed25519/29774A85FD26125D </span> created: 2026-02-02 expires: 2030-02-01 usage: S </span>[ultimate] (1). Hantong Chen (2026) <public-service@7rs.net> </span> </span>gpg> addkey </span>Please select what kind of key you want: </span> (3) DSA (sign only) </span> (4) RSA (sign only) </span> (5) Elgamal (encrypt only) </span> (6) RSA (encrypt only) </span> (7) DSA (set your own capabilities) </span> (8) RSA (set your own capabilities) </span> (10) ECC (sign only) </span> (11) ECC (set your own capabilities) </span> (12) ECC (encrypt only) </span> (13) Existing key </span> (14) Existing key from card </span>Your selection? 11 </span> </span>Possible actions for this ECC key: Sign Authenticate </span>Current allowed actions: Sign </span> </span> (S) Toggle the sign capability </span> (A) Toggle the authenticate capability </span> (Q) Finished </span> </span>Your selection? S </span> </span>Possible actions for this ECC key: Sign Authenticate </span>Current allowed actions: </span> </span> (S) Toggle the sign capability </span> (A) Toggle the authenticate capability </span> (Q) Finished </span> </span>Your selection? A </span> </span>Possible actions for this ECC key: Sign Authenticate </span>Current allowed actions: Authenticate </span> </span> (S) Toggle the sign capability </span> (A) Toggle the authenticate capability </span> (Q) Finished </span> </span>Your selection? Q </span>Please select which elliptic curve you want: </span> (1) Curve 25519 default </span> (2) Curve 448 </span> (3) NIST P-256 </span> (4) NIST P-384 </span> (5) NIST P-521 </span> (6) Brainpool P-256 </span> (7) Brainpool P-384 </span> (8) Brainpool P-512 </span> (9) secp256k1 </span>Your selection? `1 </span>Invalid selection. </span>Your selection? 1 </span>Please specify how long the key should be valid. </span> 0 = key does not expire </span> <n> = key expires in n days </span> <n>w = key expires in n weeks </span> <n>m = key expires in n months </span> <n>y = key expires in n years </span>Key is valid for? (0) 4y </span>Key expires at Fri Feb 1 16:23:08 2030 CST </span>Is this correct? (y/N) y </span>Really create? (y/N) y </span>We need to generate a lot of random bytes. It is a good idea to perform </span>some other action (type on the keyboard, move the mouse, utilize the </span>disks) during the prime generation; this gives the random number </span>generator a better chance to gain enough entropy. </span> </span>sec ed25519/F95DD10B4BFF68A2 </span> created: 2026-02-02 expires: 2030-02-01 usage: C </span> trust: ultimate validity: ultimate </span>ssb ed25519/29774A85FD26125D </span> created: 2026-02-02 expires: 2030-02-01 usage: S </span>ssb ed25519/11E7B3A29E772EB3 </span> created: 2026-02-02 expires: 2030-02-01 usage: A </span>[ultimate] (1). Hantong Chen (2026) <public-service@7rs.net> </span> </span>gpg> addkey </span>Please select what kind of key you want: </span> (3) DSA (sign only) </span> (4) RSA (sign only) </span> (5) Elgamal (encrypt only) </span> (6) RSA (encrypt only) </span> (7) DSA (set your own capabilities) </span> (8) RSA (set your own capabilities) </span> (10) ECC (sign only) </span> (11) ECC (set your own capabilities) </span> (12) ECC (encrypt only) </span> (13) Existing key </span> (14) Existing key from card </span>Your selection? 12 </span>Please select which elliptic curve you want: </span> (1) Curve 25519 default </span> (2) Curve 448 </span> (3) NIST P-256 </span> (4) NIST P-384 </span> (5) NIST P-521 </span> (6) Brainpool P-256 </span> (7) Brainpool P-384 </span> (8) Brainpool P-512 </span> (9) secp256k1 </span>Your selection? 1 </span>Please specify how long the key should be valid. </span> 0 = key does not expire </span> <n> = key expires in n days </span> <n>w = key expires in n weeks </span> <n>m = key expires in n months </span> <n>y = key expires in n years </span>Key is valid for? (0) 4y </span>Key expires at Fri Feb 1 16:23:27 2030 CST </span>Is this correct? (y/N) y </span>Really create? (y/N) y </span>We need to generate a lot of random bytes. It is a good idea to perform </span>some other action (type on the keyboard, move the mouse, utilize the </span>disks) during the prime generation; this gives the random number </span>generator a better chance to gain enough entropy. </span> </span>sec ed25519/F95DD10B4BFF68A2 </span> created: 2026-02-02 expires: 2030-02-01 usage: C </span> trust: ultimate validity: ultimate </span>ssb ed25519/29774A85FD26125D </span> created: 2026-02-02 expires: 2030-02-01 usage: S </span>ssb ed25519/11E7B3A29E772EB3 </span> created: 2026-02-02 expires: 2030-02-01 usage: A </span>ssb cv25519/AE4E4336187491D9 </span> created: 2026-02-02 expires: 2030-02-01 usage: E </span>[ultimate] (1). Hantong Chen (2026) <public-service@7rs.net> </span> </span>gpg> save </span></code></pre> 常用的命令:</p> addkey</code>: 添加子密钥</p> gpg> addkey </span>Please select what kind of key you want: </span> (3) DSA (sign only) </span> (4) RSA (sign only) </span> (5) Elgamal (encrypt only) </span> (6) RSA (encrypt only) </span> (7) DSA (set your own capabilities) </span> (8) RSA (set your own capabilities) </span> (10) ECC (sign only) </span> (11) ECC (set your own capabilities) </span> (12) ECC (encrypt only) </span> (13) Existing key </span> (14) Existing key from card </span>Your selection? </span></code></pre> 子密钥的密钥类型并不要求和主密钥一致, 不过我们沿用 ECC.</p> 对于签名 (S</code>) 用途, 我们选择 ECC (sign only)</code>; 对于认证 (A</code>) 用途, 我们选择 ECC (set your own capabilities)</code>; 对于加密 (E</code>) 用途, 我们选择 ECC (encrypt only)</code>. 接下来的选择 ECC 曲线和配置密钥有效期和配置主密钥时的步骤一致.</p> 特别地, 认证 (A</code>) 用途选择 ECC (set your own capabilities)</code> 时, 类似配置主密钥的密钥用途那样, 一开始会让我们手动选择密钥用途:</p> Possible actions for this ECC key: Sign Authenticate </span>Current allowed actions: Sign </span> </span> (S) Toggle the sign capability </span> (A) Toggle the authenticate capability </span> (Q) Finished </span> </span>Your selection? </span></code></pre> 这里默认情况下是签名用途的, 我们输入 A</code> 添加认证用途, 再输入 S</code> 去掉签名用途, 最后输入 Q</code> 完成用途设置.</p> </li> key <key-id></code>: 选中 <key-id></code> 指示的密钥.</p> 选中时, 密钥前会带有 </code> 号; 再次输入相同 ID 即为取消选中.</p> </li> delkey</code>: 删除子密钥</p> 需要提前选中子密钥.</p> </li> expire</code>: 更改密钥有效期.</p> 需要提前选中子密钥, 否则默认修改主密钥的有效期.</p> </li> save</code>: 保存并退出编辑模式.</p> 千万别忘记执行此命令, 否则前面的操作都白做了.</p> </li> </ol> 导出主密钥吊销证书</h3> 前面生成主密钥时, 还生成了一个吊销证书:</p> gpg: revocation certificate stored as '/home/hantong/.gnupg/openpgp-revocs.d/6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2.rev' </span></code></pre> 吊销证书是需要吊销主密钥但丢失主私钥时的兜底手段, 需要妥善保存.</p> 导出公钥</h3> 执行 gpg --output <pub-key-file> --armor --export <key-id></code> 导出公钥, 例如:</p> > gpg --output 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2.pub --armor --export 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2 </span></code></pre> 此即将 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2</code> 指示的 GPG 密钥的公钥以 ASCII 装甲格式 (--armor</code>, 或者说 PEM 格式, 人类可读) 导出于当前文件夹的 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2.pub</code> 文件中.</p> GPG 导出的公钥包含主公钥和全部的子公钥</strong>, 以及有效期、子密钥吊销信息、UID 等必要信息, 并使用主私钥签名防止被篡改.</p> 导出私钥</h3> 执行 gpg --output <key-file> --armor --export-secret-keys <key-id>!</code> 导出主私钥, 例如:</p> > gpg --output 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2.primary.key --armor --export-secret-keys 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2! </span></code></pre> 此即将 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2</code> 指示的 GPG 密钥的主私钥</strong>以 ASCII 装甲格式导出于当前文件夹的 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2.primary.key</code> 文件中. 注意, 这里的 !</code> 是必须的.</p> 执行 gpg --output <key-file> --armor --export-secret-subkeys <key-id></code> 导出子私钥, 例如:</p> > gpg --output 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2.sub.key --armor --export-secret-subkeys 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2 </span></code></pre> 此即将 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2</code> 指示的 GPG 密钥的全部子私钥</strong>以 ASCII 装甲格式导出于当前文件夹的 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2.sub.key</code> 文件中.</p> 随后离线保存主私钥, 以及备份子私钥, 以转移至其他机器上使用.</p> 删除本机密钥</h3> 在导出密钥后, 我们执行 gpg --delete-secret-keys <key-id></code> 执行交互式删除私钥, 如:</p> > gpg --delete-secret-keys 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2 </span></code></pre> 如果需要在当前机器上使用子密钥, 则只需要删除主私钥, 提示删除子私钥时取消即可. 操作完成后如果你尝试列出私钥, 会发现主私钥已经被移除了 (提示 sec#</code>), 仅剩子私钥, 如:</p> > gpg --list-secret-keys --keyid-format long </span># 略去部分输出 </span>sec# ed25519/F95DD10B4BFF68A2 2026-02-02 [C] [expires: 2030-02-01] </span> 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2 </span>uid [ultimate] Hantong Chen (2026) <public-service@7rs.net> </span>ssb ed25519/29774A85FD26125D 2026-02-02 [S] [expires: 2030-02-01] </span>ssb ed25519/11E7B3A29E772EB3 2026-02-02 [A] [expires: 2030-02-01] </span>ssb cv25519/AE4E4336187491D9 2026-02-02 [E] [expires: 2030-02-01] </span></code></pre> 如果打算在当前机器上彻底删除, 则一路确认删除主私钥和子私钥后, 执行 gpg --delete-keys <key-id></code> 删除公钥, 如:</p> > gpg --delete-keys 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2 </span></code></pre> 小结</h3> 到这里, 我们已经完成了 GPG 密钥生成的全部操作, 没有特殊情况, 可以直接移步应用章节了.</p> 公布 GPG 公钥</h2> 虽然 GPG 采用点对点的信任体系, 没有 PKI 那样的中心化信任机构, 但为了便利起见, 我们仍然可以将公钥上传到公钥服务器 (Key Server), 以便对等方方便获取和信任该公钥.</p> 需要注意, 上传公钥到公钥服务器存在风险</strong>. 首先, 这是不可逆的操作, 一旦上传, 即使后续吊销该密钥, 该密钥仍然可以被下载和使用; 此外, 公钥服务器一般不会删除已经上传的公钥, 即使该公钥已经吊销. 更详细的风险说明参阅『2021 年，用更现代的方法使用PGP（下） - 安全风险和争议，被玩坏的KeyServer』</a>. 除非你非常确定需要上传公钥, 否则不建议上传公钥到公钥服务器.</p> 上传公钥到公钥服务器的命令如下:</p> > gpg --keyserver hkps://keys.openpgp.org --send-keys 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2 </span></code></pre> 吊销 GPG 密钥</h2> 如果一个主/子密钥或者 UID 不再使用了, 将其删除是没有意义的, 因为我们已经将公钥分发给了对等方, 他们仍然会信任该密钥; 此外, 如果私钥泄露, 删除密钥并不能阻止他人继续使用该密钥. 为此, 我们需要吊销该密钥或 UID, 以告知对等方该密钥或 UID 不再可信, 方式包括:</p> 使用前面导出的吊销证书文件吊销主密钥:</p> gpg</span></span> --</span>import</span> <</span>path-to-revocation-certificate-file></span> </span></span></code></pre> </li> 使用主私钥吊销密钥:</p> gpg</span></span> --</span>edit-key</span> <</span>key-id></span> </span></span></code></pre> 在交互式界面中按前面所述选中需要吊销的子密钥, 输入 revkey</code> 吊销; 不选中任何子密钥时即吊销主密钥.</p> </li> </ol> 完成吊销后, 重新导出公钥并分发给对等方即可宣告吊销状态; 如果上传了公钥到公钥服务器, 也需要重新上传吊销后的公钥. 密钥吊销是不可逆的操作, 请谨慎执行.</p> GPG 应用</h2> 下文示例仍然使用前面生成的 GPG 密钥, 信息再次指出如下:</p> 签名用途子密钥 ID: 29774A85FD26125D</code></li> 认证用途子密钥 ID: 11E7B3A29E772EB3</code></li> 加密用途子密钥 ID: AE4E4336187491D9</code></li> </ol> Git commit 签名</h3> 下面是一个简单例子说明如何使用 GPG 签名 Git commit.</p> > export GPG_TTY=$(tty) </span>> cd /tmp </span>> git init ./test-gpg </span>> cd test-gpg </span>> echo "Hello, GPG!" > README.md </span>> git add </span>> git commit -S29774A85FD26125D -m "Initial commit with GPG signature" </span></code></pre> 输入 GPG 密钥密码后, 即可完成签名提交:</p> > git log --show-signature </span>commit 745048eeb6e87f27d5e5a8aa1f6e33f3543b8942 (HEAD -> main) </span>gpg: Signature made Mon Feb 2 17:09:22 2026 CST </span>gpg: using EDDSA key 652C18ED73F115A6F9369B9029774A85FD26125D </span>gpg: Good signature from "Hantong Chen (2026) <public-service@7rs.net>" [ultimate] </span>Author: Hantong Chen <public-service@7rs.net> </span>Date: Mon Feb 2 17:09:22 2026 +0800 </span> </span> Initial commit with GPG signature </span></code></pre> 可以修改 ~/.gitconfig</code> 配置文件, 以便每次提交时自动使用指定的 GPG 密钥签名, 如:</p> [user] </span></span>name</span> =</span></span> Hantong Chen </span>email</span> =</span></span> public-</span>service@7rs</span>.</span>net </span>signingkey</span> =</span></span> 29774A85FD26125D </span></code></pre> 显然, 我们使用的是具备签名 (S</strong>) 用途的子密钥 ID, 后面不再赘述.</p> Github GPG 配置</h4> 打开 Add new GPG key</a> 页面, 填写 Title, 将前面导出的公钥文件内容全部复制粘贴至 Key 的文本框中确认即可. 添加完毕的效果如下图所示:</p> </p> 完成添加后, 如果邮箱还没有在 Github 上添加 (图中可见 Email address 是 Unverified 的) 就去添加一下即可, 和本文无关, 此处不赘述.</p> 一切配置正确后, 带有签名的 commit 即会显示为 Verified (此处随意截取了一个 commit, 非本文生成的 commit):</p> </p> 可以配置 Vigilant mode</code>:</p> </p> 上述流程可能存在时效性, 以官方文档 GitHub Docs: Adding a GPG key to your GitHub account</a> 说明的最新流程为准.</p> Gitea / Forgejo GPG 配置</h4> 打开 https://{YOUR_GIT_SERVER_HOST}/user/settings/keys</a>, 添加 GPG 密钥:</p> </p> 如果 GPG 密钥的电子邮件和当前用户一致电子邮件不匹配, 则会要求执行一次签名确认:</p> > echo "[REDACTED]" \| gpg -a --default-key F95DD10B4BFF68A2 --detach-sig </span>gpg: using "F95DD10B4BFF68A2" as default secret key for signing </span>-----BEGIN PGP SIGNATURE----- </span> </span>[REDACTED] </span>-----END PGP SIGNATURE----- </span></code></pre> 将执行结果 (“-----BEGIN PGP SIGNATURE-----</code>” 和 “-----END PGP SIGNATURE-----</code>” 之间的部分, 包括这两行) 复制粘贴至确认框中完成确认.</p> 疑难杂症</h4> “gpg: signing failed: Inappropriate ioctl for device”</p> 出现该错误时, 一般是因为 GPG_TTY</code> 环境变量未正确设置.</p> 解决方案: 需要执行 export GPG_TTY=$(tty)</code>, 或者添加至 ~/.bashrc</code> 等 shell 配置文件中.</p> </li> “not a tty”</p> 使用 zsh 时, 在 VSCode 远程开发等场景中, 将 export GPG_TTY=$(tty)</code> 添加至 ~/.zshrc</code>, 可能出现 “not a tty” 错误.</p> 解决方案: 需要在 ~/.zshenv</code> 中添加而不是 ~/.zshrc</code>.</p> </li> 其他奇奇怪怪无法弹出 GPG 密码输入窗口的问题.</p> 解决方案: 建议重新打开终端再尝试一下.</p> </li> </ol> 文件加解密</h3> gpg</span></span> [</span>--</span>output <output-</span>file>]</span> --</span>encrypt</span> --</span>recipient</span> <</span>recipient-key-id></span> <</span>input-file></span> </span></span></code></pre> 即: 使用 <recipient-key-id></code> 密钥对的公钥加密 <input-file></code> 文件, 输出加密结果至 <output-file></code>, 如果未指定 --output <output-file></code>, 默认输出至 <input-file>.gpg</code>.</p> gpg</span></span> --</span>output</span> <</span>decrypted-file></span> -</span>-decrypt <</span>encrypted-file></span> </span></span></code></pre> 即: 使用和加密时使用的公钥成对的私钥解密 <encrypted-file></code> 文件, 输出解密结果至 <decrypted-file></code>.</p> 一个例子:</p> > cd /tmp </span>> echo "Hello, GPG file encryption" > secret.test </span>> gpg --output secret.test.gpg --encrypt --recipient AE4E4336187491D9 secret.test </span># 提示输入密码时输入密码; 短时间内重复加密不会再提示输入密码 </span>> gpg --output secret.decrypted.test --decrypt secret.test.gpg </span>gpg: encrypted with cv25519 key, ID AE4E4336187491D9, created 2026-02-02 </span> "Hantong Chen (2026) <public-service@7rs.net>" </span>> cat secret.decrypted.test </span>Hello, GPG file encryption </span></code></pre> 签名和验签</h3> gpg</span></span> --</span>armor</span> [</span>-u <your-</span>key-</span>id>]</span> --</span>output</span> <</span>output-sig-file></span> -</span>-detach-sign <</span>file-to-be-signed></span> </span></span></code></pre> 即: 使用 <your-key-id></code> 密钥对的私钥 (不提供则使用 GPG 配置的默认密钥) 签名 <file-to-be-signed></code> 文件, 生成 PEM 格式的签名 (--armor</code>, -a</code>) 并保存至 <output-sig-file></code> 而不是嵌入待签名的文件内 (--detach-sign</code>).</p> gpg</span></span> [</span>-u <your-</span>key-</span>id>]</span> --</span>verify</span> <</span>sig-file></span> <</span>file-to-be-verified></span> </span></span></code></pre> 即: 使用 <your-key-id></code> 密钥对的公钥 (不提供则自动匹配), 对 <file-to-be-verified></code> 文件, 读取并验证 <sig-file></code> 中的签名, 如果签名有效且文件未被篡改, 则输出 “Good signature” 信息.</p> 一个例子:</p> > cd /tmp </span>> echo "Hello, GPG signing" > signing.test </span>> gpg --armor -u 29774A85FD26125D --output signing.test.sig --detach-sign signing.test </span>> gpg --verify signing.test.sig signing.test </span>gpg: Signature made Mon Feb 2 23:01:40 2026 CST </span>gpg: using EDDSA key 652C18ED73F115A6F9369B9029774A85FD26125D </span>gpg: Good signature from "Hantong Chen (2026) <public-service@7rs.net>" [ultimate] </span></code></pre> 这是相当常见的用途, 例如 Debian 软件包管理系统就使用 GPG 对软件包进行签名, 在早期 HTTPS 并不成熟时用以保证软件包在网络传输时不被篡改:</p> > cat /etc/apt/sources.list.d/debian.sources </span>Types: deb deb-src </span>URIs: http://deb.debian.org/debian </span>Suites: trixie trixie-updates trixie-backports </span>Components: main contrib non-free non-free-firmware </span>Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg </span> </span>Types: deb deb-src </span>URIs: http://deb.debian.org/debian-security </span>Suites: trixie-security </span>Components: main contrib non-free non-free-firmware </span>Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg </span>> gpg --show-keys /usr/share/keyrings/debian-archive-keyring.gpg </span>pub rsa4096 2021-01-17 [SC] [expires: 2029-01-15] </span> 1F89983E0081FDE018F3CC9673A4F27B8DD47936 </span> Revocable by: 80E976F14A508A48E9CA3FE9BC372252CA1CF964 </span> Revocable by: FBFABDB541B5DC955BD9BA6EDB16CF5BB12525C4 </span> Revocable by: 8C823DED10AA8041639E12105ACE8D6E0C14A470 </span> Revocable by: 309911BEA966D0613053045711B4E5FF15B0FD82 </span> Revocable by: C74F6AC9E933B3067F52F33FA459EC6715B0705F </span>uid Debian Archive Automatic Signing Key (11/bullseye) <ftpmaster@debian.org> </span>sub rsa4096 2021-01-17 [S] [expires: 2029-01-15] </span> </span>pub rsa4096 2021-01-17 [SC] [expires: 2029-01-15] </span> AC530D520F2F3269F5E98313A48449044AAD5C5D </span> Revocable by: 80E976F14A508A48E9CA3FE9BC372252CA1CF964 </span> Revocable by: FBFABDB541B5DC955BD9BA6EDB16CF5BB12525C4 </span> Revocable by: 8C823DED10AA8041639E12105ACE8D6E0C14A470 </span> Revocable by: 309911BEA966D0613053045711B4E5FF15B0FD82 </span> Revocable by: C74F6AC9E933B3067F52F33FA459EC6715B0705F </span>uid Debian Security Archive Automatic Signing Key (11/bullseye) <ftpmaster@debian.org> </span>sub rsa4096 2021-01-17 [S] [expires: 2029-01-15] </span># 其余输出省略 </span></code></pre> 可以看到, 该公钥文件包含了多个主密钥, 每个主密钥下有一个签名用途的子密钥.</p> (碎碎念: 本文的写作动机之一就是笔者想自行维护一个 APT 软件源, 对官方源不包含的一些较新的开源软件使用 Github Actions 执行可信自动构建并打包为 deb 包…)</p> 结语</h2> (唉, 年纪大了, 先总结到这里, 假装有个结语吧; 后面看情况增删补改.)</p> 参考资料</h2> 本文参考了大量资料, 在此不完整列出, 以表感谢:</p> 简明 GPG 概念</a></li> 使用 GPG</a></li> val’s Blog - GPG 使用指南</a></li> GPG配置、命令、实例与apt-key密钥测试</a></li> An abridged guide to using ed25519 PGP keys with GnuPG and SSH</a></li> GPG 筆記 - 產生 ECC 金鑰及加解密檔案</a></li> …</li> </ol> WikiPedia: GNU Privacy Guard</a>. ↩</a></p> </li> 参阅 https://safecurves.cr.yp.to/</a>. ↩</a></p> </li> </ol> </footer> TLS 加密 ClientHello (Encrypted Client Hello, ECH) 2025-10-05T00:00:00+00:00 本译文材料参见 [draft-ietf-tls-esni](https://github.com/han-rs/draft-ietf-tls-esni), 手动构建为 HTML. 全文字数颇多, 难免错漏, 还请谅解, 欢迎反馈交流. 混合公钥加密 (hybrid public key encryption, HPKE) 方案 2025-10-05T00:00:00+00:00 本译文材料参见 [draft-irtf-cfrg-hpke](https://github.com/han-rs/draft-irtf-cfrg-hpke), 手动构建为 HTML. 全文字数颇多, 难免错漏, 还请谅解, 欢迎反馈交流. 从零开始了解 TLS 1.3 系列笔记 (六) —— 实用密码学之「对称加密、AEAD 与非对称密码学」 2025-09-17T00:00:00+00:00 一些密码学高频英文术语需要我们了解</p> 加密 (encrypt), 解密 (decrypt)</li> 密文 (ciphertext), 明文 (plaintext)</li> 对称加密 (symmetric encryption), 非对称加密 (asymmetric encryption)</li> “cipher”: 一般指 “加密算法”, 但有些翻译会直译为 “密码”, 需要和 “password” 区分.</li> </ol> </blockquote> 密码学中, 依据加解密密钥是否相同, 可以将加密算法分为对称加密和非对称加密两大类.</p> 对称加密</h2> 对称加密, 即加密和解密使用相同的密钥. 这种加密方式的优点是加解密速度快, 适合处理大量数据. 常见的对称加密算法包括 AES 和 Chacha20 等. 其中绝大多数都是 “块密码算法 (Block Cipher)” 或者叫 “分组密码算法</strong>”, 这种算法一次只能加密固定大小的块</strong> (例如 128 位), 少部分是 “流密码算法</strong> (Stream Cipher)”, 流密码算法允许将数据逐字节地加密为密文流. 可以使用称为分组密码工作模式</em>的技术, 让分组密码算法也能做到流式加密, 我们会在后文详细了解.</p> 用于加密/解密的密钥也被称为共享密钥(需要在通信双方之间共享). 可以是 PSK, 如从密码利用 KDF 派生得到, 或编码为 Base58 / Base64 格式; 或者通过密钥交换方案协商或传输.</p> 小贴士</p> 对称加密所使用的密钥一般是 128 / 192 / 256 位的二进制数据, 直接使用不便于存储和传输, 因此通常会编码为 Base58 / Base64 格式.</p> 原始 (按 HEX 格式给出):</p> 02c324648931b89e3e8a0fc42c96e8e3be2e42812986573a40d46563bceaf75110 </span></code></pre> Base58 编码:</p> pbPRqYDxnKZfs8j4KKiqYmx6nzipAjTJf1oCD1WKgy99 </span></code></pre> Base64 编码:</p> AsMkZIkxuJ4+ig/ELJbo474uQoEphlc6QNRlY7zq91EQ </span></code></pre> </blockquote> 大多数现代对称密钥密码算法都是抗量子的 (quantum-resistant), 当使用长度足够的密钥时 (如 AES-256), 即便是量子计算机也无法破坏其安全性.</p> 对称加密方案</h3> 我们知道, 单纯使用加密算法只能保证数据的安全性, 并不能满足我们对消息真实性、完整性与不可否认性的需求, 因此通常我们会将对称加密算法跟其他算法组合成一个对称加密方案来使用:</p> KDF (如果是密码作 PSK 的模式, 需要使用 KDF 从密码学强度低的密码派生出密码学强度高的伪随机密钥)</li> 分组密码工作模式 (如 CBC 或 CTR) + 消息填充算法 (如 PKCS7): 分组密码算法, 如 AES, 需要借助这两种算法, 才能加密任意大小的数据 (即所谓的数据流). 而一个流密码加密方案本身就能加密任意长度的数据, 因此不需要分组密码模式与消息填充算法.</li> 密码算法.</li> 消息认证算法: 如 HMAC, 用于验证消息的真实性、完整性、不可否认性.</li> </ol> 如 AES-256-CTR-HMAC-SHA256 就表示一个使用 AES-256 与 Counter 分组模式 (CTR) 进行加密, 使用 HMAC-SHA256 进行消息认证的加密方案.</p> 分组密码工作模式</h3> 前面我们提到分组密码工作模式可以让分组密码算法也能加密任意长度的数据. 其中涉及一些概念值得我们了解.</p> 加密方案的名称中就带有具体的分组模式名称, 如:</p> AES-256-GCM - AES 密码算法 + 256 位加密密钥 + Galois Counter Mode (GCM) 分组模式</li> AES-128-CTR - AES 密码算法 + 128 位加密密钥 + Counter (CTR) 分组模式</li> </ul> 分组密码工作模式背后的主要思想是把明文分成多个长度固定的组, 再在这些分组上重复应用分组密码算法进行加密/解密, 以实现安全地加密/解密任意长度的数据. 某些分组模式 (如 CBC) 要求将输入拆分为分组, 并使用填充算法将最末尾的分组填充到块大小, 也有些分组模式 (如 CTR、CFB、OFB、CCM、EAX 和 GCM) 不需要, 因为它们在每个步骤中, 都直接在明文部分和内部密码状态之间执行异或 (XOR) 运算.</p> 使用 “分组模式” 加密大量数据的流程基本如下:</p> 使用加密密钥 + IV (Initialization Vector, 初始向量) 初始化加密算法状态</li> 加密数据的第一个分组</li> 使用加密密钥和其他参数转换加密算法的当前状态</li> 加密下一个分组</li> 再次转换加密状态</li> </ol> 依此类推, 直到处理完所有输入数据. 解密的流程类似.</p> 值得注意的是, 显然, 使用 CTR / GCM 分组模式时, 密文的大小与明文相同</strong>, 必要时应当进行填充 (padding) 以掩盖明文的真实长度.</p> IV</h4> IV 也被称作 salt 或者 nonce</strong>, 通常是一个随机数, 主要作用是往密文中添加随机性, 使同样的明文被多次加密也会产生不同的密文, 从而确保密文的不可预测性.</p> IV 的大小应与密码块大小相同.</p> IV 通常无需保密, 但应当足够随机 (GCM 模式下除外). 绝不允许重用 (nonce 即 number once, 一次性的数字).</p> GCM 分组模式</h4> GCM (Galois Counter Mode) 是一种广泛使用的分组密码工作模式, 结合了 CTR 模式的加密和 Galois 域上的消息认证</strong>. GCM 模式下的 AES 加密过程除了得到密文外, 还会得到一个认证标签</strong> (authentication tag), 一般附在密文后面.</p> AE(AD)</h3> AE(AD) 即 Authenticated Encryption (with Associated Data), (带关联数据的)认证加密, 我们前面已经提到过这个名词, 其包含了 “认证” 和 “加密” 两大部分.</p> 认证 (Authentication): 通常使用 HMAC, Poly1305, 或者 GCM 分组模式自带.</li> 加密 (Encryption): 使用对称加密算法, 如 AES 或 ChaCha.</li> </ol> 正确实现了消息认证的对称加密方案, 如 AES-256-CTR-HMAC-SHA256, AES-128-GCM, AES-256-GCM 或 ChaCha20-Poly1305 等, 均可称为 AE(AD) 加密方案. 今天的大多数应用程序应该优先选用 AEAD 加密方案进行对称加密, 而不是自己造轮子, 由于密码学的复杂性, 自己造轮子往往会出错.</p> 性能小贴士: AES 和 Chacha 怎么选择?</p> 机器 CPU 支持 AES 硬件加速 (大部分现代 CPU 都支持), 使用 AES.</li> 机器 CPU 不支持 AES 硬件加速, 如 2014 年以前的 x86 架构处理器, 或者移动端相当一部分 ARM 架构处理器, 或者路由器所使用的大部分的 MIPS 架构处理器. 此时使用 ChaCha 会更快 (本来就是为移动端特别优化的).</li> 如果机器 CPU 足够现代且性能强劲, AES 和 ChaCha 差别不大, 在 HTTPS 场景下基本不可能是加密能力瓶颈, 任选其一即可.</li> </ol> 如果想测试, 可以尝试运行:</p> openssl</span></span> speed -</span>evp</span> aes-128-gcm</span> </span>openssl</span></span> speed -</span>evp</span> chacha20-poly1305</span> </span></code></pre> 参考输出:</p> ></span> openssl speed</span></span> -</span>evp</span> chacha20-poly1305</span> </span>...</span></span> (略</span></span>) ...</span></span> </span>The</span></span> '</span>numbers'</span></span> are in 1000s of bytes per second processed.</span> </span>type</span></span> 2 bytes 31 bytes 136 bytes 1024 bytes 8192 bytes 16384 bytes</span> </span>ChaCha20-Poly1305</span></span> 135090.41k 398677.07k 685502.68k 4633523.20k 5013787.99k 5053565.35k</span> </span>></span> openssl speed</span></span> -</span>evp</span> aes-128-gcm</span> </span>...</span></span> (略</span></span>) ...</span></span> </span>The</span></span> '</span>numbers'</span></span> are in 1000s of bytes per second processed.</span> </span>type</span></span> 2 bytes 31 bytes 136 bytes 1024 bytes 8192 bytes 16384 bytes</span> </span>AES-128-GCM</span></span> 16855.33k 246339.19k 1061738.45k 4942513.83k 13130011.57k 14806788.78k</span> </span></code></pre> 结果显示, 在笔者的机器上, AES-128-GCM 的加密速度 (14.8 GB/s) 明显快于 ChaCha20-Poly1305 (5.1 GB/s). 然而, 5 GB/s 是 40 Gbps 的网络带宽才能达到的速度了, 还只用到了一个核心.</p> </blockquote> 对称加密算法</h3> 以下列举一些常见的对称加密算法.</p> 安全的:</p> AES (Advanced Encryption Standard, 高级加密标准): 目前最流行的对称加密算法, 由 NIST 于 2001 年发布. 支持 128, 192 和 256 位密钥长度. AES 是一种分组密码算法, 块大小为 128 位, 使用 128 位的 IV. AES-GCM 是目前最常用的对称加密方案之一.</li> ChaCha: Salsa 改进版变种, 包括 Chacha20 等. 使用 128 / 256 位密钥和 64 位 IV. ChaCha20-Poly1305 也是一种流行的对称加密方案, 结合了 ChaCha20 流密码和 Poly1305 消息认证码.</li> 其他: 包括但不限于 RC5, RC6, 韩国的 ARIA (类似 AES), 中国的 SM4 (类似 AES) 等.</li> </ul> 由于出现安全问题已弃用的:</p> DES</li> 3DES</li> RC4</li> Blowfish</li> …</li> </ul> 在介绍完对称加密后, 我们来了解一下非对称加密. 在此之前, 我们先了解一下非对称密码学(公钥密码学)的基本概念.</p> </blockquote> 公钥密码学</h2> 公钥密码系统的密钥始终以公钥/私钥对(密钥对</strong>, Key Pair)的形式出现, 公钥密码系统提供数学框架和算法来生成密钥对. 公钥通常与所有人共享, 而私钥则保密. 公钥密码系统在设计时就确保了在预期的算力下, 几乎不可能从其公开的公钥逆向演算出对应的私钥.</li> 公钥密码系统主要有三大用途: 加密与解密</strong>、签名与验证</strong>、密钥交换</strong>. 每种算法都需要使用到公钥和私钥, 比如由公钥加密的消息只能由私钥解密, 由私钥签名的消息需要用公钥验证. 由于加密解密、签名验证均需要两个不同的密钥, 故公钥密码学也被称为非对称密码学.</li> </ol> 比较著名的公钥密码系统有: RSA、ECC、(EC)DH. 不同的公钥密码系统可以提供以下一项或多项功能:</p> 执行密钥对生成: 随机生成私钥和对应的公钥;</li> 执行加解密: 通过公钥加密, 通过私钥解密;</li> 作为密钥交换算法;</li> 执行数字签名 (消息认证): 通过私钥对消息进行签名, 通过公钥验证签名.</li> </ul> 公钥密码系统的密钥交换功能, 我们已经在前面的文章讲述过, 在此不再赘述; 公钥密码系统的数字签名功能, 我们会在后文单独介绍.</p> 非对称加密</h3> 应用公钥密码系统的加(解)密功能即称非对称加(解)密. 非对称加密安全性相对于对称加密高, 但缺点也明显:</p> 算法更为复杂, 加解密速度比对称加密慢非常多.</p> </li> 只能加密/解密很短的消息.</p> 如在 RSA 系统中, 输入消息需要被转换为大整数, 例如使用 OAEP 填充, 然后才能被加密为密文. (密文实质上就是另一个大整数.)</p> 一些非对称密码系统, 如 ECC, 不直接提供加密能力, 需要结合使用更复杂的方案才能实现加解密.</p> </li> </ul> 为此, 现代密码学协议一般混合使用对称加密和非对称加密</strong> 以发挥各自的优势, 如使用非对称加密方案来安全地生成、交换对称加密所需的共享密钥, 然后使用对称加密方案来加密实际的消息内容.</p> KEM: 仅使用非对称加密算法加密另一个密钥, 实际数据的加解密由该密钥完成. 前面介绍 TLS 1.3 后量子密码学改进时提到过 ML-KEM, 这就是一个典型的 KEM.</p> RSA-OAEP, RSA-KEM, ECIES-KEM 和 PSEC-KEM. 都是 KEM 加密方案.</p> </li> IKS: 集成加密方案, 在 KEM 技术上添加 KDF 等其他密码学算法达成更高安全性, 此处不展开.</p> </li> </ol> RSA 公钥密码系统</h3> RSA 密码系统是最早的公钥密码系统之一, 它基于模幂的数学和 RSA 问题的计算难度以及密切相关的整数分解问题 (IFP). RSA 算法以其作者的首字母命名, 并在计算机密码学的早期广泛使用.</p> RSA 密码系统是典型的公钥密码系统, 完整提供了密钥对生成、加解密、密钥交换和数字签名等功能.</p> RSA 私钥长度可以是 1024, 2048, 3072 或 4096 位及更长, 但 3072 位是目前的推荐最小长度, 过长的密钥也会导致加解密速度过慢.</p> 示例</h4> 2048 位 RSA 公钥示例 (表示为 2048 位十六进制整数模数 n 和 24 位公指数 e):</p> n = 0xa709e2f84ac0e21eb0caa018cf7f697f774e96f8115fc2359e9cf60b1dd8d4048d974cdf8422bef6be3c162b04b916f7ea2133f0e3e4e0eee164859bd9c1e0ef0357c142f4f633b4add4aab86c8f8895cd33fbf4e024d9a3ad6be6267570b4a72d2c34354e0139e74ada665a16a2611490debb8e131a6cffc7ef25e74240803dd71a4fcd953c988111b0aa9bbc4c57024fc5e8c4462ad9049c7f1abed859c63455fa6d58b5cc34a3d3206ff74b9e96c336dbacf0cdd18ed0c66796ce00ab07f36b24cbe3342523fd8215a8e77f89e86a08db911f237459388dee642dae7cb2644a03e71ed5c6fa5077cf4090fafa556048b536b879a88f628698f0c7b420c4b7 </span>e = 0x010001 </span></code></pre> 以 RSA PKCS#8 PEM ASN.1 格式编码:</p> -----BEGIN PUBLIC KEY----- </span>MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApwni+ErA4h6wyqAYz39p </span>f3dOlvgRX8I1npz2Cx3Y1ASNl0zfhCK+9r48FisEuRb36iEz8OPk4O7hZIWb2cHg </span>7wNXwUL09jO0rdSquGyPiJXNM/v04CTZo61r5iZ1cLSnLSw0NU4BOedK2mZaFqJh </span>FJDeu44TGmz/x+8l50JAgD3XGk/NlTyYgRGwqpu8TFcCT8XoxEYq2QScfxq+2FnG </span>NFX6bVi1zDSj0yBv90uelsM226zwzdGO0MZnls4AqwfzayTL4zQlI/2CFajnf4no </span>agjbkR8jdFk4je5kLa58smRKA+ce1cb6UHfPQJD6+lVgSLU2uHmoj2KGmPDHtCDE </span>twIDAQAB </span>-----END PUBLIC KEY----- </span></code></pre> 2048 位 RSA 私钥示例, 对应于上述给定的公钥 (表示为十六进制 2048 位整数模数 n 和 2048 位秘密指数 d):</p> n = 0xa709e2f84ac0e21eb0caa018cf7f697f774e96f8115fc2359e9cf60b1dd8d4048d974cdf8422bef6be3c162b04b916f7ea2133f0e3e4e0eee164859bd9c1e0ef0357c142f4f633b4add4aab86c8f8895cd33fbf4e024d9a3ad6be6267570b4a72d2c34354e0139e74ada665a16a2611490debb8e131a6cffc7ef25e74240803dd71a4fcd953c988111b0aa9bbc4c57024fc5e8c4462ad9049c7f1abed859c63455fa6d58b5cc34a3d3206ff74b9e96c336dbacf0cdd18ed0c66796ce00ab07f36b24cbe3342523fd8215a8e77f89e86a08db911f237459388dee642dae7cb2644a03e71ed5c6fa5077cf4090fafa556048b536b879a88f628698f0c7b420c4b7 </span>d = 0x10f22727e552e2c86ba06d7ed6de28326eef76d0128327cd64c5566368fdc1a9f740ad8dd221419a5550fc8c14b33fa9f058b9fa4044775aaf5c66a999a7da4d4fdb8141c25ee5294ea6a54331d045f25c9a5f7f47960acbae20fa27ab5669c80eaf235a1d0b1c22b8d750a191c0f0c9b3561aaa4934847101343920d84f24334d3af05fede0e355911c7db8b8de3bf435907c855c3d7eeede4f148df830b43dd360b43692239ac10e566f138fb4b30fb1af0603cfcf0cd8adf4349a0d0b93bf89804e7c2e24ca7615e51af66dccfdb71a1204e2107abbee4259f2cac917fafe3b029baf13c4dde7923c47ee3fec248390203a384b9eb773c154540c5196bce1 </span></code></pre> 以传统的 RSA PKCS#1 PEM ASN.1 格式编码, 看起来更长一些:</p> -----BEGIN RSA PRIVATE KEY----- </span>MIIEowIBAAKCAQEApwni+ErA4h6wyqAYz39pf3dOlvgRX8I1npz2Cx3Y1ASNl0zf </span>hCK+9r48FisEuRb36iEz8OPk4O7hZIWb2cHg7wNXwUL09jO0rdSquGyPiJXNM/v0 </span>4CTZo61r5iZ1cLSnLSw0NU4BOedK2mZaFqJhFJDeu44TGmz/x+8l50JAgD3XGk/N </span>lTyYgRGwqpu8TFcCT8XoxEYq2QScfxq+2FnGNFX6bVi1zDSj0yBv90uelsM226zw </span>zdGO0MZnls4AqwfzayTL4zQlI/2CFajnf4noagjbkR8jdFk4je5kLa58smRKA+ce </span>1cb6UHfPQJD6+lVgSLU2uHmoj2KGmPDHtCDEtwIDAQABAoIBABDyJyflUuLIa6Bt </span>ftbeKDJu73bQEoMnzWTFVmNo/cGp90CtjdIhQZpVUPyMFLM/qfBYufpARHdar1xm </span>qZmn2k1P24FBwl7lKU6mpUMx0EXyXJpff0eWCsuuIPonq1ZpyA6vI1odCxwiuNdQ </span>oZHA8MmzVhqqSTSEcQE0OSDYTyQzTTrwX+3g41WRHH24uN479DWQfIVcPX7u3k8U </span>jfgwtD3TYLQ2kiOawQ5WbxOPtLMPsa8GA8/PDNit9DSaDQuTv4mATnwuJMp2FeUa </span>9m3M/bcaEgTiEHq77kJZ8srJF/r+OwKbrxPE3eeSPEfuP+wkg5AgOjhLnrdzwVRU </span>DFGWvOECgYEAyIk7F0S0AGn2aryhw9CihDfimigCxEmtIO5q7mnItCfeQwYPsX72 </span>1fLpJNgfPc9DDfhAZ2hLSsBlAPLUOa0Cuny9PCBWVuxi1WjLVaeZCV2bF11mAgW2 </span>fjLkAXT34IX+HZl60VoetSWq9ibfkJHeCAPnh/yjdB3Vs+2wxNkU8m8CgYEA1Tzm </span>mjJq7M6f+zMo7DpRwFazGMmrLKFmHiGBY6sEg7EmoeH2CkAQePIGQw/Rk16gWJR6 </span>DtUZ9666sjCH6/79rx2xg+9AB76XTFFzIxOk9cm49cIosDMk4mogSfK0Zg8nVbyW </span>5nEb//9JCrZ18g4lD3IrT5VJoF4MhfdBUjAS1jkCgYB+RDIpv3+bNx0KLgWpFwgN </span>Omb667B6SW2ya4x227KdBPFkwD9HYosnQZDdOxvIvmUZObPLqJan1aaDR2Krgi1S </span>oNJCNpZGmwbMGvTU1Pd+Nys9NfjR0ykKIx7/b9fXzman2ojDovvs0W/pF6bzD3V/ </span>FH5HWKLOrS5u4X3JJGqVDwKBgQCd953FwW/gujld+EpqpdGGMTRAOrXqPC7QR3X5 </span>Beo0PPonlqOUeF07m9/zsjZJfCJBPM0nS8sO54w7ESTAOYhpQBAPcx/2HMUsrnIj </span>HBxqUOQKe6l0zo6WhJQi8/+cU8GKDEmlsUlS3iWYIA9EICJoTOW08R04BjQ00jS7 </span>1A1AUQKBgHlHrV/6S/4hjvMp+30hX5DpZviUDiwcGOGasmIYXAgwXepJUq0xN6aa </span>lnT+ykLGSMMY/LABQiNZALZQtwK35KTshnThK6zB4e9p8JUCVrFpssJ2NCrMY3SU </span>qw87K1W6engeDrmunkJ/PmvSDLYeGiYWmEKQbLQchTxx1IEddXkK </span>-----END RSA PRIVATE KEY----- </span></code></pre> RSA 密钥生成</h4> 略, 相关应用参见加密库的文档.</p> RSA 加解密</h4> RSA 一次只能加密/解密一个(大)整数, 一般采用 OAEP 对消息编码为一个个整数再逐个加解密.</p> RSA 签名与验证</h4> 参见后文介绍数字签名算法.</p> ECC 公钥密码系统</h3> ECC 椭圆曲线密码学于 1985 年被首次提出, 并于 2004 年开始被广泛应用. ECC 被认为是 RSA 的继任者, 新一代的非对称加密算法. 其最大的特点在于相同密码强度下, ECC 的密钥和签名的大小都要显著低于 RSA. 256 位的 ECC 密钥, 安全性与 3072 位的 RSA 密钥安全性相当. ECC 的密钥对生成、密钥交换与签名算法的速度都要比 RSA 快.</p> ECC 中的椭圆曲线可以以多种形式呈现, 这些形式被证明是同构</strong>的:</p> 魏尔施特拉斯 (Weierstrass) 形式: 这是最常见的椭圆曲线形式, 其方程为 $y^2=x^3+ax+b$</p> 如: $y^2=x^3+7$ (secp256k1, 加密货币领域常用).</p> 需要指出, NSA 推荐的 secp256r1 (NIST P-256, prime256v1, nist256p1) 和 secp256k1 名称只有一字之差, k 和 r 的不同. 其中 k 表示 Koblitz (ECC 发明人), 而 r 表示随机, 即参数是随机选取的, 但美国国家安全局 NSA 并没有公布随机数的挑选规则, 有质疑称 NSA 可能对随机数动过手脚, 让破解难度大幅降低.</p> </blockquote> </li> 蒙哥马利 (Montgomery) 形式: 其方程为 $By^2=x^3+Ax^2+x$</p> 如 Curve25519: $y^2 = x^3+486662x^2+x$.</p> </li> 爱德华兹 (Edwards) 形式: 其方程为 $x^2+y^2=1+dx^2y^2$</p> 如 Ed448: $x^2+y^2=1-39081x^2y^2$. (也可以写成蒙哥马利形式, 称 Curve448).</p> 一般而言, Edwards 形式性能更好, 如 Ed25519 是基于 Curve25519 同构地 “扭曲” 而来, 专为计算速度优化而设计的.</p> </li> </ul> 我们推荐使用 Curve52219 / Ed25519 以及 Curve448 / Ed448, 其性能和安全性均优于 NSA 推荐的 NIST P-256 (secp256r1), NIST P-384 (secp384r1), NIST P-521 (secp521r1) 等曲线. 参见 https://safecurves.cr.yp.to</a>.</p> 轶事一则</p> 参考: https://www.cnblogs.com/greencollar/p/14363535.html</a></p> Daniel J. Bernstein 是世界著名的密码学家, 他在大学曾经开设过一门 UNIX 系统安全的课程给学生, 结果一学期下来, 发现了 UNIX 程序中的 91 个安全漏洞; 他早年在美国依然禁止出口加密算法时, 曾因为把自己设计的加密算法发布到网上遭到了美国政府的起诉, 他本人抗争六年, 最后美国政府撤销所有指控, 目前另一个非常火的高性能安全流密码 ChaCha20 也是出自 Bernstein 之手.</p> Curve25519 自 2006 年发表以来, 除了学术界无人问津. 但自 2013 年斯诺登曝光棱镜计划后, 该算法突然大火. Curve25519 安全性高, 不同于 NIST 推荐的 P-256 等曲线, Curve25519 的参数是公开透明的, 任何人都可以验证其安全性, 而 NSA 推荐的 NIST P-256 等曲线方程的系数使用了来历不明的随机种子, 在密码学上难以验证其安全性; 此外, Curve25519 的设计也充分考虑了缓存攻击等, 尽可能避免分支跳转, 在实践上安全性也非常高.</p> </blockquote> 数字签名算法 (digital signature algorithm, DSA)</h2> 在密码学中, 数字签名为数字文档提供消息身份验证、完整性和不可否认性. 数字签名基于公钥密码系统, 消息签名由私有密钥执行, 消息验证由相应的公钥执行.</p> 数字签名的过程本质还是加解密, 但是加解密的对象变成了消息的哈希值: 使用私钥签名 (加密哈希值), 公钥验证 (解密后比对实际的哈希值).</p> RSA 数字签名算法</h3> 即使用 RSA 公钥密码系统的数字签名算法.</p> 刚刚好, 哈希值就是一个大整数.</p> </blockquote> ECC 数字签名算法</h3> 即使用 ECC 公钥密码系统的数字签名算法. ECC 相对于 RSA, 在相同的安全强度下, 使用更短的密钥长度, 因此在计算和存储方面更为高效.</p> 常用的 ECC 数字签名算法包括:</p> ECDSA: 在经典 Weierstrass 形式的有限域上使用加密椭圆曲线.</p> 出于特定实体影响, 目前的 ECC 证书一般使用 ECDSA 数字签名算法.</p> 需要指出, DSA 是 digital signature algorithm (数字签名算法) 的缩写, 但也可能特指 FIPS 186 Digital Signature Standard (DSS) 中定义的数字签名算法. 一般地, ECDSA 特指使用了 NIST P-256, NIST P-384 或 NIST P-521 曲线的 NIST DSA 的椭圆曲线实现.</p> </blockquote> </li> EdDSA: 在 Edwards 形式的有限域上使用加密椭圆曲线.</p> 常用变体包括 Ed25519 (使用 Ed25519 曲线, SHA512 哈希算法) 或 Ed448 (使用 Ed448 曲线, SHAKE256 哈希算法).</p> </li> </ol> 我们推荐使用 EdDSA 作为数字签名算法, 原因前面已经提到过.</p> 数字证书</h2> (本节内容大部分摘录自 https://thiscute.world/posts/about-tls-cert</a>) 的总结, 向原作者表示感谢!)</p> 我们已经熟悉了对称密码与非对称密码两个密码学体系:</p> 对称密码算法: 计算速度快、安全强度高, 但是缺乏安全保存、管理乃至交换密钥的手段 (PSK 一旦泄露, 则所有使用该密钥加密的通信均不再安全).</li> 非对称密码算法: 计算速度慢, 但是它给出了安全的密钥交换算法 DHE/ECDHE, 且公钥是可公开的, 这降低了密钥的保存与管理难度.</li> </ul> 但是问题来了:</p> 公钥该如何分发? 比如 Alice 跟 Bob 交换公钥时, 如何确定收到的确实是对方的公钥, 也就是说如何确认公钥的真实性、完整性、认证其来源身份? (DH 是匿名的无认证的, 无法防止中间人攻击)</li> 如果 Alice 的私钥泄漏了, 她该如何作废自己旧的公钥?</li> </ul> 数字证书与公钥基础架构就是为了解决上述问题而设计的.</p> 首先简单介绍下 PKI (Public Key Infrastructure, 公钥基础架构), 它是一组由硬件、软件、参与者、管理政策与流程组成的基础架构, 其目的在于创造、管理、分配、使用、存储以及撤销数字证书. PKI 是一个总称, 而并非指单独的某一个规范或标准, 因此显然数字证书的规范 (X.509)、存储格式等都是 PKI 的一部分.</p> 公钥证书</h3> 前面我们介绍了公钥密码系统存在的一个问题是 “在分发公钥时, 难以确认公钥的真实性、完整性及其来源身份”. PKI 通过数字证书和证书认证机构来解决这个问题.</p> 数字证书指的其实就是公钥证书 (也可直接简称为证书). 在现代网络通讯中通行的公钥证书格式标准名为 X.509 v3, 由 RFC5280</a> 定义, 被广泛应用在 TLS 等众多加密通讯协议中.</p> 一个公钥证书内容应当包括:</p> 证书</p> 序列号 (Serial Number): 用以识别每一张证书, 在作废证书的时候会用到它.</li> 版本: 证书的规范版本.</li> 公钥 (Public Key): 证书所包含的公钥.</li> 公钥指纹: 即公钥的 Hash 值, 当前大部分证书都使用 SHA256 计算此指纹.</li> 公钥用途 (Key Usage + Extended Key Usage): 记录了此证书可用于哪些用途, 如数字签名、身份认证等.</li> 主体 (Subject): 即姓名、组织、邮箱、地址等证书拥有者的个人信息.</li> 证书有效期的开始时间、结束时间 (Not Before + Not After): 为了确保安全性, 每个证书都会记录一个自身的有效期.</li> 签发者 (Issuer): 签发此证书的实体.</li> 其他拓展信息.</li> </ul> </li> 数字签名 (Signature): 对整个证书计算数字签名, 来确保这些数据的真实性、完整性, 确保证书未被恶意篡改/伪造.</p> 此数字签名由证书签发者使用其私钥+证书内容计算得出.</p> </li> 数字签名算法 (Signature Algorithm): 证书所使用的签名算法, 常用的有 RSA-SHA-256 与 ECDSA-SHA-256.</p> </li> </ul> 每个证书都有唯一的 ID, 这样在私钥泄漏的情况下, 我们可以通过公钥基础设施的 OCSP (Online Certificate Status Protocol) 协议吊销某个证书. 吊销证书的操作还是比较罕见的, 毕竟私钥泄漏并不容易遇到, 因此这里就略过不提了, 有需要的可以自行搜索.</p> 感兴趣的, 可以使用浏览器查看证书详情的功能查看一下自己常用网站的证书, 了解一下证书的具体内容, 这里是旧版 Firefox 查看谷歌网站的示例:</p> </div> 证书签发机构 (CA) 与证书链</h3> 前面介绍证书内容时, 提到了签发者会使用签发者私钥和证书内容生成数字签名, 显然需要使用签发者公钥来验证被签发证书中的签名. 但是问题又来了, 签发者的公钥该如何分发? 这不又回到了最初的问题吗?</p> 为此, PKI 引入了一个可信第三方 (Trusted third party, TTP) 来解决这个问题.</p> 在 Alice 与 Bob 的案例中, 就是说还有个可信第三方 Eve, 他使用自己的私钥为自己的公钥证书签了名, 生成了一个自签名</em>证书, 并且已经提前将这个自签名证书分发(比如当面交付、预置在操作系统中等手段)给了 Alice 跟 Bob.</p> 现在 Alice 首先使用自己的公钥以及个人信息制作了自己的公钥证书, 但是这个证书还缺乏一个 Issuer 以及数字签名.</p> </li> Alice 找到 Eve, 将这个 CSR 文件提交给 Eve, 希望 Eve 为自己的证书签名. 此时, 我们称之为提交CSR</strong> (Certificate Signing Request, CSR)</p> </li> Eve 验证了 Alice 的身份后, 再使用这个 CSR 签发出完整的证书文件 (Issuer 就填 Eve, 然后 Eve 使用自己的私钥计算出证书的数字签名, 这样就得到了最终的证书), 交付给 Alice.</p> Eve 曾经 “跨越千里之遥”, 将自己的公钥证书分发给了 Bob, 所以在给 Alice 签发证书时, 他显然可能会要求 Alice 给付签名费</em>. 目前许多证书机构就是靠这个赚钱的, 当然也有非盈利的证书颁发机构, 如 ZeroSSL 等 (真的是做慈善么).</p> </li> 现在 Alice 再将经 Eve 签名的证书发送给 Bob</p> </li> Bob 收到证书后, 看到 Issuer 是 Eve, 于是找出以前 Eve 给他的自签名</em>证书, 然后使用其中的公钥验证收到的证书.</p> 如果验证成功, 就说明证书的内容是经过 Eve 认证的. 如果 Eve 没老糊涂了, 那这个证书应该确实就是 Alice 的. 否则, 这是某个攻击者伪造的证书.</p> </li> </ul> 在现实世界中, Eve 这个角色被称作 CA (Certification Authority, 证书认证机构), 全世界只有几十家这样的权威机构, 它们都通过了各大软件厂商的严格审核</em>, 从而将根证书(CA 证书)直接内置于主流操作系统与浏览器中, 也就是说早就提前分发给了因特网世界的几乎所有用户. 由于许多操作系统或软件的更新迭代缓慢, 根证书的有效期通常都在十年以上.</p> 但是, 如果 CA 机构直接使用自己的私钥处理各种证书签名请求, 这将是非常危险的. 因为全世界有海量的 HTTPS 网站, 也就是说有海量的证书需求, 可一共才几十家 CA 机构. 频繁的动用私钥会产生私钥泄漏的风险, 如果这个私钥泄漏了, 那将直接影响海量网站的安全性.</p> PKI 架构使用数字证书链的机制来解决这个问题:</p> </div> CA 机构首先生成自己的根证书与私钥, 并使用私钥给根证书签名</p> 因为私钥跟证书本身就是一对, 因此根证书也被称作自签名证书.</p> </li> CA 交付根证书给各大软硬件厂商, 内置在主流的操作系统与浏览器中.</p> </li> CA 使用私钥签发一些所谓的中间证书, 之后就把私钥雪藏了, 非必要不会再拿出来使用.</p> 根证书的私钥通常离线存储在安全地点; 中间证书的有效期通常会比根证书短一些; 部分中间证书会被作为备份使用, 平常不会启用.</p> CA 机构使用这些中间证书的私钥, 为用户提交的所有 CSR 请求签名.</li> CA 机构也可以使用中间证书的私钥, 为子一级 CA 机构签发中间证书, 形成更长的证书链.</li> 不同 CA 机构也可能执行交叉签名, 共同为对方的中间证书签名. 客户端只要安装有其中任何一个根证书, 就能验证该中间证书.</li> </ul> </li> </ul> 上述这个全球互联网上, 由证书认证机构、操作系统与浏览器内置的根证书、TLS 加密认证协议、OCSP 证书吊销协议等等组成的架构, 我们可以称它为 Web PKI</strong>.</p> Web PKI 通常是可信</em>的, 但是并不意味着它们可靠</em>.</p> 可以说, 谁掌握</em>了 CA, 谁就能对如今互联网安全所仰赖的 TLS 通信执行 MitM.</p> </blockquote> 在更高安全性要求的场景中, 搭建私有 PKI 架构是有必要的, 如支付场景下银行 APP 等要求安装特定数字证书, 即安装了一个由支付机构控制的私有 CA 证书, 或者以 U 盾形式存在的硬件介质的证书; 又或者内部通讯系统, 也会使用私有 CA 证书来签发内部服务器的证书. 这种情况下, 私有 CA 证书需要被提前手动安装在客户端设备上, 否则会提示不受信任的证书错误.</p> TLS 证书主体 (Subject)</h3> TLS 证书的主体字段包含了证书持有者的身份信息, 我们主要关注其中的通用名称 (Common Name, CN) 和主体备用名称 (Subject Alternative Name, SAN).</p> CN 是证书的 “主域名”, SAN 则是该证书所覆盖的所有域名或 IP 地址. 由于 CN 字段只能有一个, 无法满足单证书保护多个子域的需求, 实际上已被弃用, 我们通过 SAN 字段来指定证书所覆盖的域名/IP 地址.</p> 一般地, 我们使用的证书均为域名证书, 但也有 IP 证书 (只能是公网 IP, 难以自动化申请, 而且收费一般不便宜, 目前应该只有 ZeroSSL 提供了免费</em>的 IP 证书), 如著名的 https://1.1.1.1</code>.</p> SAN 支持配置泛域名, 即 .example.com</code> 的形式, 但不支持多级泛域名, 即 ..example.com</code> 的形式; .example.com</code> 只能匹配到同级子域名 a.example.com</code>, 不能匹配 a.b.example.com</code> 等.</p> SAN 可以设置很多个, 如:</p> </div> 补充内容: 证书以及公私钥的(文本)编码</h2> 由于历史原因, 实践上对证书以及公私钥的存储格式可谓五花八门, 这里参考了 RFC 7468 以及 https://thiscute.world/posts/about-tls-cert/#pki</a>, 试图做一个实用意义上比较全面的总结.</p> 基本概念</h3> X.509: PKI 标准, 规定了证书应该包含哪些信息 (但是未定义证书该如何存储). PKIX 即 “Public Key Infrastructure X.509”.</p> </li> ASN.1 (Abstract Syntax Notation One, 抽象语法标记法第 1 部分): 一种用于描述数据结构的标准, 广泛应用于通信协议和加密标准中. ASN.1 定义了数据的语法和语义, 使得不同系统之间能够理解和交换数据. 被应用于 X.509 证书、PKCS 标准等.</p> 感兴趣的, 可以参考 https://letsencrypt.org/zh-cn/docs/a-warm-welcome-to-asn1-and-der/</a> 的总结.</p> </li> DER (Distinguished Encoding Rules, 可辨别编码规则): ASN.1 的一种序列化规则, 用于将 ASN.1 数据结构编码为二进制格式. 定义于 X.690 标准中.</p> DER 编码的证书通常</em>使用 .cer</code> 或 .der</code> 作为文件扩展名, 但也有使用 .crt</code> 的 (RFC 7468 要求使用此拓展名保存文本格式), 更有使用 .cer</code> 保存 PEM 格式的证书的. 在实践上, 尝试以纯文本形式打开看看就知道了.</p> </li> PEM (Privacy-Enhanced Mail, 隐私增强邮件): “隐私增强邮件” 自身已鲜少使用, 但其定义的基于文本的编码格式, 如今被广泛应用于证书(链)和公私钥的文本编码中. PEM 格式可以理解为对 DER 编码的证书或密钥进行 Base64 编码并添加封装边界.</p> </li> PKCS (Public Key Cryptography Standards, 公钥密码学标准).</p> </li> </ol> PEM 格式</h3> (以下来自 RFC7468</a>, 但是由于历史因素, 实践中 PEM 格式的使用也存在不完全符合 RFC 7468 的定义的情况)</p> 文本编码以一行包含 “-----BEGIN </code>”、标签和 “-----</code>” 开始, 并以一行包含 “-----END </code>”、标签和 “-----</code>” 结束. 在这些行 (或称“封装边界“) 之间, 是根据 RFC4648 第 4 节进行 Base64 编码的数据 (PEM RFC1421</a> 称这部分数据为 “封装文本部分”). 封装边界之前允许存在数据, 解析器在处理此类数据时绝不能</strong>出错. 此外, 解析器必须</strong>忽略空白字符及其他非 Base64 字符, 且必须</strong>支持不同的换行规范.</p> 编码数据的类型由 “-----BEGIN </code>” (前置封装边界) 行中的类型标签决定. 例如, “-----BEGIN CERTIFICATE-----</code>” 表示内容是一个 PKIX 证书. 生成器必须</strong>在 “-----END </code>” (后置封装边界) 行使用与对应 “-----BEGIN </code>” 行相同的标签. 标签由区分大小写的、全大写的零个或多个字符组成; 不得包含连续空格或连字符, 首尾也不得出现空格或连字符. 若标签不匹配, 解析器可以</strong>选择忽略后置封装边界中的标签而非报错: 现存实现中部分要求标签匹配, 部分不作要求.</p> “BEGIN” 或 “END” 与标签之间必须严格用一个空格字符 (SP) 分隔. 封装边界两端的连字符 (即短横线 “-”) 必须正好五个, 不能多也不能少.</p> 标签类型暗示编码数据遵循特定语法. 解析器必须</strong>能够优雅处理不符合规范的数据. 但需注意本文档发布前的解析器或生成器行为并不统一. 合法的解析器可能</strong>将内容解释为其他标签类型, 但应注意安全考量章节讨论的潜在风险. 本文档描述的标签标识的容器格式不与特定加密算法绑定, 这符合算法敏捷性原则. 这些格式采用 RFC5280</a> 第 4.1.1.2 节所述的 ASN.1 AlgorithmIdentifier 结构.</p> 与传统 PEM 编码 RFC1421</a>、OpenPGP ASCII armor 及 OpenSSH 密钥文件格式不同, 文本编码不</em>定义也不允许在数据旁编码头信息. 前置封装边界与 Base64 数据之间允许存在空白, 但生成器绝不能</strong>产生此类空白 (保留此空白区域是对 PEM “封装头部分” 定义的沿袭).</p> PKCS #1 标准</h3> 专用于编码 RSA 公私钥, PEM 标签为 “RSA PUBLIC KEY” 和 “RSA PRIVATE KEY”.</p> 示例:</p> -----BEGIN RSA PUBLIC KEY----- </span>MIIBCgKCAQEApwni+ErA4h6wyqAYz39pf3dOlvgRX8I1npz2Cx3Y1ASNl0zfhCK+ </span>9r48FisEuRb36iEz8OPk4O7hZIWb2cHg7wNXwUL09jO0rdSquGyPiJXNM/v04CTZ </span>o61r5iZ1cLSnLSw0NU4BOedK2mZaFqJhFJDeu44TGmz/x+8l50JAgD3XGk/NlTyY </span>gRGwqpu8TFcCT8XoxEYq2QScfxq+2FnGNFX6bVi1zDSj0yBv90uelsM226zwzdGO </span>0MZnls4AqwfzayTL4zQlI/2CFajnf4noagjbkR8jdFk4je5kLa58smRKA+ce1cb6 </span>UHfPQJD6+lVgSLU2uHmoj2KGmPDHtCDEtwIDAQAB </span>-----END RSA PUBLIC KEY----- </span></code></pre> -----BEGIN RSA PRIVATE KEY----- </span>MIIEowIBAAKCAQEApwni+ErA4h6wyqAYz39pf3dOlvgRX8I1npz2Cx3Y1ASNl0zf </span>hCK+9r48FisEuRb36iEz8OPk4O7hZIWb2cHg7wNXwUL09jO0rdSquGyPiJXNM/v0 </span>4CTZo61r5iZ1cLSnLSw0NU4BOedK2mZaFqJhFJDeu44TGmz/x+8l50JAgD3XGk/N </span>lTyYgRGwqpu8TFcCT8XoxEYq2QScfxq+2FnGNFX6bVi1zDSj0yBv90uelsM226zw </span>zdGO0MZnls4AqwfzayTL4zQlI/2CFajnf4noagjbkR8jdFk4je5kLa58smRKA+ce </span>1cb6UHfPQJD6+lVgSLU2uHmoj2KGmPDHtCDEtwIDAQABAoIBABDyJyflUuLIa6Bt </span>ftbeKDJu73bQEoMnzWTFVmNo/cGp90CtjdIhQZpVUPyMFLM/qfBYufpARHdar1xm </span>qZmn2k1P24FBwl7lKU6mpUMx0EXyXJpff0eWCsuuIPonq1ZpyA6vI1odCxwiuNdQ </span>oZHA8MmzVhqqSTSEcQE0OSDYTyQzTTrwX+3g41WRHH24uN479DWQfIVcPX7u3k8U </span>jfgwtD3TYLQ2kiOawQ5WbxOPtLMPsa8GA8/PDNit9DSaDQuTv4mATnwuJMp2FeUa </span>9m3M/bcaEgTiEHq77kJZ8srJF/r+OwKbrxPE3eeSPEfuP+wkg5AgOjhLnrdzwVRU </span>DFGWvOECgYEAyIk7F0S0AGn2aryhw9CihDfimigCxEmtIO5q7mnItCfeQwYPsX72 </span>1fLpJNgfPc9DDfhAZ2hLSsBlAPLUOa0Cuny9PCBWVuxi1WjLVaeZCV2bF11mAgW2 </span>fjLkAXT34IX+HZl60VoetSWq9ibfkJHeCAPnh/yjdB3Vs+2wxNkU8m8CgYEA1Tzm </span>mjJq7M6f+zMo7DpRwFazGMmrLKFmHiGBY6sEg7EmoeH2CkAQePIGQw/Rk16gWJR6 </span>DtUZ9666sjCH6/79rx2xg+9AB76XTFFzIxOk9cm49cIosDMk4mogSfK0Zg8nVbyW </span>5nEb//9JCrZ18g4lD3IrT5VJoF4MhfdBUjAS1jkCgYB+RDIpv3+bNx0KLgWpFwgN </span>Omb667B6SW2ya4x227KdBPFkwD9HYosnQZDdOxvIvmUZObPLqJan1aaDR2Krgi1S </span>oNJCNpZGmwbMGvTU1Pd+Nys9NfjR0ykKIx7/b9fXzman2ojDovvs0W/pF6bzD3V/ </span>FH5HWKLOrS5u4X3JJGqVDwKBgQCd953FwW/gujld+EpqpdGGMTRAOrXqPC7QR3X5 </span>Beo0PPonlqOUeF07m9/zsjZJfCJBPM0nS8sO54w7ESTAOYhpQBAPcx/2HMUsrnIj </span>HBxqUOQKe6l0zo6WhJQi8/+cU8GKDEmlsUlS3iWYIA9EICJoTOW08R04BjQ00jS7 </span>1A1AUQKBgHlHrV/6S/4hjvMp+30hX5DpZviUDiwcGOGasmIYXAgwXepJUq0xN6aa </span>lnT+ykLGSMMY/LABQiNZALZQtwK35KTshnThK6zB4e9p8JUCVrFpssJ2NCrMY3SU </span>qw87K1W6engeDrmunkJ/PmvSDLYeGiYWmEKQbLQchTxx1IEddXkK </span>-----END RSA PRIVATE KEY----- </span></code></pre> 如今已经统一转向使用 PKCS #8 格式保存私钥, 公钥则按 RFC7468</a> Section 13 所述的格式保存.</p> ANSI X9.62 (ITU-T X.894) 标准</h3> 类似 PKCS #1 标准, 但此标准仅用于编码 ECC 私钥, PEM 标签为 “EC PRIVATE KEY”.</p> 示例 (使用 openssl ecparam -name secp384r1 -genkey -noout -out privkey.pem</code> 生成):</p> -----BEGIN EC PRIVATE KEY----- </span>MIGkAgEBBDDhhKJcKC7jnRbKLYKAzY1f/9aC9JGGuqqo2d4FejHSi/TOZiLf3JhP </span>xAb+IJdQYEqgBwYFK4EEACKhZANiAARPyjgUZlw+IWfP/+PD8m1HZRWbEvUB+ai9 </span>pTV63SI7MWw5OzM3qKwTUNP+NK3xFt14A5lJwFMzl5AB7QhJYarW5ra3e2yhP8Vn </span>oC9E7Om31FLwVX+AHTM4Rg0ZQQoqH0c= </span>-----END EC PRIVATE KEY----- </span></code></pre> 类似地, 如今已经统一转向使用 PKCS #8 格式保存私钥.</p> PKCS #7 / CMS 标准</h3> PKCS #7 / CMS, 是一个多用途的证书描述格式. 它包含一个数据填充规则, 这个填充规则常被用在需要数据填充的分组加密、数字签名等算法中.</p> 由于历史原因, 有使用 PKCS #7 标准保存证书的, 后缀通常使用 .p7b</code> 或者 .p7c</code>, 可以使用 DER 或 PEM 格式保存:</p> </div> 以下内容摘抄自 RFC7468</a> Section 8 和 Section 9.</p> </blockquote> PKCS #7 加密消息语法结构使用 “PKCS7” 标签进行编码. 编码内容必须</strong>是 BER (强烈推荐 DER 格式) 编码的 ASN.1 ContentInfo 结构, 如 RFC2315</a> 所述.</p> -----BEGIN PKCS7----- </span>MIHjBgsqhkiG9w0BCRABF6CB0zCB0AIBADFho18CAQCgGwYJKoZIhvcNAQUMMA4E </span>CLfrI6dr0gUWAgITiDAjBgsqhkiG9w0BCRADCTAUBggqhkiG9w0DBwQIZpECRWtz </span>u5kEGDCjerXY8odQ7EEEromZJvAurk/j81IrozBSBgkqhkiG9w0BBwEwMwYLKoZI </span>hvcNAQkQAw8wJDAUBggqhkiG9w0DBwQI0tCBcU09nxEwDAYIKwYBBQUIAQIFAIAQ </span>OsYGYUFdAH0RNc1p4VbKEAQUM2Xo8PMHBoYdqEcsbTodlCFAZH4= </span>-----END PKCS7----- </span></code></pre> 标签 “CERTIFICATE CHAIN” 曾用于表示仅包含证书列表的退化 (degenerated) PKCS #7 结构 (参见 RFC2315</a> 第 9 节). 多个现代工具已不再支持此标签. 生成器绝不能</strong>生成 “CERTIFICATE CHAIN” 标签. 解析器绝不能</strong>将 “CERTIFICATE CHAIN” 视为等同于 “PKCS7”. PKCS #7 是一个已被 CMS RFC5652</a> 长期取代的旧规范. 在 CMS 可作为替代方案时, 实现绝不能</strong>生成 PKCS #7.</p> CMS 结构使用 “CMS” 标签进行编码. 编码内容必须</strong>是 BER (强烈推荐 DER 格式) 编码的 ASN.1 ContentInfo 结构, 如 RFC5652</a> 所述.</p> -----BEGIN CMS----- </span>MIGDBgsqhkiG9w0BCRABCaB0MHICAQAwDQYLKoZIhvcNAQkQAwgwXgYJKoZIhvcN </span>AQcBoFEET3icc87PK0nNK9ENqSxItVIoSa0o0S/ISczMs1ZIzkgsKk4tsQ0N1nUM </span>dvb05OXi5XLPLEtViMwvLVLwSE0sKlFIVHAqSk3MBkkBAJv0Fx0= </span>-----END CMS----- </span></code></pre> CMS 是 IETF 对 PKCS #7 的继承. RFC5652</a> 第 1.1.1 节描述了自 PKCS #7 v1.5 以来的变更. 实现方案在可选时必须</strong>生成 CMS 格式, 以促进互操作性和前向兼容性.</p> PKCS #8 标准</h3> 此标准专用于编码私钥, 且允许对私钥加密, 是现代非对称密钥存储的事实标准.</p> 私钥建议使用 .key</code> 作为文件扩展名, 但也有相当一部分人使用通用拓展名 .pem</code> 的.</p> 可以使用 openssl pkcs8 -topk8 -inform PEM -in private-key.pem -outform PEM -nocrypt -out private-key-pkcs8.pem</code> 来将传统私钥转换为 PKCS #8 格式.</p> 以下内容摘抄自 RFC7468</a> Section 10 和 Section 11.</p> </blockquote> 未加密的 PKCS #8 私钥信息语法结构 (PrivateKeyInfo, 现更名为非对称密钥包 OneAsymmetricKey) 使用 “PRIVATE KEY” 标签编码. 编码内容必须</strong>是 BER (强烈推荐 DER 格式) 编码的 ASN.1 PrivateKeyInfo 结构, 如 PKCS #8 RFC5208</a> 所述, 或 OneAsymmetricKey 结构, 如 RFC5958</a> 所述. 两者语义相同, 可通过版本号区分.</p> -----BEGIN PRIVATE KEY----- </span>MIGHTAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQglQanBRiYVPX7F2Rd </span>4CqyjEN0K4qfHw4tM/yMIh21wamhRANCAARsxaI4jT1b8zbDlFziuLngPcExbYzz </span>ePAHUmgWL/ZCeqlODF/l/XvimkjaWC2huu1OSWB9EKuG+mKFY2Y5k+vF </span>-----END PRIVATE KEY----- </span></code></pre> 加密的 PKCS #8 私钥信息语法结构 (EncryptedPrivateKeyInfo, RFC5958</a> 中名称相同) 使用 “ENCRYPTED PRIVATE KEY” 标签编码. 编码内容必须</strong>是 BER (强烈推荐 DER 格式) 编码的 ASN.1 PrivateKeyInfo 结构, 如 PKCS #8 RFC5208</a> 和 RFC5958</a> 所述.</p> -----BEGIN ENCRYPTED PRIVATE KEY----- </span>MIHNMEAGCSqGSIb3DQEFDTAzMBsGCSqGSIb3DQEFDDAOBAghhICA6T/51QICCAAw </span>FAYIKoZIhvcNAwcECBCxDgvI59i9BIGIY3CAqlMNBgaSI5QiiWVNJ3IpfLnEiEsW </span>Z0JIoHyRmKK/+cr9QPLnzxImm0TR9s4JrG3CilzTWvb0jIvbG3hu0zyFPraoMkap </span>8eRzWsIvC5SVel+CSjoS2mVS87cyjlD+txrmrXOVYDE+eTgMLbrLmsWh3QkCTRtF </span>QC7k0NNzUHTV9yGDwfqMbw== </span>-----END ENCRYPTED PRIVATE KEY----- </span></code></pre> PKCS #12 标准</h3> PKCS #12 是一个归档文件格式, 不是文本编码, 但这里也顺带说一下了. 主要用于存储多个私钥及相关的 X.509 证书, 常用拓展名为 .p12</code>, .pfx</code>. 因为保存了私钥, 为了安全性它通常是加密的, 需要解密后才能使用.</p> 安卓开发者应该比较熟悉, APK 签名证书通常就是使用 PKCS #12 格式存储的, 拓展名为 .keystore</code> 或者 .jks</code> 而已.</p> 公钥 (Public Key) PEM 编码标准 (RFC 7468 Section 13)</h3> 公钥信息结构 (SubjectPublicKeyInfo) 使用 “PUBLIC KEY” 标签进行编码. 编码内容必须</strong>是 BER (强烈推荐 DER 格式) 编码的 ASN.1 SubjectPublicKeyInfo 结构, 如 RFC5280</a> 第 4.1.2.7 节所述.</p> -----BEGIN PUBLIC KEY----- </span>MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEn1LlwLN/KBYQRVH6HfIMTzfEqJOVztLe </span>kLchp2hi78cCaMY81FBlYs8J9l7krc+M4aBeCGYFjba+hiXttJWPL7ydlE+5UG4U </span>Nkn3Eos8EiZByi9DVsyfy9eejh+8AXgp </span>-----END PUBLIC KEY----- </span></code></pre> 证书 (Certificate) PEM 编码标准 (RFC 7468 Section 5)</h3> 这里的 “证书”, 指互联网 X.509 公钥基础设施证书及证书吊销列表 (Certificate Revocation Lists, CRL) 规范 RFC5280</a> 中的 “证书”.</p> 以下内容摘抄自 RFC7468</a> Section 5.</p> </blockquote> 5.1. 编码</p> 公钥证书使用 “CERTIFICATE” 标签进行编码.</p> 编码内容必须</strong>是 BER (强烈推荐 DER 格式) 编码的 ASN.1 Certificate 结构, 如 RFC5280</a> 第 4 节所述.</p> -----BEGIN CERTIFICATE----- </span>MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G </span>A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y </span>aXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdudVRMUyBjZXJ0aWZpY2F0 </span>ZSBhdXRob3JpdHkwHhcNMTEwNTIzMjAzODIxWhcNMTIxMjIyMDc0MTUxWjB9MQsw </span>CQYDVQQGEwJCRTEPMA0GA1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2Vy </span>dGlmaWNhdGUgYXV0aG9yaXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdu </span>dVRMUyBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkwWTATBgcqhkjOPQIBBggqhkjOPQMB </span>BwNCAARS2I0jiuNn14Y2sSALCX3IybqiIJUvxUpj+oNfzngvj/Niyv2394BWnW4X </span>uQ4RTEiywK87WRcWMGgJB5kX/t2no0MwQTAPBgNVHRMBAf8EBTADAQH/MA8GA1Ud </span>DwEB/wQFAwMHBgAwHQYDVR0OBBYEFPC0gf6YEr+1KLlkQAPLzB9mTigDMAoGCCqG </span>SM49BAMCA0gAMEUCIDGuwD1KPyG+hRf88MeyMQcqOFZD0TbVleF+UsAGQ4enAiEA </span>l4wOuDwKQa+upc8GftXE2C//4mKANBC6It01gUaTIpo= </span>-----END CERTIFICATE----- </span></code></pre> 以上为示例.</p> 历史上曾使用过 “X509 CERTIFICATE” 标签, 以及较少使用的 “X.509 CERTIFICATE” 标签. 符合本文件的生成器必须</strong>生成 “CERTIFICATE” 标签, 绝不能</strong>生成 “X509 CERTIFICATE” 或 “X.509 CERTIFICATE” 标签. 解析器绝不能</strong>将 “X509 CERTIFICATE” 或 “X.509 CERTIFICATE” 视为等同于 “CERTIFICATE”, 但有效的例外可能是为了向后兼容性 (可能附带警告).</p> 5.2. 说明性文本</p> 已知许多工具在 PKIX 证书的 BEGIN 行之前和 END 行之后会输出说明性文本, 比其他类型的证书更为常见. 如果输出此类文本, 应使其与证书相关, 例如提供证书中关键数据元素的文本表示.</p> Subject: CN=Atlantis </span>Issuer: CN=Atlantis </span>Validity: from 7/9/2012 3:10:38 AM UTC to 7/9/2013 3:10:37 AM UTC </span>-----BEGIN CERTIFICATE----- </span>MIIBmTCCAUegAwIBAgIBKjAJBgUrDgMCHQUAMBMxETAPBgNVBAMTCEF0bGFudGlz </span>MB4XDTEyMDcwOTAzMTAzOFoXDTEzMDcwOTAzMTAzN1owEzERMA8GA1UEAxMIQXRs </span>YW50aXMwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAu+BXo+miabDIHHx+yquqzqNh </span>Ryn/XtkJIIHVcYtHvIX+S1x5ErgMoHehycpoxbErZmVR4GCq1S2diNmRFZCRtQID </span>AQABo4GJMIGGMAwGA1UdEwEB/wQCMAAwIAYDVR0EAQH/BBYwFDAOMAwGCisGAQQB </span>gjcCARUDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDAzA1BgNVHQEE </span>LjAsgBA0jOnSSuIHYmnVryHAdywMoRUwEzERMA8GA1UEAxMIQXRsYW50aXOCASow </span>CQYFKw4DAh0FAANBAKi6HRBaNEL5R0n56nvfclQNaXiDT174uf+lojzA4lhVInc0 </span>ILwpnZ1izL4MlI9eCSHhVQBHEp2uQdXJB+d5Byg= </span>-----END CERTIFICATE----- </span></code></pre> 5.3. 文件扩展名</p> 尽管 PKIX 结构的文本编码可以出现在任何地方, 但已知许多工具在序列化 PKIX 结构时会提供输出此编码的选项. 为了促进互操作性并将 DER 编码与文本编码分开, 证书的文本编码应使用 “.crt” 扩展名. 实现应意识到, 尽管有此建议, 许多工具仍默认使用 “.cer” 扩展名对证书进行此类文本编码.</p> 本节不会以任何方式干扰官方的 application/pkix-cert 注册 RFC2585</a> (其中规定 “每个 ‘.cer’ 文件包含一个 DER 格式编码的证书”), 而仅是阐明一种广泛存在的事实上的替代方案.</p> 证书链 (Certificate chain) 通常是多个证书的集合, 但似乎并没有一个统一的标准来表示它.</p> 实践上, 可以将多个 PEM 编码的证书直接串联在一个文件中, RFC7468</a> 也允许这么干.</p> </blockquote> PKCS #10 标准</h3> 这个标准是为证书请求语法 (Certificate Request Syntax) 准备的, 不过笔者个人没怎么见过, 但还是顺带说一下了.</p> 以下内容摘抄自 RFC7468</a> Section 7.</p> </blockquote> PKCS #10 证书请求使用 “CERTIFICATE REQUEST” 标签进行编码. 编码内容必须</strong>是 BER (强烈推荐 DER 格式) 编码的 ASN.1 CertificationRequest 结构, 如 RFC2986</a> 所述.</p> -----BEGIN CERTIFICATE REQUEST----- </span>MIIBWDCCAQcCAQAwTjELMAkGA1UEBhMCU0UxJzAlBgNVBAoTHlNpbW9uIEpvc2Vm </span>c3NvbiBEYXRha29uc3VsdCBBQjEWMBQGA1UEAxMNam9zZWZzc29uLm9yZzBOMBAG </span>ByqGSM49AgEGBSuBBAAhAzoABLLPSkuXY0l66MbxVJ3Mot5FCFuqQfn6dTs+9/CM </span>EOlSwVej77tj56kj9R/j9Q+LfysX8FO9I5p3oGIwYAYJKoZIhvcNAQkOMVMwUTAY </span>BgNVHREEETAPgg1qb3NlZnNzb24ub3JnMAwGA1UdEwEB/wQCMAAwDwYDVR0PAQH/ </span>BAUDAwegADAWBgNVHSUBAf8EDDAKBggrBgEFBQcDATAKBggqhkjOPQQDAgM/ADA8 </span>AhxBvfhxPFfbBbsE1NoFmCUczOFApEuQVUw3ZP69AhwWXk3dgSUsKnuwL5g/ftAY </span>dEQc8B8jAcnuOrfU </span>-----END CERTIFICATE REQUEST----- </span></code></pre> 标签 “NEW CERTIFICATE REQUEST” 也被广泛使用. 符合本文档的生成器必须</strong>生成 “CERTIFICATE REQUEST” 标签. 解析器可以</strong>将 “NEW CERTIFICATE REQUEST” 视为等同于 “CERTIFICATE REQUEST”.</p> 补充内容 2: An Interface and Algorithms for Authenticated Encryption (RFC 5116)</h2> 为了更好地理解 AEAD, 这里提供 RFC5116</a> 的翻译, 供读者参考学习.</p> </blockquote> 1. 引言</h3> 认证加密 (Authenticated Encryption) 是一种加密形式, 除了为加密的明文提供机密性之外, 还提供了一种检查其完整性和真实性的方法. 带关联数据的认证加密 (Authenticated Encryption with Associated Data), 或简称 AEAD</strong>, 增加了检查某些关联数据 (AD) 的完整性和真实性的能力, 这些关联数据也被称为 “附加认证数据” (AAD</strong>, Additional Authenticated Data), 且未被加密.</p> 2. AEAD 接口</h3> AEAD 算法具有两种操作: 认证加密和认证解密. 这些算法的输入和输出在下面以八位字节字符串的形式定义.</p> 实现可以</strong>接受额外的输入. 例如, 可以提供一个输入来允许用户在不同的实现策略之间进行选择. 然而, 此类扩展绝不能</strong>影响与其他实现的互操作性.</p> 2.1. 认证加密</h4> 认证加密操作具有四个输入, 每个输入都是一个八位字节字符串:</p> 一个秘密密钥 (secret key</strong>) K, 它必须</strong>以均匀随机或伪随机的方式生成.</li> 一个随机数 (nonce</strong>) N. 对于密钥的任何特定值, 提供给认证加密操作不同调用的每个随机数必须</strong>是不同的, 除非每个随机数都是零长度. 能够生成不同随机数的应用程序必须</strong>使用第 3.2 节中定义的随机数形成方法, 并可以使用任何其他满足唯一性要求的方法. 其他应用程序必须</strong>使用零长度随机数.</li> 一个明文 (plaintext) P, 其中包含要要认证且需要被加密的数据.</li> 关联数据 (associated data) A, 其中包含要认证但不需要被加密的数据.</li> </ul> 敲黑板: nonce 必须唯一, 但不必保密.</p> </blockquote> 有一个单一输出:</p> 一个密文 C, 其长度至少与明文一样长, 或者</li> 一个指示请求的加密操作无法执行的指示.</li> </ul> 所有输入和输出都是可变长度的八位字节字符串, 其长度遵守以下限制:</p> 密钥 K 中的八位字节数在 1 到 255 之间. 对于每个 AEAD 算法, K 的长度必须</strong>是固定的. 对于密钥的任何特定值, 要么 1) 提供给认证加密操作不同调用的每个随机数必须是不同的, 要么 2) 每个随机数必须是零长度. 如果使用零长度随机数与特定密钥一起, 则与该密钥一起使用的每个随机数必须具有零长度. 否则, 随机数的八位字节数应为十二 (12). 可以与特定密钥一起使用不同长度的随机数. 有些算法不能与零长度随机数一起使用, 但其他算法可以; 参见第 4 节. 符合推荐随机数长度的应用程序将避免根据所使用的算法构造不同长度的随机数. 此指导有助于将算法特定逻辑保持在应用程序之外.</li> 明文 P 中的八位字节数可以为零.</li> 关联数据 A 中的八位字节数可以为零.</li> 密文 C 中的八位字节数可以为零.</li> </ul> 本规范不对随机数、明文、密文或附加认证数据设置最大长度限制. 然而, 特定 AEAD 算法可以进一步限制这些输入和输出的长度. 特定 AEAD 实现可以进一步限制其输入和输出的长度. 如果特定 AEAD 算法的实现被要求处理超出可接受长度范围的输入, 或超出该实现支持的长度范围的输入, 它必须返回错误代码, 并且不得输出任何其他信息. 特别是, 不得返回部分加密或部分解密的数据.</p> 明文 P 同时提供机密性和消息认证. 当 P 的长度为零时, AEAD 算法充当输入 A 的消息认证码.</p> 关联数据 A 用于保护需要认证但不需要保密的信息. 例如, 在使用 AEAD 保护网络协议时, 此输入可以包括地址、端口、序列号、协议版本号以及其他指示如何处理、转发或处理明文或密文的字段. 在许多情况下, 希望认证这些字段, 尽管它们必须保持明文以允许网络或系统正常运行. 当此数据包含在输入 A 中时, 可以在不将数据复制到明文中提供认证. 秘密密钥 K 不得包含在任何其他输入 (N、P 和 A) 中. (此限制并不意味着必须检查这些输入的值以确保它们不包含匹配密钥的子字符串; 相反, 它意味着密钥不得明确复制到这些输入中. )</p> 敲黑板: TLS 里面, TLS Record 的 TLV 结构, 类型和长度是不能加密的, 故作为 AAD.</p> </blockquote> 随机数在算法内部被认证, 因此没有必要将其包含在 AD 输入中. 如果对应用程序方便, 可以将随机数包含在 P 或 A 中.</p> 随机数可以与密文一起存储或传输, 或者可以在认证解密操作之前立即重建. 只需向解密模块提供足够的信息以允许其构造随机数即可. (例如, 系统可以使用特定格式的序列号作为随机数, 在这种情况下, 可以从密文的顺序推断出来.) 由于认证解密过程会检测不正确的随机数值, 如果随机数被不正确重建并输入到认证解密操作中, 不会导致安全失败. 任何随机数重建方法都需要考虑加密和解密过程之间密文丢失或重新排序的可能性.</p> 应用程序不得假设密文的任何特定结构或格式.</p> 2.2. 认证解密</h4> 认证解密操作具有四个输入: K、N、A 和 C, 如上定义. 它只有一个单一输出, 要么是明文值 P, 要么是一个特殊符号 FAIL, 表示输入不是认证的. 当使用输入 K、N、P 和 A 通过加密操作生成 C (对于 N、P 和 A 的某些值) 时, 密文 C、随机数 N 和关联数据 A 对于密钥 K 是认证的. 认证解密操作将以高概率返回 FAIL, 只要输入 N、P 和 A 是由遵守随机数的对手精心制作的, 且该对手不知道秘密密钥(假设 AEAD 算法是安全的).</p> 2.3. 数据格式</h4> 本文档未指定 AEAD 输入和输出的任何特定编码, 因为编码不影响 AEAD 算法提供的安全服务.</p> 在选择应用程序数据格式时, 应用程序应将密文 C 放置在认证解密操作的其他输入所需的任何其他数据之后. 例如, 如果随机数和密文都出现在数据包中, 前者应先于后者. 此规则有助于 AEAD 算法的高效和简单的硬件实现.</p> 3. AEAD 算法的使用指导</h3> 本节提供必须遵循的建议, 以安全地使用 AEAD 算法.</p> 如果应用程序无法满足随机数生成的唯一性要求, 则它必须使用零长度随机数. 下面定义的随机化或有状态算法适合与此类应用程序一起使用. 否则, 应用程序应使用长度为十二个八位字节的随机数. 由于鼓励算法支持该长度, 应用程序应使用该长度以辅助互操作性.</p> 3.1. Nonce 生成要求</h4> 略, 简要总结: 重复使用 nonce 会有严重的安全问题, 具体因特定 AEAD 算法而异; nonce 必须唯一, 但不必保密, 可以将 nonce 直接附加在密文前面, 又或者像 TLS 那样, 通过握手协商出一个初始值, 然后每次加密时依据顺序号生成.</p> </blockquote> 3.2. 推荐的 Nonce 构造方法</h4> (略)</p> 4. AEAD 算法规范要求</h3> 每个 AEAD 算法必须只接受固定密钥长度 K_LEN 的密钥, 并且不得要求所提供的密钥具有任何特定的数据格式. 需要这种结构 (例如, 包含特定奇偶校验格式子密钥的算法) 的算法将需要在内部提供它.</p> 每个 AEAD 算法必须接受长度在零到 P_MAX Bytes (含零和 P_MAX) 之间的任何明文, 其中 P_MAX 值是该算法特有的. P_MAX 的值必须大于零, 并且应至少为 65536 (2^16) Bytes. 此大小是网络数据包的典型上限. 其他应用程序可能使用更大的 P_MAX 值, 因此通用算法支持更高的值是可取的.</p> 某些 AEAD 算法存在 “漏洞”, 一旦发送了一定数量的消息, 它们就不再安全, 为此, TLS 1.3 引入了 KeyUpdate 机制.</p> </blockquote> 每个 AEAD 算法必须接受长度在零到 A_MAX Bytes (含零和 A_MAX) 之间的任何关联数据, 其中 A_MAX 值是该算法特有的. A_MAX 的值必须大于零, 并且应至少为 65536 (2^16) Bytes. 其他应用程序可能使用更大的 A_MAX 值, 因此通用算法支持更高的值是可取的.</p> 每个 AEAD 算法必须接受长度在 N_MIN 和 N_MAX Bytes (含 N_MIN 和 N_MAX) 之间的任何随机数 (nonce), 其中 N_MIN 和 N_MAX 的值是该算法特有的. N_MAX 和 N_MIN 的值可以相等. 每个算法应接受长度为 12 Bytes 的随机数. 下面描述的随机化或有状态算法的 N_MAX 值可以为零.</p> AEAD 算法可以以任何方式构造其密文输出; 例如, 密文可以包含一个认证标签. 每个算法都应选择一种有利于高效处理的结构. 认证加密算法可以包含或使用随机源, 例如, 用于生成包含在密文输出中的内部初始化向量. 这种 AEAD 算法被称为随机化算法; 但请注意, 只有加密是随机的, 而解密始终是确定性的. 随机化算法的 N_MAX 值可以为零.</p> 认证加密算法可以包含在加密操作的调用之间维护的内部状态信息, 例如, 允许构造用作算法内部随机数的不同值. 这种 AEAD 算法被称为有状态算法. 即使应用程序输入零长度随机数, 此方法也可以用于算法以提供良好的安全性. 有状态算法的 N_MAX 值可以为零.</p> AEAD 算法的规范必须包含上面定义的 K_LEN、P_MAX、A_MAX、N_MIN 和 N_MAX 值. 此外, 它必须指定最大可能密文的八位字节数, 我们将其表示为 C_MAX.</p> 每个 AEAD 算法必须提供一个描述, 说明明文长度与密文长度之间的关系. 这种关系不得依赖于外部参数, 例如认证强度参数 (例如, 认证标签长度). 这种依赖性会通过创建一种情况来使算法的使用复杂化, 即 AEAD 注册表中的信息不足以确保互操作性.</p> 每个 AEAD 算法规范应描述由于意外重复使用随机数值而导致的安全降级.</p> 每个 AEAD 算法规范应提供详细安全分析的参考文献. 本文档未指定特定的安全模型, 因为文献中已使用了几种不同的模型. 安全分析应定义或引用一个安全模型.</p> 如上所述, 随机化或有状态的算法应使用这些术语来描述自己.</p> 5. AEAD 算法</h3> (以下简要总结, 不再翻译原文)</p> K_LEN</th> P_MAX</th> A_MAX</th> N_MIN</th> N_MAX</th> C_MAX</th></tr></thead> 密钥长度</td> 明文最大长度</td> AAD 最大长度</td> Nonce 最低长度</td> Nonce 最大长度</td> 密文最大长度</td></tr> </tbody></table> 单位均为 Bytes (即 <&[u8]>::len</code>).</p> 5.1. AES-128-GCM</h4> K_LEN</th> P_MAX</th> A_MAX</th> N_MIN</th> N_MAX</th> C_MAX</th></tr></thead> 16</td> 2^36 - 31</td> 2^61 - 1</td> 12</td> 12</td> 2^36 - 15</td></tr> </tbody></table> 对于 GCM, C.len = P.len + 16, 多出来的 16 Bytes 是认证标签.</p> </blockquote> GCM 模式下, 加密操作重复使用 nonce 值会严重削弱安全性, 必须保证 nonce 的唯一性.</p> 5.2. AES-256-GCM</h4> 除 K_LEN 为 32 Bytes 外, 其他均与 AES-128-GCM 相同.</p> 5.3. AES-128-CCM</h4> K_LEN</th> P_MAX</th> A_MAX</th> N_MIN</th> N_MAX</th> C_MAX</th></tr></thead> 16</td> 2^24 - 1</td> 2^64 - 1</td> 12</td> 12</td> 2^24 + 15</td></tr> </tbody></table> 对于 CCM, C.len = P.len + 16, 多出来的 16 Bytes 是认证标签.</p> </blockquote> CCM 模式下, 加密操作重复使用 nonce 值会严重削弱安全性, 必须保证 nonce 的唯一性.</p> 5.4. AES-256-CCM</h4> 除 K_LEN 为 32 Bytes 外, 其他均与 AES-128-CCM 相同.</p> 5.5. (非 RFC 5116 所列, 此处简要补充) Chacha20-Poly1305 (RFC 8439)</h4> K_LEN</th> P_MAX</th> A_MAX</th> N_MIN</th> N_MAX</th> C_MAX</th></tr></thead> 32</td> 274,877,906,880 (2^38 - 64)</td> 2^64 - 1</td> 12</td> 12</td> 274,877,906,896 (2^38 - 48)</td></tr> </tbody></table> C.len = P.len + 16, 多出来的 16 Bytes 是认证标签.</p> </blockquote> 类似地, 加密操作重复使用 nonce 值会严重削弱安全性, 必须保证 nonce 的唯一性.</p> 5.6. (非 RFC 5116 所列, 此处简要补充) XChacha20-Poly1305 (draft-irtf-cfrg-xchacha-03)</h4> XChacha20 是 Chacha20 的变种, 使用 192-bit (24 Bytes) 的 nonce.</p> </blockquote> K_LEN</th> P_MAX</th> A_MAX</th> N_MIN</th> N_MAX</th> C_MAX</th></tr></thead> 32</td> ~2^80 (TBD)</td> 2^64 - 1</td> 24</td> 24</td> ~2^80 (TBD)</td></tr> </tbody></table> C.len = P.len + 16, 多出来的 16 Bytes 是认证标签.</p> </blockquote> 类似地, 加密操作重复使用 nonce 值会严重削弱安全性, 必须保证 nonce 的唯一性.</p> 6. IANA Considerations</h3> (略)</p> 7. 其他考虑</h3> 可以使用 encrypt-then-MAC</code> (加密后 MAC) 策略组合加密算法和消息认证码算法提供 AEAD.</p> (其余略)</p> 小结</h2> 阅读完本文, 我们应当已经熟悉了对称加密和非对称密码学(公钥密码学)的基本概念, 以及下面这些术语:</p> RSA 公钥密码系统</li> ECC 公钥密码系统</li> </ol> 使用到的椭圆曲线: Curve25519 / Ed25519, Curve448 / Ed448 等</p> X25519 (ECDH) / X448 (EdDH).</li> ECDSA</li> EdDSA (Ed25519 / Ed448).</li> </ul> 此外, 我们还应熟悉 PEM 格式下证书、公私钥的文本编码方式, 以及其与 DER 的关系.</p> 再有, 我们应当熟悉 AEAD 算法基本流程, 了解 AAD, nonce 的概念与作用, 熟记常用的 AEAD 算法, 铭记对于绝大多数 (本文所列全部) AEAD 算法来说, nonce 必须唯一.</p> 从零开始了解 TLS 1.3 系列笔记 (五) —— 实用密码学之「密钥交换, Diffie–Hellman 与后量子加密」 2025-09-16T00:00:00+00:00 导语</h2> 在密码学中, 密钥建立 (key establishment)</a>, 或称密钥交换</strong> (key exchange, KE), 是一个过程或协议. 通过该过程或协议, 通信双方共享密钥.</p> 密钥交换过程一定基于公私钥加密, 也就是非对称加密, 我们将在后续章节详细介绍.</p> 密钥交换可以分为两类:</p> 在密钥协商</strong>中, 双方都对密钥的生成做出贡献, 因此没有一方能单独决定最终的密钥.</p> 如 Diffie-Hellman 密钥交换协议 (DH), 或 ECDH (Elliptic-Curve DH, 椭圆曲线 DH). 大多数不严谨的场景, 密钥交换和密钥协商指的是一件事.</p> </li> 在密钥传输</strong>中, 一方生成密钥并将其传输给另一方.</p> 如 RSA 密钥交换过程, 一方通过私钥加密随机会话密钥, 并将其发送到另一方, 另一方使用相应公钥将其解密.</p> 由于此过程是静态的, 高度依赖 RSA 的安全性, 在 TLS 1.3 中已被弃用, 即便是 TLS 1.2 中也不推荐使用.</p> </li> </ol> 通过密码学设计, 密钥交换方案 (Key exchange schemes) 允许通信双方安全地交换加密密钥, 通常这个过程发生在加密通讯开始时, 例如在 TLS 握手阶段.</p> 大体上, 密钥协商可以基于匿名(无认证</strong>)的密钥交换协议 (如 DH), 密码或预共享密钥 (pre-shared key, PSK), 数字证书或许多元素的组合. 某些通信协议仅建立并从头到尾使用同一个共享密钥, 而另一些通信协议随着时间的流逝不断更改共享密钥.</p> 小贴士</p> 由于密钥交换协议自身是匿名的, 密钥协商在一些需要消息完整性的场景 (如 TLS) 会配合签名算法组成最终的加密方案, 如 TLS 1.2 的加密套件有 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384</code>, 即:</p> ECDHE: Ephemeral ECDH, 密钥交换方案;</li> ECDSA: 数字签名方案;</li> AES-256-GCM: 对称加密方案;</li> SHA384: 消息摘要算法.</li> </ul> 这里超前提一下, 后面会继续介绍相关内容.</p> </blockquote> Diffie-Hellman 密钥交换 (DHKE)</h2> DHKE 是最早的公钥协议之一, 允许两个没有事先了解的当事方在不安全的渠道上安全地交换共享密钥. 请注意, DHKE 可以对抗嗅探攻击 (即直接读取数据包), 但无法对抗中间人攻击 MitM (无认证, 中间人可以冒充).</p> DHKE 的实现包括经典的基于离散对数的 DH, 和基于椭圆曲线的 ECDH.</p> 从混合颜色解释</h3> </p> 这是来自维基百科的一幅经典图片, 利用混合颜色来解释 DH 的工作原理:</p> Alice 和 Bob 公开同意使用黄色;</li> Alice 选择一个秘密的红色, 并将其与黄色混合, 得到橙色;</li> Bob 选择一个秘密的海洋绿色, 并将其与黄色混合, 得到浅天蓝色;</li> Alice 和 Bob 交换他们混合后的颜色, 我们依然假设混合颜色难以分离出原始颜色;</li> Alice 将 Bob 交换过来的浅天蓝色与她的秘密颜色混合, 得到黄褐色;</li> Bob 将 Alice 交换过来的橙色与他的秘密颜色混合, 也得到黄褐色;</li> </ol> 到此, Alice 和 Bob 都得到了相同的颜色, 即共享密钥, 而中间人 Eve 只能看到黄色, 橙色和浅天蓝色, 无法计算出黄褐色.</p> 经典 DH</h3> 对于传统基于离散对数的 DH, 其过程类似于前面的颜色混合解释.</p> 首先介绍一点数学背景知识:</p> 模幂: 是指求 $g$ 的 $a$ 次幂模 $p$ 的值 $c$ 的过程, 记作 $c = g^a \mod p$, 其中 $p$ 是一个质数;</li> 离散对数, 即模幂的逆运算, 是指已知 $g$, $p$, $c$, 求 $a$ 的过程</li> 模幂运算律: $g^{ab} \mod p = {(g^a \mod p)}^b \mod p$</li> </ol> 模幂过程计算非常快, 然而离散对数求解被认为在 $p$ 足够大的情况下是在现有计算能力下无法完成的, 此即离散对数难题</strong> (discrete logarithm problem, DLP). 经典的 DHKE 就是基于 DLP 设计的.</p> 那么类似地就有 DHKE 的过程:</p> Alice 和 Bob 公开同意使用一个大质数 $p$ 和一个生成元 $g$ (通常 $g$ 是 2 或 5, 不需要很大), 在代码层面是写死的;</li> Alice 选择一个秘密整数 $a$, 并计算 $A = g^a \mod p$, 将 $A$ 发送给 Bob;</li> Bob 选择一个秘密整数 $b$, 并计算 $B = g^b \mod p$, 将 $B$ 发送给 Alice;</li> Alice 收到 $B$ 后, 计算共享密钥 $S_1 = B^a \mod p$;</li> Bob 收到 $A$ 后, 计算共享密钥 $S_2 = A^b \mod p$;</li> </ol> 由模幂的运算律可以找到 $S_1 = S_2$, 即 Alice 和 Bob 都得到了相同的共享密钥 $S$; 而中间人获得 $A$ 和 $B$ 后, 只能通过离散对数求解 $a$ 或 $b$.</p> 在最常见的 DHKE 实现中 (RFC 3526), 基数是 $g = 2$, 模数 $p$ 是一个 1536 到 8192 比特的大质数. 而整数 $A$ $B$ 通常会使用非常大的数字以防范暴力破解. 对于这种离散对数问题 (DLP), 目前还不存在有效的算法.</p> ECDH</h3> ECDH 应用椭圆曲线代替了 DH 中的模幂.</p> 我们依然有运算律:</p> $$(a * G) * b = (b * G) * a$$</p> 其中 $a, b$ 为常数, $G$ 为椭圆曲线上的某一点的坐标 $(x, y)$.</p> 类似地有 ECDH 的过程:</p> Alice 和 Bob 公开同意使用一个椭圆曲线和基点 $G$;</li> Alice 生成一个随机的 ECC 密钥对: $A = a * G$, 将公钥 $A$ 发送给 Bob;</li> Bob 生成一个随机的 ECC 密钥对: $B = b * G$, 将公钥 $B$ 发送给 Alice;</li> Alice 收到 $B$ 后, 计算共享密钥 $S_1 = a * B$;</li> Bob 收到 $A$ 后, 计算共享密钥 $S_2 = b * A$</li> </ol> 显然, $S_1 = S_2$, 即 Alice 和 Bob 都得到了相同的共享密钥 $S$, 而私钥 $a$, $b$ 的安全性, 则类似地由 ECDLP 问题提供保证, 即「通过公开的 $kG$ 以及 $G$ 这两个参数, 目前没有有效的手段能快速求解出 $k$ 的值. 」</p> 示例</h4> 如果读者还是对 (EC)DH 感到陌生, 相信 X25519 这个名字会更熟悉一些, 这是 TLS 1.3 中最常用的密钥交换算法.</p> 以下内容参考自深入理解 X25519</a>, 在此表示感谢.</p> </blockquote> Curve25519 是一种椭圆曲线, 由 Daniel J. Bernstein 在 2005 年设计, 其设计目标是提供高安全性和高性能的椭圆曲线密码学 (ECC) 操作. Curve25519 的名称来源于其使用的素数 $2^{255} - 19$, 该素数定义了曲线所在的有限域. 而 X25519 是基于 Curve25519 的密钥交换协议, 具体来说, X25519 是一种椭圆曲线 Diffie-Hellman (ECDH) 密钥交换协议的实现. 关于 ECC 公钥密码学的更详细内容, 我们将在下一章介绍.</p> 值得记忆的常识:</p> X25519 协议对应的私钥是 32 字节.</li> X25519 协议对应的公钥是 32</strong> 字节.</li> </ol> DHE (Diffie-Hellman Ephemeral, 临时 DH)</h3> 前面介绍的经典 DH 与 ECDH 协议流程, 都是在最开始时交换一次密钥, 之后就一直使用该密钥通讯. 因此如果密钥被破解, 整个会话的所有信息对攻击者而言就完全透明了.</p> 为了进一步提高安全性, 密码学家提出了「完全前向保密 (Perfect Forward Secrecy, PFS)」的概念, 并在 DHKE 与 ECDH 的基础上提出了支持 PFS 的 DHE / ECDHE 协议.</p> PFS 是指长期使用的主密钥泄漏不会导致过去的会话密钥泄漏, 从而保护过去进行的通讯不受密码或密钥在未来暴露的威胁.</p> DHE / ECDHE 协议的流程与前面介绍的 DH / ECDH 类似, 但每次通讯时都会重新生成一对密钥对, 计算出新的共享密钥随密文发送供下一轮使用. 这样即使某次会话的密钥被破解, 也不会影响到之前或之后的会话.</p> (一个小问题: 如果能破解一次, 那么破解下一次应该也不难了?</del>)</p> 量子计算机的影响</h3> 在量子计算机面前, DLP 可以通过 Shor 算法解决, 因此 DH 和 ECDH 在量子计算机面前不再安全. 值得庆幸的是, 当前量子计算机还远未达到能破解这些加密算法的规模, 但从长远来看, 我们需要考虑量子安全的密钥交换算法.</p> 后量子密码学 (Post-Quantum Cryptography, PQC) 应用: 混合密钥交换 (Hybrid Key Exchange)</h2> 相信读者一定提到过 X25519MLKEM768, X25519Kyber768Draft00 这样的名字, 这是 TLS 1.3 中的混合密钥交换方案, 本节简要介绍.</p> </blockquote> 前面提到, 量子计算机的出现对 (EC)DH 的密码学安全保证构成威胁, 因此需要考虑量子安全的密钥交换算法. 目前, NIST 在 FIPS. 203</a> 中标准化了 ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, 基于模格的密钥封装机制), 各大厂商亦跟进用之替代了先前测试阶段的 Kyber (ML-KEM 的前身).</p> 在介绍混合密钥交换之前, 先简要介绍一下 KEM.</p> KEM (Key Encapsulation Mechanism, 密钥封装机制)</h3> 如其名, 密钥封装机制核心就是对密文的封装 (encapsulate) 与解封装 (decapsulate), 示意图如下:</p> </div> 主要流程为:</p> Alice 生成一对公私钥 $(pk, sk)$, 并将公钥 $pk$ 发送给 Bob; 公钥也称封装密钥 (encapsulation key), 私钥也称解封装密钥 (decapsulation key);</li> Bob 使用公钥 $pk$ 执行 Encaps 操作, 获得一个密钥和关联的封装密文</strong>; Bob 将关联密文发送给 Alice, 密钥则作为共享密钥使用;</li> Alice 使用私钥 $sk$ 对关联密文执行 Decaps 解封装操作, 获得共享密钥;</li> </ol> 到此, Alice 和 Bob 得到了相同的共享密钥.</p> 而 ML-KEM 是 KEM 中的一种, 其安全性基于模格 (Module-Lattice) 问题, 目前已知的量子计算机无法有效解决.</p> 稍微跑题, 还有 ML-DSA, 作为数字签名算法 (DSA), 应用于 TLS 证书验证模块 (draft-ietf-tls-mldsa).</p> TLS 1.3 中的混合密钥交换</h3> (也许是)出于兼容性考虑, 目前 TLS 1.3 中的后量子密钥交换方案均以混合密钥交换的形式出现.</p> 感谢 @jschauma 总结的一图流</a>, (图示为 X25519Kyber768, 但其他的基于 ML-KEM 的混合密钥交换方案也是类似的流程):</p> </div> 简单地来说, 就是在原 (EC)DH 的基础上, 额外增加了 KEM 的公钥交换与密文交换过程: 客户端将 PQC 公钥拼接在客户端向服务端共享的 (EC)DH 公钥后, 服务端将封装密文拼接在服务端向客户端共享的 (EC)DH 公钥后, 双方最终将通过 (EC)DH 得到的共享密钥与 KEM 拿到的或解封装出来的共享密钥拼接起来, 就得到了最终的共享密钥, 是不是非常简单粗暴呢.</p> 碎碎念</p> 后量子算法的引入, 直接导致 ClientHello 消息体积暴增, 如 X25519MLKEM768, 会额外多出 32 字节的用于回落的 X25519 公钥, 以及 1184 字节的 ML-KEM-768 的公钥, 加上原有的 500 字节左右, 大概是 1700 字节左右, 已经超过了 IPv4 TCP 最大 MSS (1500 - 20 - 20 = 1460 Bytes) 导致需要分包, 一旦丢包, 握手延迟蹭蹭涨.</p> </div> 即便使用纯 PQC, 也只是堪堪减少 32 Bytes, 于事无补.</p> </blockquote> 小结</h2> 读完本文, 我们应该已经熟悉以下术语及相应的流程:</p> 密钥交换 (Key Exchange, KE)</li> 密钥协商</strong> (Key Agreement)</li> 密钥传输 (Key Transport)</li> Diffie-Hellman (DH</strong>)</li> 椭圆曲线 Diffie-Hellman (ECDH</strong>) Curve25519, X25519</strong></li> secp256r1 (NIST P-256</strong>), etc.</li> </ul> </li> 临时 Diffie-Hellman (DHE</strong>)</li> 完全前向保密 (Perfect Forward Secrecy, PFS)</li> 后量子安全; 密钥封装机制 (Key Encapsulation Mechanism, KEM) ML-KEM (Module-Lattice-based KEM)</li> </ul> </li> 混合密钥交换 (Hybrid Key Exchange)</li> </ul> 从零开始了解 TLS 1.3 系列笔记 (四) —— 实用密码学之「HMAC、HKDF 与安全随机数」 2025-09-15T00:00:00+00:00 导语</h2> MAC (Message Authentication Code, 消息认证码)、HMAC (Hash-based MAC, 哈希消息认证码)和 KDF (Key Derivation</strong> Function, 密钥派生</strong>函数) 在密码学中发挥着重要作用. 让我们解释一下何时需要 MAC, 如何计算 HMAC 以及它与 KDF 的关系.</p> MAC</h3> MAC 由给定密钥和消息计算而来:</p> MAC = f(key, message) </span></code></pre> 通常, 它的表现类似于加密哈希函数:</p> 难以分析</strong>: 密钥或消息的微小变化会生成完全不同的 MAC 值.</li> 不可逆</strong>: 从其哈希值逆向演算出输入值应该是不可行的. 这意味着没有比暴力破解更好的破解方法.</li> 抗碰撞</strong>: 几乎不可能找到具有相同哈希值的两条不同消息.</li> </ul> 例如, MAC 码可以通过 HMAC-SHA256 算法计算, 如下所示:</p> HMAC-SHA256('key', 'some msg') = 32885b49c8a1009e6d66662f8462e7dd5df769a7b725d1d546574e6d5d6e76ad </span></code></pre> MAC 码是数字真实性代码</em> (digital authenticity code), 类似于数字签名 (digital signature), 但具有预共享密钥 (pre-shared key).</p> MAC 算法</h3> 包括但不限于:</p> HMAC</a> (Hash-based MAC, 哈希消息认证码), 如 HMAC-SHA256;</li> KMAC</a> (Keccak-based MAC, 基于 Keccak 的消息认证码);</li> 基于对称密码算法的 MAC, 如 Poly1305</strong></a> (Bernstein 一次性身份验证) 等等.</li> 其他, 如 SipHash</a> (一种快速的、加密的哈希函数, 适用于哈希表).</li> </ul> MAC 主要应用</h3> MAC 码主要用于验证消息未被篡改. 如当通信双方持有相同的共享密钥时, 发送方可以计算消息的 MAC 码并将其附加到消息中; 接收方收到消息后, 使用相同的密钥计算消息的 MAC 码, 并将其与附加的 MAC 码进行比较; 如果两个 MAC 码匹配, 则消息被认为是完整且未被篡改的.</p> 认证加密 (Authenticated Encryption, AE)</h3> 使用 MAC 码的另一种场景是认证加密.</p> 加密方:</p> 首先, 我们派生一密钥.</li> 使用该密钥加密消息.</li> 使用该密钥和原始消息</strong>计算 MAC 码, 并将其附加到第二步的输出中.</li> </ol> 接收方:</p> 使用一密钥解密密文, 此密钥并不一定是正确的.</li> 使用该密钥和解密结果计算 MAC 码, 并将其与附加的 MAC 码进行比较; 如果两个 MAC 码匹配, 则密钥一致, 解密成功且密文未被篡改; 否则, 密钥不正确或密文被篡改.</li> </ol> 背景知识</p> 可能大家并不熟悉 AE 这个术语, 但 AEAD (Authenticated Encryption with Associated Data, 带关联数据的认证加密) 应该就是熟面孔了. AEAD 是 AE 的一种扩展, 允许在认证加密过程中包含未加密的关联数据 (Associated Data, AD), 如路由信息等需要中间盒处理的信息. 例如, TLS 1.3 中使用的 AES-{128\|256}-GCM 和 ChaCha20-Poly1305 都是 AEAD 加密方案, 我们将在介绍对称加密方案时再提到.</p> </blockquote> 由此, 我们同时验证了通信双方持有相同的共享密钥 (即认证, AE 代表 Authenticated Encryption, 经过认证的加密), 以及消息未被篡改 (完整性).</p> 基于 MAC 的伪随机生成函数 (PRF, Pseudo-Random Function)</h3> MAC 码的另一个应用是作 PRF. 我们可以从某个盐和一个随机数(种子)开始.我们可以计算 next_seed</code> 如下:</p> next_seed = MAC(salt, seed) </span></code></pre> 每次计算上述公式后, 下一个伪随机数都会被 “随机变化”, 我们可以用它来生成一定范围内的下一个随机数.</p> HMAC 和密钥派生</h2> 简单计算 MAC = H(key \|\| msg)</code> 来获取 MAC 被认为是不安全的</a>. 建议改用 HMAC 算法, 例如 HMAC-SHA256.</p> 背景知识</p> 大多数哈希函数存在长度拓展攻击, 即在不知道密钥的情况下, 可以通过已知的 H(key \|\| msg)</code> 来计算有效的 H(key \|\| msg \|\| extra)</code>;</li> 计算 MAC = H(msg \|\| key)</code>, 则存在哈希冲突的可能性;</li> 计算 MAC = H(key \|\| msg \|\| key)</code> 仍然被证明是不安全的;</li> HMAC 计算 HMAC = H(key \|\| H(key \|\| msg))</code>, 采用双重哈希, 消除 msg 长度影响, 目前尚未被证明不安全; 对于 SHA-3 (Keccak) 则不需要双重哈希, 只需 HMAC = H(key \|\| msg)</code>, 因为 SHA-3 不易受长度拓展攻击.</li> </ol> </blockquote> 什么是 HMAC</a></h3> HMAC (Hash-based Message Authentication Code, 哈希消息认证码) 是一种基于哈希函数的 MAC 算法. 它使用一个密钥和一个消息, 通过两次哈希计算得到 MAC 码.</p> $$\operatorname {HMAC} (K,m)=\operatorname {H} {\Bigl (}{\bigl (}K’\oplus opad{\bigr )}\parallel \operatorname {H} {\bigl (}\left(K’\oplus ipad\right)\parallel m{\bigr )}{\Bigr )}$$</p> 其中:</p> $\operatorname {H}$ 是 HMAC 过程所使用的加密哈希函数, 如 SHA-256;</li> $m$ 是消息;</li> $K$ 是一个密钥;</li> $K’$ 是密钥 $K$ 经过右侧补 0 填充或哈希后(必要时右侧补 0)的结果, 以确保其长度等于哈希函数的块大小 (block size);</li> $ipad$ 和 $opad$ 分别是内填充 (inner padding) 和外填充 (outer padding), 长度与块大小相同, 分别由值为 0x5c, 0x36 的重复字节组成;</li> $\oplus$ 表示按位异或 (XOR) 操作;</li> $\parallel$ 表示拼接.</li> </ul> HMAC 用于验证消息真实性和完整性, 有时还用于密钥派生.</p> KDF</h3> KDF (Key Derivation Function, 密钥派生函数) 是一种将可变长度密码转换为固定长度密钥的函数:</p> key = KDF(password) </span></code></pre> 我们可以使用 SHA-256 对密码进行哈希处理, 使用哈希值作密钥, 这就是一个简单的 KDF. 但请不要这样做, 因为它不安全: 简单哈希容易受到字典攻击 (查表法).</p> 为此, 我们可以引入盐 (salt) 执行 HMAC 操作, 此即 HKDF</strong> (HMAC-based KDF), 具体内容见下文.</p> 使用 HKDF 进行密钥派生不如现代 KDF 安全, 如 PBKDF2, Bcrypt, Scrypt, Argon2 等.</p> KDF: 从密码(或密钥)派生密钥</h2> PBKDF2, Bcrypt, Scrypt, Argon2 等 KDF 函数, 通过引入盐并结合多次迭代来增加密码破解的难度, 迭代过程也称 key stretching (密钥拉伸)</a>.</p> 要计算安全的 KDF, 需要一些 CPU 时间来派生密钥 + 一些内存. 因此, 派生密钥是计算成本高昂的, 因此密码破解的尝试也会面临高昂计算成本.</p> 当现代 KDF 与适当的配置参数一起使用时, 破解密码的速度会很慢 (例如, 每秒只能作 5-10 次尝试, 而不是每秒数千或数百万次尝试).</p> 上述现代 KDF 均未申请专利, 可公开使用.</p> 由于本系列主要介绍 TLS 1.3, 因此不再赘述现代 KDF 的细节 (我们只用到了 HKDF), 有兴趣的读者可参考 Practical Cryptography for Developers Book</a>. 下一节对 HKDF 的介绍, 主要翻译自 RFC 5869</a>.</p> HKDF (RFC 5869)</h2> 本文档规定了一个简单的基于 HMAC 的 KDF, 它可以作为各种协议和应用程序中的 (加密) 组件. KDF 旨在支持广泛的应用程序和需求, 并在使用加密哈希函数方面是保守的.</p> 1. 引言</h3> KDF 是加密系统的基本和必要组件. 其目标是获取一些初始密钥材料源, 并从中派生出一个或多个具备强加密强度的密钥.</p> 本文档规定了一个简单的基于 HMAC 的 KDF, 名为 HKDF, 它可以作为各种协议和应用程序中的 (加密) 组件, 并且已经在几个 IETF 协议中使用, 包括 IKEv2、PANA 和 EAP-AKA. 本文档旨在以通用化的方式, 促进其在未来协议和应用中的采纳, 并防止多种 KDF 机制的无序发展. 它不是要求更改现有协议的呼吁, 也不会更改或更新使用此 KDF 的现有规范.</p> HKDF 遵循 “提取然后扩展” (extract-then-expand) 的范式, 其中 KDF 在逻辑上由两个模块组成. 第一阶段获取输入密钥材料并从中 “提取” 固定长度的伪随机密钥 K. 第二阶段将密钥 K “扩展” 为几个额外的伪随机密钥 (KDF 的输出).</p> 在许多应用程序中, 输入密钥材料不一定均匀分布, 攻击者可能对其有部分了解 (例如, 由密钥交换协议计算的 Diffie-Hellman 值), 甚至对其有部分控制 (如在一些熵收集应用程序中). 因此, “提取” 阶段的目标是将输入密钥材料可能分散的熵 “集中” 到一个短而高强度的伪随机密钥</strong> (pseudorandom key, PRK</strong>) 中. 在一些应用程序中, 输入可能已经是一个良好的 PRK; 在这些情况下, “提取” 阶段不是必需的, “扩展” 部分可以单独使用. 第二阶段, 将伪随机密钥 “扩展” 到所需长度; 输出密钥的数量和长度取决于需要密钥的特定加密算法.</p> 请注意, 一些现有的 KDF 规范要么只考虑第二阶段, 要么没有明确区分 “提取” 和 “扩展” 阶段, 经常导致设计缺陷. 本规范的目标是适应广泛的 KDF 需求, 同时最小化对底层哈希函数的假设. 提取然后扩展“ 范式很好地支持了这一目标.</p> 2. HKDF</h3> 2.1. 符号系统</h4> HMAC-Hash 表示使用哈希函数 “Hash” 的 HMAC 函数. HMAC 始终有两个参数: 第一个是密钥, 第二个是输入(或消息). (请注意, 在提取步骤中, IKM 用作 HMAC 输入, 而不是 HMAC 密钥.)</p> 当消息由多个元素组成时, 我们在第二个参数中将其串接 (表示为 \|); 例如, HMAC(K, elem1 \| elem2 \| elem3).</p> 本文档中的关键词 “必须” (“MUST” / “SHALL” / “REQUIRED”)、“绝不能” (“MUST NOT” / “SHALL NOT”), “推荐” (“SHOULD” / “RECOMMENDED”)、“不推荐” (“SHOULD NOT” / “NOT RECOMMENDED”), “可以/可能/可选” (“MAY” / “OPTIONAL”) 按照 BCP 14, RFC 2119 中的描述进行解释.</p> 2.2. 第一步: 提取 (extract)</h4> HKDF-Extract(salt, IKM) -> PRK </span></code></pre> 可选:</p> Hash</code>: 用于 HMAC 的哈希函数, HashLen 是其输出长度 (以字节为单位);</li> </ul> 入参:</p> salt</code>: 可选的随机盐值 (一个非秘密随机值); 如果未提供, 则将其设置为 HashLen 字节的零值;</li> IKM</code>: 输入密钥材料 (input key material);</li> </ul> 输出:</p> PRK</code>: 输出的长度为 HashLen 字节的伪随机密钥 (pseudorandom key).</li> </ul> PRK 由以下公式计算:</p> PRK = HMAC-Hash(salt, IKM) </span></code></pre> 2.3. 第二步: 扩展 (expand)</h4> HKDF-Expand(PRK, info, L) -> OKM </span></code></pre> 可选:</p> Hash</code>: 用于 HMAC 的哈希函数, HashLen 是其输出长度 (以字节为单位);</li> </ul> 入参:</p> PRK</code>: 伪随机密钥 (pseudorandom key), 长度至少为 HashLen 字节 (通常, 这是由 HKDF-Extract 生成的输出);</li> info</code>: 可选的上下文和应用程序特定信息 (可以是零长度);</li> L</code>: 所需输出密钥材料 (output keying material) 的长度 (以字节为单位); L 必须小于或等于 255 * HashLen;</li> </ul> 输出:</p> OKM</code>: 输出的密钥材料 (output keying material), 长度为 L 字节;</li> </ul> OKM 由以下公式计算:</p> N = ceil(L/HashLen) </span>T = T(1) \| T(2) \| T(3) \| ... \| T(N) </span>OKM = first L bytes of T </span></code></pre> 其中:</p> T(0) = empty string (zero length) </span>T(1) = HMAC-Hash(PRK, T(0) \| info \| 0x01) </span>T(2) = HMAC-Hash(PRK, T(1) \| info \| 0x02) </span>T(3) = HMAC-Hash(PRK, T(2) \| info \| 0x03) </span>... </span></code></pre> 3. HKDF 的使用注意事项</h3> 本节讨论 HKDF 的一些使用注意事项.</p> 3.1. 关于盐 (salt)</h4> HKDF 被定义为可以在有或没有随机盐值的情况下运行. 这样做是为了适应那些无法获得盐值的应用程序. 然而, 我们强调, 使用盐值可以显著增强 HKDF 的强度, 确保哈希函数不同用途之间的独立性, 支持 “源独立地” 提取, 并强化支持 HKDF 设计的分析结果.</p> 随机盐值与初始密钥材料在两个方面有根本不同: 它不是保密的, 并且可以重复使用. 因此, 许多应用程序都可以应用盐值. 例如, 一个通过将 HKDF 应用于可再生熵池 (例如, 采样的系统事件) 来持续生成输出的伪随机数生成器 (PRNG) 可以固定一个盐值, 并将其用于 HKDF 的多个应用, 而无需保护盐值的秘密性. 在另一个应用领域, 一个从 Diffie-Hellman 交换中导出加密密钥的密钥协商协议可以从通信双方作为密钥协商一部分交换和认证的公开随机数中导出盐值 (这是 IKEv2 中采用的方法).</p> 理想情况下, 盐值是长度为 HashLen 的随机或伪随机字符串. 然而, 即使是质量较低的盐值 (尺寸较短或熵有限) 也可能对输出密钥材料的安全性做出显著贡献; 因此, 鼓励应用程序设计者在应用程序能够获取此类值时, 向 HKDF 提供盐值.</p> 值得注意的是, 虽然不常见, 但某些应用程序甚至可能拥有保密的盐值; 在这种情况下, HKDF 提供了更强的安全保证. 这种应用程序的一个例子是 IKEv1 的 “公钥加密模式”, 其中提取器的 “盐值” 是从秘密随机数计算出来的; 类似地, IKEv1 的预共享模式使用从预共享密钥派生的秘密盐值.</p> 3.2. 关于 info</h4> 尽管 “info” 值在 HKDF 的定义中是可选的, 但它在应用程序中通常非常重要. 其主要目标是将派生密钥材料与应用程序和上下文特定的信息绑定. 例如, “info” 可能包含协议号、算法标识符、用户身份等. 特别是, 它可以防止为不同上下文派生相同的密钥材料 (当在这些不同上下文中使用相同的 IKM 时) . 如果需要, 它还可以容纳密钥扩展部分的额外输入 (例如, 应用程序可能希望将密钥材料与其长度 L 绑定, 从而使 L 成为 info 字段的一部分) . “info” 有一个技术要求: 它应该独立于 IKM.</p> 3.3. 跳过还是不跳过(提取)</h4> 在某些应用程序中, IKM 可能已经作为密码学强度高的密钥存在 (例如, TLS RSA 密码套件中的预主密钥将是一个伪随机字符串, 除了前两个八位字节) . 在这种情况下, 可以跳过提取部分, 直接使用 IKM 作为扩展步骤中的密钥. 另一方面, 为了与一般情况兼容, 应用程序仍可能使用提取部分. 特别是, 如果 IKM 是随机的 (或伪随机的) , 但比 HMAC 密钥长, 则提取步骤可以用于输出一个合适的 HMAC 密钥 (在 HMAC 的情况下, 通过提取器进行这种缩短并非严格必要, 因为 HMAC 也被定义为可以处理长密钥) . 然而, 请注意, 如果 IKM 是 Diffie-Hellman 值, 如同 TLS 与 Diffie-Hellman 的情况, 则不应跳过提取部分. 这样做将导致使用 Diffie-Hellman 值 g^{xy} 本身 (它不是一个均匀随机或伪随机字符串) 作为 HMAC 的密钥 PRK. 相反, HKDF 应该将提取步骤应用于 g^{xy} (最好带有一个盐值) , 并使用生成的 PRK 作为 HMAC 在扩展部分中的密钥.</p> 在所需的密钥位数 L 不超过 HashLen 的情况下, 可以直接将 PRK 截断获得最终的 OKM. 然而, 不推荐这样做, 特别是因为它会省略在派生过程中使用的 “info” (也不建议将 “info” 作为输入添加到提取步骤中) .</p> 3.4. 独立性的作用</h4> KDF 的分析假设 IKM 来自某个源, 该源被建模为特定长度比特流的概率分布 (例如, 由熵池产生的流, 从随机选择的 Diffie-Hellman 指数派生的值等) ; IKM 的每个实例都是该分布中的一个样本. 密钥派生函数的一个主要目标是确保, 当将 KDF 应用于从 (相同) 源分布中抽取的任意两个值 IKM 和 IKM’ 时, 生成的密钥 OKM 和 OKM’ 在本质上是相互独立的 (在统计或计算意义上) . 为了实现这一目标, KDF 的输入必须从适当的输入分布中选择, 并且输入也必须相互独立选择 (从技术上讲, 即使以 KDF 的其他输入为条件, 每个样本也必须具有足够的熵) .</p> 独立性也是提供给 KDF 的盐值的一个重要方面. 虽然没有必要对盐值保密, 并且同一个盐值可以与多个 IKM 值一起使用, 但假定盐值独立于输入密钥材料. 特别是, 应用程序需要确保盐值不是由攻击者选择或操纵的. 例如, 考虑 (如 IKE 中) 盐值是从密钥交换协议中各方提供的随机数派生的情况. 在协议使用此类盐值派生密钥之前, 它需要确保这些随机数被认证为来自合法方, 而不是由攻击者选择的 (在 IKE 中, 例如, 这种认证是经过认证的 Diffie-Hellman 交换的一个组成部分).</p> 4. HKDF 的应用</h3> HKDF 旨在用于各种 KDF 应用. 这些应用包括从弱随机性来源获得伪随机性; 在密钥协商协议中从共享的 Diffie-Hellman 值导出加密密钥; 从混合公钥加密方案导出对称密钥; 用于密钥封装机制的密钥导出; 以及更多. 所有这些应用都可以受益于 HKDF 的简洁性和多功能性, 以及其分析基础.</p> 另一方面, 预计某些应用由于特定的操作要求将无法 “按原样” 使用 HKDF, 或者可以使用但无法充分发挥该方案的全部优势. 一个重要的例子是从低熵源 (例如用户密码) 导出加密密钥. HKDF 中的提取步骤可以集中现有熵, 但不能放大熵. 对于基于密码的 KDF, 主要目标是使用两个要素来减缓字典攻击: 一个盐值, 以及有意减慢密钥导出计算. HKDF 自然支持使用盐; 然而, 减速机制并非本规范的一部分. 对基于密码的 KDF 感兴趣的应用应考虑例如 PKCS5 是否比 HKDF 更能满足其需求.</p> 5. 安全注意事项</h3> 尽管 HKDF 组成简单, 但在其设计和分析中已考虑了许多安全因素. 对所有这些方面的阐述超出了本文档的范围.</p> 相关论文已投入大量精力, 对 HKDF 作为一种多用途 KDF 进行了密码学分析, 该分析在利用加密哈希函数的方式上非常谨慎. 鉴于我们对当前哈希函数强度的信心有限, 这一点尤为重要. 然而, 这项分析并不意味着任何方案的绝对安全性, 并且它在很大程度上取决于底层哈希函数的强度和建模选择. 尽管如此, 它有力地表明了 HKDF 设计的正确结构及其相对于其他常见 KDF 方案的优势.</p> (余下内容略去不译)</p> 安全随机数</h2> 密码学中, 随机性 (熵) 起着非常重要的作用. 在许多算法中, 我们需要随机的 (不可预测的) 数字. 如果这些数字不是不可预测的, 算法就会受到损害.</p> 在计算机科学中, 随机数通常来自伪随机数生成器 (pseudo-random numbers generators, PRNG), 由一些初始随机性初始化, 这些初始随机性一般来自极难预测的用户输入等, 可从操作系统读取, 如 Linux 的 /dev/random</code>; 在密码学中, 使用安全 PRNG, 称为 CSPRNG, 它通常将熵与 PRNG 和其他技术相结合, 使生成的随机性在密码学意义上不可预测.</p> 应当注意, 获取安全随机数的开销通常是比较大的, 而许多语言提供的随机数生成函数并非 CSPRNG (例如 Python 的 random</code> 库), 而是基于时间戳等可预测的种子获得的伪随机数, 不能用于密码学场景.</p> 小结</h2> 本文介绍了 MAC、HMAC、KDF 和 HKDF 的基本概念及其应用. 除却这四个术语外, 以下再摘抄若干术语、表达式供读者快速回顾:</p> HMAC = H(key \|\| H(key \|\| msg))</code>;</li> AEAD</code></strong></li> PRK = HKDF-Extract(salt, IKM)</code></strong>;</li> OKM = HKDF-Expand(PRK, info, L)</code></strong>;</li> </ul> 在阅读完本文后, 我们应该对上述表达式及相关术语不再陌生.</p> 从零开始了解 TLS 1.3 系列笔记（三）—— 实用密码学之「哈希函数」 2025-09-14T00:00:00+00:00 前言</h2> 在本章中, 我们将介绍哈希函数的基本概念, 以及常见的安全哈希算法. 哈希函数在 TLS 协议中被广泛使用, 例如在数字签名算法、消息认证码 (MAC) 和密钥派生函数 (KDF) 中都有应用.</p> 哈希函数与加密哈希函数</h2> 在计算机编程中, 哈希函数将输入不可逆地映射到一个整数. 通常不同的输入映射到不同的输出; 在密码学中, 哈希函数将任意大小的输入数据转换为因算法而异的固定大小的结果, 该结果称为哈希值. 计算机密码学中使用的哈希函数称为 “加密哈希函数”.</p> 对于哈希函数, 我们期待不同输入映射到不同输出, 但由于输入空间无限而输出空间有限, 不可避免地会发生冲突 (也称哈希碰撞); 而对于一个合格的加密哈希函数, 我们要求这个冲突的发生概率非常非常低, 以至于在实际应用中可以忽略不计.</p> 一个理想的加密哈希函数应当具有如下特性:</p> 确定性</strong>, 即对同样的输入, 应该总是产生同样的输出;</li> 快速</strong>, 计算速度要足够快;</li> 难以分析</strong>, 即对输入的任何微小改动, 都应该使输出完全发生变化;</li> 不可逆</strong>, 即从其哈希值逆向演算出输入值应该是不可行的, 这意味着没有比暴力破解更好的破解方法;</li> 抗碰撞</strong>, 即几乎不可能找到具有相同哈希值的两条不同消息.</li> </ul> 现代加密哈希函数, 如 SHA-2 和 SHA-3, 都至少在当前已知的攻击方法下满足上述特性.</p> 加密哈希函数的应用</h2> 加密哈希函数有很多应用, 其中最常见的包括:</p> 数据完整性校验</li> </ol> 这是加密哈希函数最常见的应用, 此时的哈希值作为 “校验和” (checksum). 例如, 当从互联网下载文件, 下载完毕后计算文件字节流的 SHA256 校验和跟官方公布的一致, 那就说明文件没有损坏.</p> 但需要指出: 哈希函数自身不能保证文件的真实性</strong>, 目前来讲, 从网上下载的文件的真实性通常是 TLS 协议要保证的, 它确保你看到的网站所公布的「SHA256 校验和」是未被篡改的.</p> 密码存储</strong></li> </ol> 加密哈希函数还被用于密码的安全存储, 以避免因直接存储明文密码、而某日数据库泄露导致密码泄露的问题.</p> 应当使用专门设计的安全哈希算法, 如 Scrypt, 计算用户密码的哈希值再持久化保存. 这种算法往往被设计为 CPU 密集和/或内存密集的, 以及难以并行化的, 提高单次计算的耗时, 以增加暴力破解的成本.</p> 唯一 ID</strong></li> </ol> 将任意长的文件内容哈希化生成一个定长的唯一的 ID, 用以索引等.</p> 伪随机数生成</strong></li> </ol> 哈希函数也可以用来生成伪随机数, 例如, 可以将一个随机种子值(从随机事件中收集熵, 如随机的鼠标移动或键盘输入)并附加一个值然后哈希化, 得到一个伪随机数. 可将结果附加一个值再哈希化, 得到另一个伪随机数. Linux 内核的 /dev/urandom</code> 就是基于此原理实现的.</p> 工作量证明 (PoW, Proof of Work) 算法</strong></li> </ol> 略.</p> 安全哈希算法</h2> 以下简要介绍几种常见的安全哈希算法.</p> SHA-2</h3> 依据哈希位数, 可分为 SHA-256, SHA-384 和 SHA-512 等若干变体. SHA-2 基于 “Merkle-Damgård 构造” , 目前被认为高度安全.</p> 示例:</p> SHA-256('hello') = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 </span>SHA-384('hello') = 59e1748777448c69de6b800d7a33bbfb9ff1b463e44354c3553bcdb9c666fa90125a3c79f90397bdf5f6a13de828684f </span>SHA-512('hello') = 9b71d224bd62f3785d96d46ad3ea3d73319bfbc2890caadae2dff72519673ca72323c3d99ba5c11d7c7acc6e14b8c5da0c4663475c2e5c3adef46f73bcdec043 </span></code></pre> SHA-3</h3> 比 SHA-2 更安全, 不容易遭受长度扩展攻击</a>; 在 TLS 1.3 中并未使用.</p> BLAKE2 / BLAKE3</h3> BLAKE2 / BLAKE3 安全性与 SHA-3 相当, 但针对现代硬件进行高度优化, 哈希速度比 SHA-3 快得多; 在 TLS 1.3 中并未使用.</p> 其他</h3> 如中国的商密系列 SM3 / SM4 等.</p> 不安全的哈希函数</h2> 应当避免使用以下被认为不安全或安全性有争议的的哈希算法: MD2、MD4、MD5、SHA-0、SHA-1、Panama、HAVAL (有争议的安全性, HAVAL-128 发现冲突)、Tiger (有争议, 发现弱点)、SipHash (它不是加密哈希函数).</p> 本章小结</h2> 哈希函数将任意大小的输入数据不可逆地映射为固定大小的结果, 该结果称为哈希值.</li> 加密哈希函数要求映射冲突的发生概率非常低, 以至于在实际应用中可以忽略不计, 保证无法伪造数据和原始数据具备一致的哈希值.</li> 加密哈希函数只能保证数据完整性, 不能保证数据真实性.</li> 现代哈希函数包括 SHA-2, SHA-3, BLAKE2 / BLAKE3 等; 应当避免使用 MD5, SHA-1 等被认为不安全的哈希函数.</li> </ol> 部分参考文献</h2> Practical Cryptography for Developers Book</a></li> </ul> 从零开始了解 TLS 1.3 系列笔记（二）—— 实用密码学之「引言」 2025-09-13T00:00:00+00:00 前言</h2> TLS 协议是一种密码学实践, 其目标如其名曰 “传输层安全”, 在假设完全不可信的信道上提供安全的通信. 这要求 TLS 协议必须满足以下安全目标:</p> 确保数据不会被中间人获取;</li> 确保数据不被中间人篡改;</li> 确定对端的真实身份, 确保通信双方的身份可信.</li> </ul> 通俗地说, 我们需要维持消息的机密性</strong> (confidentiality), 以及消息的真实性</strong> (authenticity)、完整性</strong> (integrity) 和不可否认性</strong> (non-repudiation). 为此, TLS 协议使用了大量的密码学算法原语、组件, 如哈希函数, 对称加密算法, 非对称加密算法, 数字签名算法等. 在系统地理解 TLS 协议之前, 我们需要先了解这些密码学基础概念.</p> 什么是密码学</h2> 密码学 (Cryptography) 是提供信息安全和保护</strong>的科学. 它在我们的数字世界中无处不在, 当你打开网站时、发送电子邮件时、连接到 WiFi 网络时, 使用账号密码登录 APP 时、使用二步认证验证码认证身份时, 都有涉及到密码学相关技术. 因此, 开发人员应该对密码学有基本的了解, 以避免写出不安全的代码. 至少也得知道如何使用密码算法和密码库, 了解哈希、对称密码算法、非对称密码算法与加密方案这些概念, 知晓数字签名及其背后的密码系统和算法.</p> 以下密码学基础概念(术语)将在本文以及后续文章中频繁出现, 需要熟悉.</p> 熵 (entropy) 与安全随机数生成器.</li> 哈希函数 (Hash Function, 也称散列函数), 如 MD5, SHA-1, SHA-2 (主要包括 SHA-256, SHA-384, SHA-512 三个变体) 等.</li> 哈希消息认证码 (Hash-based Message Authentication Code, HMAC</strong>), 如 HMAC-SHA-256.</li> 密钥派生函数 (Key Derivation Function, KDF</strong>), 如 Scrypt.</li> 密钥交换</strong>算法 (Key Exchange Algorithm), 如 Diffie-Hellman (DH) 和 ECDH (椭圆曲线 Diffie-Hellman).</li> 对称密钥加密</strong>方案 (Symmetric key encryption schemes), 如 AES-128-GCM.</li> 非对称密钥加密</strong>方案 (Asymmetric key encryption schemes), 如 RSA 和 ECC (elliptic curves-based cryptography, 椭圆曲线密码学).</li> 数字签名算法</strong> (Digital Signature Algorithm, DSA).</li> 后量子</strong> (Post-Quantum) 安全.</li> </ul> 如果你有过一些开发经验, 可能会很熟悉其中部分名词. 如果不熟也没任何关系, 都会在本系列文章内介绍, 请坐和放宽.</p> 密码学的用途</h2> 熵与安全随机数</h3> 熵 (entropy, 指不可预测的随机性) 是密码学的重要部分, 大量算法的安全性都仰赖于具备足够熵的随机数.</p> 计算机无法产生真正的随机数, 只能从外部获得 “真” 随机性:</p> Linux 系统下的 /dev/urandom</code> 的随机性来源于硬件中断、按键输入、鼠标移动、磁盘 IO 等不可预测的系统事件;</li> Cloudflare 使用一面熔岩墙</a> 获得真随机性…</li> </ol> 区别于真随机性, 通过特定算法从一定的随机性种子 (seed) 生成的随机性我们称之为伪随机性, 伪随机性显然由于随机性种子的来源有高低优劣之分. 密码学操作在需求随机性时, 往往要求使用安全伪随机数生成器 (Cryptographically secure pseudo-random number generator, CSPRNG), 基于具备足够熵的随机性种子生成高质量的伪随机数: 通过 CSPRNG 生成的随机数即便攻击者在统计学意义上能收集大量过往产生的随机数进行分析, 或者计算上通过特定手段探知得 CSPRNG 内部状态, 均无法推测出未来的随机数. 而大部分编程语言内置的伪随机数生成器出于性能因素, 在设计上是基于时间戳等可预测性强的随机数种子的, 不具备密码学安全性.</p> 哈希函数与 HMAC</h3> 哈希函数, 如 MD5、SHA-1、SHA-2, SHA-3 和 BLAKE2 等, 将任意长消息不可逆地</strong>转换固定长度的哈希值, 称消息摘要 (digest). 哈希函数被设计为几乎不可能找到具有相同哈希值的两条不同消息, 违背这一点的哈希函数被认为是不安全的, 如 MD5 和 SHA-1.</p> 基于哈希函数的特性, 可以将特定哈希函数用于验证消息完整性, 称 HMAC.</p> KDF</h3> 文本密码绝大部分情况下不具备足够的熵, 不能直接作加密密钥. KDF</strong> (Key Derivation Function, 密钥派生函数) 负责从文本密码安全地派生出具备足够熵的密钥, 且往往还通过注入随机参数 (盐, salt) 和使用大量迭代和计算资源使暴力计算所有可能的密钥变得不可行. 常用的 KDF 包括 PBKDF2、Scrypt 和 Argon2 等.</p> 密钥交换</h3> 密钥交换算法、方案允许通信双方经由完全不可信的信道安全地协商共享密钥. TLS 中使用到的密钥交换算法包括传统 Diffie-Hellman (DH</strong>) 和基于椭圆曲线的 ECDH</strong> (Elliptic Curve DH), 以及后量子安全的密钥交换算法 (如 ML-KEM</strong>).</p> 加解密</h3> 密码学自诞生之日起最大用途, 就是进行数据的安全存储和安全传输. 按密钥数量, 可将加密算法分为两类:</p> 对称 (Symmetric) 加密: 加密和解密使用相同的密钥</strong>.</p> 如 AES 和 ChaCha20.</p> </li> 非对称 (Asymmetric) 加密: 加密和解密使用成对的不同的密钥</strong>.</p> 非对称加密用到的两个密钥在数学上是关联的, 我们称其为 “密钥对</strong>”; 其中一把密钥公开, 另一把密钥保密, 我们分别称其为 “公钥</strong>” 和 “私钥</strong>”; 公钥可以由私钥计算得到, 但反过来则几乎不可能实现.</p> 非对称加密体系也称公钥密码学体系.</p> </li> </ul> 一般而言, 对称加密比非对称加密更快, 但非对称加密更安全</strong>. TLS 等现代加密协议通常会结合使用对称和非对称加密, 以平衡最佳的安全性和性能.</p> 单纯使用加密算法是不够的, 这是因为有的加密算法只能按块进行加密, 而且很多加密算法并不能保证密文的真实性、完整性. 因此, 现实中我们通常会使用一套加密方案</strong>进行数据的加解密. 加密方案由一系列加密算法、消息认证算法或数字签名算法、块密码模式等多种密码学原语组合得到, 以同时保证数据的安全性、真实性、完整性;加密方案的名称就是使用到的各种密码算法名称的组合, 如 AES-128-GCM、ChaCha20-Poly1305 等. 后面我们再详细了解.</p> 数字签名和消息认证</h3> 密码学当中, 数字签名算法 (Digital Signature Algorithm, DSA) 算法和消息认证 (Message Authentication) 算法提供了对消息真实性、完整性和不可否认性的保证.</p> DSA 首先是个公钥密码学体系, 大多数数字签名算法使用非对称加密原语: 使用私钥加密特定信息, 此即签名</strong>; 由相应的公钥解密, 此即验签</strong> (保证双方持有合法的密钥对).</p> MAC 跟数字签名的功能实际上是一致的, 区别在于其使用哈希算法 (HMAC), 或者对称加密原语.</p> 现代加密协议通常会结合使用数字签名和消息认证.</p> 混淆与扩散</h2> 在密码学当中, 香农提出的「混淆」 (confusion) 与「扩散」 (diffusion) 是设计安全密码学算法的两个原则.</p> 「混淆」使密文和对称加密中密钥的映射关系变得尽可能的复杂, 使之难以分析. 如果使用了混淆, 那么输出密文中的每个比特位都应该依赖于密钥和输入数据的多个部分, 确保两者无法建立直接映射. 混淆常用的方法是「替换」与「排列」.</p> 「扩散」将明文的统计结构扩散到大量密文中, 隐藏明文与密文之间的统计学关系. 使单个明文或密钥位的影响尽可能扩大到更多的密文中去, 确保改变输入中的任意一位都应该导致输出中大约一半的位发生变化, 反过来改变输出密文的任一位, 明文中大约一半的位也必须发生变化. 扩散常用的方法是「置换」.</p> 这两个原则被包含在大多数哈希函数、MAC 算法、随机数生成器、对称和非对称密码算法中.</p> 值得指出, “XOR 加密” 的说法本质上是错误的. XOR 操作本身并不提供混淆或扩散.</p> 关于库的使用</h2> 程序员常自嘲为 Ctrl-C / Ctrl-V 工程师, 但在密码学领域反而推荐那么干, 以获得经大量实践验证的当下最优的安全性. 当然, 盲目地从互联网复制粘贴代码也可能会导致安全问题; 曾经安全的代码、算法或者最佳实践, 随着时间的推移也可能变得不再安全.</p> 本章小结</h2> 密码学是一个庞大而复杂的领域, 在后续的文章中, 我们将继续深入探讨 TLS 1.3 协议这一密码学最佳实践. 虽然本章很短, 但不管怎么样, 通过本章内容先建立一个全局观念是极好的.</p> 部分参考文献</h2> Practical Cryptography for Developers Book</a></li> Cloudflare: 熔岩灯如何为 Internet 加密助力？</a></li> </ul> 从零开始了解 TLS 1.3 系列笔记（一）—— 导语 2025-09-12T00:00:00+00:00 导语</h2> 笔者一直认为, 个人是难以面面俱到地从零设计一个安全协议的: 密码学算法固然重要, 但错误的密码学实践与不安全的算法具有同等危害; 总有人试图自创加密协议, 但结果往往是造方形轮子乃至破轮子, 不如直接使用成熟的协议来得安全可靠. Transport Layer Security (TLS, 传输层安全</em>) 协议可谓现代互联网安全的基石, 经历数十年的发展, 在实践中缝缝补补、推陈出新, 如今来到了 1.3 版本. 出于实际需求, 笔者最近半年的空余时间都在阅读 draft-ietf-tls-rfc8446bis</a> (即 RFC8446</a>), 并结合 rustls</a> 源码研究 TLS 1.3 实现. 苦于互联网关于 TLS 1.3 的中文内容相当零散, 遂开个新坑, 从零开始介绍(学习</del>) TLS 1.3 协议的实现细节, 一方面方便笔者自己随时查阅, 另一方面也方便后来者参考学习, 减轻阅读晦涩的英文资料的烦恼.</p> 本系列内容</h2> 本系列按照以下大纲进行撰写:</p> 密码学应用基础.</li> RFC 8446 规范详解.</li> TLS 协议拓展, 包括但不限于: ECH, 见 draft-ietf-tls-esni</a>.</li> </ul> </li> 实战: 从零开始, 实现一个简易但 Production Ready 的 TLS 1.3 加密库 (in Rust).</li> </ul> 由于涉及的内容繁杂且笔者精力有限只能抽空闲时间学习、总结, 预计这个系列在一年内完成. 欢迎各位读者参考学习、批评指正. 感兴趣的读者可以点击 Tag 订阅 RSS.</p> 参考文献</h2> 笔者在编写此系列文章的过程中学习参考了大量资料, 在此列出质量较高的部分, 以飨读者:</p> 冰霜之地 (Halfrost)</a> 分享的系列文章</li> 超超哥哥 (taikulawo)</a> 分享的文章</li> 於清樂 (thiscute)</a> 分享的翻译文章 Practical Cryptography for Developers Book</a></li> </ul> </li> …</li> </ul> This Week In Rust (#613) 速报 2025-08-23T00:00:00+00:00 最新一期 This Week In Rust (#613) 新鲜出炉: This Week in Rust #613</a>.</p> Updates from Rust Community</h2> Official</h3> Demoting x86_64-apple-darwin to Tier 2 with host tools</a></p> 评: 光阴似箭, M1 已经是五年前的产物, 在苹果的强力推动下, MacOS 生态对 ARM 架构的支持已经相当完善. 笔者表示, 不愧是苹果.</em></p> 仍然在使用搭载 Intel 处理器的 x86_64 架构的苹果电脑的人越来越少, 自然也就难以继续维持 Tier 1 的支持了.</em></p> </li> Leadership Council September 2025 Representative Selections</p> </li> Electing new Project Directors 2025</p> </li> </ul> Newsletters</h3> This Month in Rust OSDev: July 2025</li> The Embedded Rustacean Issue #52</li> </ul> Project/Tooling Updates</h2> Zed for Windows: What’s Taking So Long?!</a></p> 评: 笔者表示, 已经受不了 VSCode 动辄几个 GB 的内存占用了… 期待 Zed 能够早日发布 Windows 版本.</em></p> </li> SeaQuery just made writing raw SQL more enjoyable (数据库</em>)</p> </li> r3bl-cmdr v0.0.22 (TUI</em>)</p> </li> r3bl_tui v0.7.4 (TUI</em>)</p> </li> Heapless v0.9.1 - static friendly data structures that don’t require dynamic memory allocation (嵌入式开发</em>)</p> </li> Announcing Asterinas 0.16.0</a> (操作系统内核, 仓库创始人是国人来着, 文档有中文, 泪目</em>)</p> </li> </ul> Observations/Thoughts</h2> Placing Arguments</a></p> 此文介绍了可能在未来引入标准库的 #[placing]</code> 属性的 API 设计. #[placing]</code> 主要是为了解决实现返回类型在调用方的堆栈帧中构造的问题.</em></p> </li> Update on our advocacy for memory-safety - Tweede golf</a></p> TL, DR: please use Rust for memory safety!</em></p> </li> Speed wins when fuzzing Rust code with #[derive(Arbitrary)]</a></p> TL, DR: 请升级 arbitrary</code> 到 1.4.2, 性能大提升!</em></p> </li> Rewriting Numaflow’s Data Plane: A Foundation for the Future</a></p> Numaflow 是一个开源 K8s 原生平台, 将使用 Rust 重构控制平面</em></p> 其实国内也有个中科院软研所主办的 R2CN（RISC-V Rust for Cloud Native）开源实习计划</a>, 旨在推动 RISC-V 生态和 Rust 在云原生领域的应用, 仓库是 rk8s</a>.</em></p> </li> Terminal sessions you can bookmark: Building Zellij’s web client</p> Zellij is a workspace aimed at developers, ops-oriented people and anyone who loves the terminal. Similar programs are sometimes called “Terminal Multiplexers”.</em></p> </li> Testing failure modes using error injection</a></p> 使用错误注入测试故障模式</em></p> </li> Multiple Breakpoints in Rust: Ownership-Driven Debugger Design</a></p> 对调试器开发感兴趣的可以看看</em></p> </li> Lessons learned from rewriting the UltraGraph crate</a></p> </li> Scientific Computing in Rust</a></p> Rust 做科学计算么, 有意思</em></p> </li> RKL: A Docker-like Command-line Interface Built in Rust</a></p> 巧了, 刚才才提到 R2CN. 就是, 得把国人用英文写的文章再翻回去么, 有意思</del></em></p> </li> kruci: Post-mortem of a UI library</a></p> TL, DR: 嫌弃 rataui 性能不行, 作者重写了一个</del> 感兴趣的可以尝鲜.</em></p> </li> Nine Rules for Generalizing Your Rust Library: Lessons from Extending RangeSetBlaze to Maps (Part 2)</a></p> 好文, 已加入 TWIR 翻译计划 (咕咕咕)</em></p> </li> [audio] Intrusive lists for fun and profit</p> </li> </ul> Rust Walkthroughs</h2> Constructor Best Practices in Rust</a></p> 好文, 已加入 TWIR 翻译计划 (咕咕咕)</em></p> </li> Let’s write a macro in Rust - Part 1</a></p> 好文, 已加入 TWIR 翻译计划 (咕咕咕)</em></p> </li> Memory analysis in Rust</a></p> 好文! 已加入 TWIR 翻译计划 (咕咕咕)</em></p> </li> </ul> Miscellaneous</h2> Rust At Microsoft And Chairing The Rust Foundation</p> </li> Talking To Zed Industries- Makers Of The 100% Rust, Super-Performant, Collaborative Code Editor</p> </li> All the Rust Tutorials</a></p> 收录了 Rust 开发各种 tutorial, 就是网站略为卡顿.</em></p> </li> July 2025 Rust Jobs Report</p> </li> </ul> Call for Participation; projects and speakers</h2> 略.</p> Updates from the Rust Project</h2> 简要列举几个我觉得很实用的:</p> implement #[derive(From)]</code></a></p> 将于 Rust 1.91.0 推出. 说实在的, 不知道为什么拖了这么久.</p> </li> add Default impls for Pin</code>ned Box</code>, Rc</code>, Arc</code></a></p> 将于 Rust 1.91.0 推出. 也是比较常用的了.</p> </li> stabilize #![feature(ip_from)]</code></a></p> 将于 Rust 1.91.0 推出. 这个也是咕了很久了, 还好我习惯使用 nightly Rust. 不知道为什么拖了这么久.</p> </li> </ul> Upcoming Events</h2> 略.</p> 使用 Rust 全局变量的注意事项 2025-08-02T00:00:00+00:00 应当区分 static</code> 和 const</code> 关键字的作用, 正如其文档</a>所言:</p> A static item is a value which is valid for the entire duration of your program (a 'static</code> lifetime).</p> 静态变量是一个在程序的整个生命周期内有效的值 (拥有 'static</code> 的生命周期).</p> </blockquote> const</code> items look remarkably similar to static</code> items, which introduces some confusion as to which one should be used at which times. To put it simply, constants are inlined wherever they’re used, making using them identical to simply replacing the name of the const</code> with its value. Static variables, on the other hand, point to a single location in memory, which all accesses share. This means that, unlike with constants, they can’t have destructors, and act as a single value across the entire codebase.</p> const</code> 与 static</code> 看起来非常相似, 可能在使用上引起困惑. 简单来说, 常量在使用的地方都会被内联, 这使得使用它们就像简单地用其值替换 const</code> 的名称一样. 另一方面, 静态变量指向内存中的一个单一位置, 所有访问都共享该位置. 这意味着, 与常量不同, 它们不能有析构函数, 并且在整个代码库中充当一个单一值.</p> </blockquote> 参考资料:</p> reddit</a></li> </ul> 译: Mimalloc Cigarette: Losing one week of my life catching a memory leak 2025-07-26T00:00:00+00:00 本文翻译自 Mimalloc Cigarette: Losing one week of my life catching a memory leak</a>, 英文原文版权由原作者所有, 中文翻译版权遵照 CC BY-NC-SA 协议开放.</p> 囿于译者自身水平, 译文虽已力求准确, 但仍可能词不达意, 欢迎批评指正.</p> 2025 年 7 月 26 日晨, 于广州.</p> </blockquote> 目录</summary> </details> One of applications at my work has always been RAM-bound - it’s a pricing engine that basically loads tons of hotels, builds some in-memory indices and then allows you to issue queries like find me the cheapest hotel in berlin, pronto.</p> 我工作中的一个应用程序一直受到 RAM 限制: 它是一个定价引擎, 基本上是加载大量酒店数据, 构建一些内存索引, 然后允许你发出查询, 比如快速找到柏林最便宜的酒店.</p> A pricing engine’s main purpose is to price engines hotels, but in order to do that effectively, there’s a lot of “meta work” involved, like:</p> 定价引擎的主要目的是为酒店定价, 但为了有效地做到这一点, 涉及很多“元工作“, 比如：</p> Where do we load the data from, how do we do it?</p> 我们从哪里加载数据, 如何加载？</p> </li> Do we load the entire dataset or just some parts of it?</p> 我们是加载整个数据集还是只加载其中的一部分？</p> </li> Should we precalculate prices in order to speed-up the most popular queries?</p> 我们是否应该预先计算价格以加速最受欢迎的查询？</p> </li> </ul> Such an engine poses an interesting technical challenge, even greater so when one day it starts OOMing on production, even though the entire dataset should fit in the memory multiple times…</p> 这样的引擎带来了有趣的技术挑战, 当有一天它在生产环境中开始出现内存不足时, 挑战变得更大, 尽管整个数据集应该能在内存中放下多次…</p> Hello, World!</h2> Simplifying a bit</del> a lot, what we’re dealing with is:</p> 简要</del>大大简化一下, 我们处理的是：</p> struct</span> </span>State</span> </span>{</span> </span></span></span> hotels</span>:</span> Vec</span><</span>Hotel></span></span>, </span></span></span></span>}</span></span></span> </span> </span>struct</span> </span>Hotel</span> </span>{</span> </span></span></span> prices</span>:</span> Vec</span><</span>f32</span>></span></span>, </span></span></span></span>}</span></span></span> </span> </span>//</span> --- </span></span> </span>impl</span> </span>State</span> </span>{</span> </span></span></span> fn</span> </span>new</span></span>(</span></span>)</span></span></span></span> -></span> Self</span></span> </span>{</span> </span></span></span></span></span> Self</span> {</span> </span></span></span></span></span></span> hotels:</span> load_hotels</span>(</span></span>)</span></span>.</span>collect</span>(</span></span>)</span></span>,</span> </span></span></span></span></span></span> </span>}</span></span> </span></span></span></span></span> </span>}</span></span></span> </span></span></span> </span></span></span> fn</span> </span>refresh</span></span>(</span>&</span>mut</span> self</span></span>)</span></span></span></span> </span>{</span> </span></span></span></span></span> for</span> (</span>id,</span> hotel</span>)</span></span> in</span> load_hotels</span>(</span></span>)</span></span>.</span>enumerate</span>(</span></span>)</span></span> {</span> </span></span></span></span></span></span> self</span>.</span>hotels[</span>id]</span></span> =</span> hotel;</span> </span></span></span></span></span></span> </span>}</span></span> </span></span></span></span></span> </span>}</span></span></span> </span></span></span></span>}</span></span></span> </span> </span>fn</span> </span>load_hotels</span></span>(</span></span>)</span></span></span></span> -></span> impl Iterator</span><</span>Item = Hotel></span></span></span> </span>{</span> </span></span></span> (</span>0</span>..</span>1_000</span></span>)</span></span>.</span>map</span>(</span>\|</span></span></span>_\|</span></span> </span>Hotel {</span> </span></span></span></span></span></span> prices:</span> (</span>0</span>..</span>1_000_000</span></span>)</span></span>.</span>map</span>(</span>\|</span></span></span>n</span>\|</span></span> </span>n as</span> f32</span></span></span>)</span></span>.</span>collect</span>(</span></span>)</span></span>,</span> </span></span></span></span></span></span> </span>}</span></span></span></span>)</span></span> </span></span></span></span>}</span></span></span> </span> </span>//</span> --- </span></span> </span>fn</span> </span>main</span></span>(</span></span>)</span></span></span></span> </span>{</span> </span></span></span> let</span> state =</span> Arc::</span></span>new(</span>RwLock::</span></span>new(</span>State::</span></span>new(</span></span>)</span></span></span>)</span></span></span>)</span></span>;</span> </span></span></span> </span></span></span> //</span> Spawn a separate thread responsible for checking which hotels have </span></span></span></span> //</span> changed and need to be refreshed etc. </span></span></span></span> thread::</span></span>spawn(</span>{</span> </span></span></span></span></span> let</span> state =</span> Arc::</span></span>clone(</span>&</span>state</span>)</span></span>;</span> </span></span></span></span></span> </span></span></span></span></span> move</span> \|\|</span> loop</span> {</span> </span></span></span></span></span></span> thread::</span></span>sleep(</span>Duration::</span></span>from_secs(</span>5</span></span>)</span></span></span>)</span></span>;</span> </span></span></span></span></span></span> state.</span>write</span>(</span></span>)</span></span>.</span>unwrap</span>(</span></span>)</span></span>.</span>refresh</span>(</span></span>)</span></span>;</span> </span></span></span></span></span></span> </span>}</span></span> </span></span></span></span></span> </span>}</span></span></span>)</span></span>;</span> </span></span></span> </span></span></span> //</span> Now in reality we start a Rocket server here, but for practical </span></span></span></span> //</span> purposes stalling the main thread will be sufficient. </span></span></span></span> loop</span> {</span> </span></span></span></span> thread::</span></span>sleep(</span>Duration::</span></span>from_secs(</span>1</span></span>)</span></span></span>)</span></span>;</span> </span></span></span></span> </span>}</span></span> </span></span></span></span>}</span></span></span> </span></code></pre> Of course IRL there’s ArcSwap</code> instead of RwLock</code>, every hotel contains much more information (like taxes, discounts or supplements) etc., but we’ve got a reasonably good approximation here.</p> 当然在现实生活中有 ArcSwap</code> 而不是 RwLock</code>, 每个酒店包含更多信息（如税费、折扣或附加费）等, 但我们在这里有一个相当好的近似.</p> Now, what if I told you that this code has totally different memory characteristics depending on which allocator you use?</p> 现在, 如果我告诉你这段代码根据你使用的分配器有完全不同的内存特性, 你会怎么想？</p> Practical Reasons \| 原因分析</h2> Memory allocator is the piece of software invoked whenever your program needs to get hands on extra memory, like when you’re calling Box::new()</code>. And memory allocation is quite a complex topic, with different solutions offering different trade-offs.</p> 内存分配器是当你的程序需要获得额外内存时调用的软件, 比如当你调用 Box::new()</code> 时. 内存分配是一个相当复杂的话题, 不同的解决方案提供不同的权衡.</p> Say, when implementing a firmware you might pick an allocator that works slower, because its implementation is just simpler and doesn’t occupy much space in the final binary.</p> 比如说, 在实现固件时, 你可能会选择一个工作较慢的分配器, 因为它的实现更简单, 在最终二进制文件中不占用太多空间.</p> (some would argue that embeddeed programs shouldn’t allocate, yadda yadda, but you get the idea – replace firmware with wasm and you end up with the same problem.)</p> （有些人会争论说嵌入式程序不应该分配内存, 等等等等, 但你懂我意思: 把固件替换为 WASM, 你最终会遇到同样的问题. ）</p> mimalloc</code> is an allocator that fights tooth and nail for performance - and while most applications don’t have to worry about allocation performance, in our case internal benchmarks have proven it gives us extra 10% for free; when your response times have to be within milliseconds, this matters.</p> mimalloc</code> 是一个为性能而生的分配器: 虽然大多数应用程序不必担心分配性能, 但在我们的情况下, 内部基准测试证明它无需额外配置即给我们带来额外的 10% 性能提升；当你的响应时间必须在毫秒内时, 这很重要.</p> But there’s a catch.</p> 但有一个陷阱.</p> Désenchantée \| 失望</h2> That program from before, on my x86_64 Linux machine it allocates around 4 GB of memory and it remains on this level through the refreshing.</p> 之前的那个程序, 在我的 x86_64 Linux 机器上分配大约 4 GB 内存, 并在刷新过程中保持在这个水平.</p> This makes sense, right? We’re using lazy iterators, replacing stuff in place one-by-one, there’s no reason we’d need more RAM.</p> 这是有道理的, 对吧？我们使用惰性迭代器, 逐个地就地替换东西, 没有理由需要更多 RAM.</p> But if you use mimalloc</code>:</p> 但如果你使用 mimalloc</code>：</p> use</span> mimalloc::</span></span>MiMalloc;</span> </span> </span>#</span>[</span>global_allocator</span>]</span></span> </span>static</span> GLOBAL</span>:</span> MiMalloc =</span> MiMalloc;</span> </span></code></pre> … the program will first allocate 4 GB and then allocate extra 4 GB during the refreshing, oh noes!</p> … 程序将首先分配 4 GB, 然后在刷新期间分配额外的 4 GB, 哦 f**!</p> Getting to this point already took three days of my life - believe me or not, when faced with 200k lines of Arc-ridden Rust code that seems to generate a memory leak, one’s first thought is not “let’s try with different allocator”, but rather “probably something’s holding onto an Arc for too long”.</p> 确认这一点已经花费了我三天的生命: 信不信由你, 当面对 20 万行充满 Arc 的 Rust 代码似乎产生内存泄漏时, 人们的第一个想法不是 “让我们尝试不同的分配器”, 而是 “可能有什么东西持有 Arc 太久了”.</p> And so I’ve valgrind-ed. I’ve perf-ed. I’ve analyzed assembly. I’ve headbanged and I’ve cried.</p> 我用了 valgrind</code>. 我用了 perf</code>. 我分析了汇编. 我撞头, 我哭.</p> No more.</p> 不再这样了.</p> From now on I’m always assuming it’s someone else’s fault - it’s the allocator, it’s the compiler, it’s that crate Mike pulled last night. WHY DO YOU HATE ME MIKE, WHY ARE YOU PULLING RANDOM CRATES TO MY PURE ~~~tv noise~~~</p> 从现在开始, 我将假设这是别人的错: 是分配器的错, 是编译器的错, 是 Mike 昨晚拉取的那个 crate 的错. (碎碎念)</p> Remède \| 解决方案</h2> Allocators have different characteristics for a reason - they do some things differently between each other. What do you think mimalloc</code> does that could account for this behavior?</p> 分配器有不同的特性是有原因的: 它们彼此之间做一些不同的事情. 你认为 mimalloc</code> 做了什么可能导致这种行为？</p> Let me give you two hints, two pieces of code that solve the problem, but feel cursed:</p> 让我给你两个提示, 两段解决问题但感觉被诅咒的代码：</p> //</span> Approach 1: </span></span>fn</span> </span>main</span></span>(</span></span>)</span></span></span></span> </span>{</span> </span></span></span> let</span> state =</span> thread::</span></span>spawn(</span>\|</span></span></span>\|</span></span> </span>{</span> </span></span></span></span></span></span> Arc::</span></span>new(</span>RwLock::</span></span>new(</span>State::</span></span>new(</span></span>)</span></span></span>)</span></span></span>)</span></span> </span></span></span></span></span></span> </span>}</span></span></span></span>)</span></span>.</span>join</span>(</span></span>)</span></span>.</span>unwrap</span>(</span></span>)</span></span>;</span> </span></span></span> </span></span></span> /</span> ... /</span></span> </span></span></span></span>}</span></span></span> </span> </span>//</span> Approach 2: </span></span>fn</span> </span>main</span></span>(</span></span>)</span></span></span></span> </span>{</span> </span></span></span> /</span> ... /</span></span> </span></span></span> </span></span></span> loop</span> {</span> </span></span></span></span> Box</span>::</span></span>new(</span>1234</span></span>)</span></span>;</span> </span></span></span></span> </span>}</span></span> </span></span></span></span>}</span></span></span> </span></code></pre> Any ideas? Last chance to win a plushie polar bear!</p> 有什么想法吗？赢得毛绒北极熊的最后机会!</p> Alright then, the issue is that mimalloc assumes that every thread allocates every now and then.</p> 好吧, 问题是 mimalloc</code> 假设每个线程时不时地分配内存.</p> Every now and then during malloc()</code>, mimalloc</code> performs some internal bookkeeping, so when a thread goes to sleep (say, because it delegates handling HTTP requests into a separate thread pool…), this bookkeeping doesn’t happen (for that particular thread).</p> 在 malloc()</code> 期间, mimalloc</code> 时不时地执行一些内部整理, 所以当一个线程进入睡眠状态时（比如, 它将处理 HTTP 请求委托给一个单独的线程池…）, 这种整理不会发生（对于那个特定的线程）.</p> The most nasty edge case that can happen here, and the one that we’ve stumbled upon, is when your thread allocates a lot of data, then launches other threads to work on that data, and then goes to sleep. As other threads work on memory and override stuff, Rust destructors are launched properly, but the underlying memory blocks simply get marked as “to be released”.</p> 这里可能发生的最讨厌的边缘情况, 也是我们遇到的情况, 是当你的线程分配大量数据, 然后启动其他线程来处理这些数据, 然后进入睡眠状态. 当其他线程处理内存并覆盖东西时, Rust 析构函数被正确启动, 但底层内存块只是被标记为 “待释放”.</p> Under normal conditions, these blocks get processed a moment later, during a call to malloc()</code> on the thread that created them - but if that thread is asleep, those blocks never become available again (unless the thread dies, of course).</p> 在正常条件下, 这些块会在稍后处理, 在创建它们的线程调用 malloc()</code> 期间. 但如果那个线程在睡眠, 这些块永远不会再次可用（当然, 除非线程终止）.</p> To be sure, the problem is not that the memory is not returned to the kernel - that’s alright. It’s that unless this bookkeeping happens, mimalloc can’t even use the memory for itself - all this free estate just lays there, dormant:</p> 可以肯定的是, 问题不是内存没有返回给内核, 那没关系. 问题是除非这种整理发生, 否则 mimalloc</code> 甚至不能为自己使用内存: 所有这些空闲空间就躺在那里, 休眠：</p> https://github.com/microsoft/mimalloc/issues/537</a></li> https://github.com/microsoft/mimalloc/issues/214</a></li> </ul> Anyway, the solution we went with was to keep all refreshing on the same thread - when program starts, we spawn a dedicated refreshing-thread and use channels to let it know to do its thing.</p> 无论如何, 我们采用的解决方案是将所有刷新保持在同一个线程上: 当程序启动时, 我们生成一个专用的刷新线程, 并使用通道让它知道要做什么.</p> So yeah, that was fun; and health-wise probably more like seven cigarettes.</p> 所以是的, 那很有趣；从健康角度来说, 可能更像七支香烟.</p> 推荐阅读: https://www.cnblogs.com/linkwk7/p/11221730.html</a></p> </blockquote> 随笔一则 2025-04-26T00:00:00+00:00 use</span> std::</span></span>{</span>borrow::</span></span>Cow,</span> hash::</span></span>Hash</span>}</span></span>;</span> </span> </span>struct</span> </span>SniMap</span></span>(</span>HashMap<</span>PeerKey<</span>'static</span>></span></span>, Peer></span></span></span>)</span></span>;</span> </span> </span>impl</span> </span>SniMap</span> </span>{</span> </span></span></span> ///</span> Get peer by SNI. </span></span></span></span> pub</span>(</span>crate</span></span>)</span></span> fn</span> </span>get</span></span><</span>'s</span>, 'sni</span>:</span> 's</span>></span></span>(</span>&</span>'s</span> self</span>, sni</span>:</span> &</span>'sni</span> str</span></span>)</span></span></span></span> -></span> Option</span><</span>&</span>'s</span> Peer></span></span></span> </span>{</span> </span></span></span></span></span> self</span>.</span>0.</span>get</span>(</span>&</span>PeerKey::</span></span>Exact(</span>Cow::</span></span>Borrowed(</span>sni</span>)</span></span></span>)</span></span></span>)</span></span>.</span>or_else</span>(</span>\|</span></span></span>\|</span></span> </span>{</span> </span></span></span></span></span></span></span></span> self</span>.</span>0.</span>get</span>(</span>&</span>PeerKey::</span></span>Subdomain(</span>Cow::</span></span>Borrowed(</span> </span></span></span></span></span></span></span></span></span></span></span> sni.</span>split_once</span>(</span>'</span>.'</span></span></span>)</span></span>.</span>map</span>(</span>\|</span></span></span>(</span></span>_,</span> prior</span></span>)</span></span>\|</span></span> </span>prior</span></span>)</span></span>.</span>unwrap_or</span>(</span>sni</span>)</span></span>,</span> </span></span></span></span></span></span></span></span></span></span></span> </span>)</span></span></span>)</span></span></span>)</span></span> </span></span></span></span></span></span></span></span> </span>}</span></span></span></span>)</span></span> </span></span></span></span></span> </span>}</span></span></span> </span></span></span></span>}</span></span></span> </span> </span>#</span>[</span>derive</span>(</span></span></span>Debug,</span> PartialEq,</span> Eq</span></span>)</span></span></span>]</span></span> </span>enum</span> PeerKey</span><'k> {</span> </span></span></span> ///</span> Match exactly the SNI. This is the default mode. </span></span></span></span> ///</span> </span></span></span></span> ///</span> Will be serialized or deserialized as `example.com`. </span></span></span></span> Exact(</span>Cow<</span>'k</span>, str</span>></span></span></span>)</span></span>,</span> </span></span></span> </span></span></span> ///</span> Subdomain match </span></span></span></span> ///</span> </span></span></span></span> ///</span> Should be serialized or deserialized as `domain:example.com`. </span></span></span></span> ///</span> </span></span></span></span> ///</span> ## Notice </span></span></span></span> ///</span> </span></span></span></span> ///</span> Matches direct subdomains only; does not match nested subdomains </span></span></span></span> ///</span> (second-level or deeper). </span></span></span></span> ///</span> </span></span></span></span> ///</span> Take `domain:example.com` as an example, it will match `.example.com` </span></span></span></span> ///</span> but not `..example.com`, etc. </span></span></span></span> Subdomain(</span>Cow<</span>'k</span>, str</span>></span></span></span>)</span></span>,</span> </span></span></span></span>}</span></span></span> </span> </span>impl</span> </span>Hash for</span></span> PeerKey</span><</span>'_</span>></span></span> </span>{</span> </span></span></span> fn</span> </span>hash</span></span><</span>H:</span> std::</span></span>hash::</span></span>Hasher></span></span>(</span>&</span>self</span>, state</span>:</span> &</span>mut</span> H</span>)</span></span></span></span> </span>{</span> </span></span></span></span></span> match</span> self</span> {</span> </span></span></span></span></span></span> PeerKey::</span></span>Exact(</span>s</span>)</span></span> =></span> s.</span>hash</span>(</span>state</span>)</span></span>,</span> </span></span></span></span></span></span> PeerKey::</span></span>Subdomain(</span>s</span>)</span></span> =></span> {</span> </span></span></span></span></span></span></span> state.</span>write</span>(</span>b</span>"</span>domain:"</span></span></span>)</span></span>;</span> </span></span></span></span></span></span></span> </span></span></span></span></span></span></span> s.</span>hash</span>(</span>state</span>)</span></span> </span></span></span></span></span></span></span> </span>}</span></span> </span></span></span></span></span></span> </span>}</span></span> </span></span></span></span></span> </span>}</span></span></span> </span></span></span></span>}</span></span></span> </span> </span>struct</span> </span>Peer</span> </span>{</span> </span></span></span> //</span> ... </span></span></span></span></span>}</span></span></span> </span></code></pre> 非常平平无奇的代码. 于是有新的需求: 想缓存 get 的结果 (把按 domain:example.com</code> 匹配到的 sub.example.com</code> 当 full:sub.example.com</code> 写入表内), 达到下次读哈希表一次就能把 Peer 读出来.</p> 有这么几个方案:</p> 改用三方库 dashmap</code> 提供的 DashMap, 类似 RwLock 但 API 层面</em> 是 Lock-free 的.</li> 套一层 Mutex / RwLock.</li> RefCell</del> 毙掉, 我们需要 Send + Sync, 应该用其线程安全版本: RwLock</em></li> </ul> 但事实上都是不可行的, 为什么? 欢迎 Rust 初学者自行查阅资料 (问 AI 也行)~</p> 答案 (实际上编译器已经提示了):</p> 对于具有内部可变性的 Cell 类似物, 子类型型变要求是不变 (invariant) 的1</a></sup>. 本例中 DashMap 内部用了 lock_api 库的 RwLock, 这玩意内部用了 UnsafeCell, 故相应字段涉及的泛型类型 K 要求是不变的.</p> </li> 不能返回本地变量 (拿到的 &Peer 只能活得和上锁后拿到的 Guard 一样久). 起码在当前的 API 设计下不能这么干. 当然, 写出来 get_and_map</code> 一类的奇怪 API 也不是不行.</p> </li> </ul> 评价: 写 Rust 的福报</del></p> 参见 https://twir.han.rs/595/rust-type-system-deep-dive#lifetime-variance-and-static–%E7%94%9F%E5%91%BD%E5%91%A8%E6%9C%9F%E5%9E%8B%E5%8F%98%E5%92%8C-static</a> ↩</a></p> </li> </ol> </footer>

i.han.rs

Instructions on building RFC documents locally

2026-04-30T00:00:00+00:00

Prerequisites</h2>

Python</h3>

Python 3.x, here we use Python 3.14.1</li>

Python virtual environment (optional but recommended)</li> </ol>

Using pyenv:</p>

pyenv</span></span> install 3.14.1</span>
</span>pyenv</span></span> virtualenv 3.14.1 rfc</span>
</span>pyenv</span></span> activate rfc</span>
</span></code></pre>
And then install the required packages:</p>
pip</span></span> install sortedcontainers</span>
</span></code></pre>
NodeJS</h3>
We make use of aasvg</code>, just install it globally:</p>
npm</span></span> install -</span>g</span> aasvg</span>
</span></code></pre>
IETF toolchains</h3>
We need kramdown-rfc</code> and xml2rfc</code>:</p>
apt</span></span> install kramdown-rfc xml2rfc</span>
</span></code></pre>
And then run make</code> to install other dependencies. This will try to build the document, but it will fail.</p>
Building the document</h2>
Run the following command to build the HTML:</p>
cat</span></span> draft-ietf-tls-rfc8446bis.md</span> |</span> lib/trace.sh</span></span> -</span>v</span> draft-ietf-tls-rfc8446bis.xml -</span>s</span> preprocessor python3 mk-appendix.py</span> |</span> kramdown-rfc</span></span> --</span>v3</span></span> |</span>  lib/trace.sh</span></span> -</span>v</span> -</span>q</span> draft-ietf-tls-rfc8446bis.xml -</span>s</span> v2v3 xml2rfc -</span>q</span> --</span>rfc-base-url</span> https://www.rfc-editor.org/rfc/ --</span>id-base-url</span> https://datatracker.ietf.org/doc/html/ --</span>allow-local-file-access</span> --</span>cache</span>=</span>./.refcache --</span>v2v3</span> /dev/stdin -</span>o</span> /dev/stdout ></span> draft-ietf-tls-rfc8446bis.xml</span> &&</span> xml2rfc</span></span> draft-ietf-tls-rfc8446bis.xml --</span>html</span></span>
</span></code></pre>
This is modified from the CI build script, removing step lib/trace.sh -v -q draft-ietf-tls-rfc8446bis.xml -s venue python3 lib/add-note.py</code> since it failed locally for me.</p>
If you want a cleaner way, run make clean</code> in advance.</p>



了解和使用 Rootless Podman
2026-02-04T00:00:00+00:00
导语</h2>
我们需要意识到:</p>

日常使用 “root” 本来就存在极大安全隐患.</li>
Docker 的守护程序设计, 导致 Docker 并不能真正实现 Rootless, Docker Rootless 的配置也是极其麻烦.</li>
在容器中运行的进程与在宿主上直接运行的其他进程没有什么不同. 部分镜像遵循最优实践, 以自定义用户启动程序, 安全性尚可; 但部分镜像直接以容器内的 “root” 启动进程, 如果在使用该镜像时没有指定用户或配置用户映射, 则近似等价于以宿主机的 “root” 启动了程序; 如果还指定了 --privileged</code>, 安全性直接归零.</li>
</ol>
Podman 由于其无守护程序设计, 天然支持 Rootless 模式.</p>
安装 Podman</h2>
参考官方文档 https://podman.io/docs/installation</a>.</p>
在 Debian 13 中, 直接通过 apt 安装即可:</p>
sudo</span></span> apt update</span>
</span>sudo</span></span> apt install podman</span>
</span></code></pre>
完成安装后, 执行 podman info</code> 可以查看 Podman 的详细配置信息.</p>
需要注意, 截止至本文写作时, 虽然 Podman 的最新 stable 版本是 5.7.1, 但 Debian 13 官方软件包提供的 Podman 的版本是 5.4.2, 本文所有例子均基于 5.4.2 测试.</p>
Rootless Podman 基本概念</h2>
在正式开始使用 Podman 前, 我们需要了解一些基本概念.</p>
命名空间 (Namespace)</h3>
命名空间是 Linux 提供的一种内核级别环境隔离的机制, 容器化技术重度使用了命名空间机制来实现容器的隔离. 关于命名空间的详细内容此处不再赘述, 读者可以阅读文末的参考文献, 此处仅介绍我们最常打交道的, 也是给普通用户带来最多 “问题” 的用户命名空间和网络命名空间.</p>
用户命名空间</h4>
不严谨地说, 用户命名空间提供了一种使容器内用户能够映射到宿主机上的(通常是非特权的)用户的机制, 而容器中的 “root” 仅在容器的用户命名空间内具有 “完全” 的权限, 对容器的用户命名空间外的资源的操作权限则被限制为 “映射” 到的 “普通用户” 的操作权限, 正如官方文档所言: “Rootless Podman is not, and will never be, root”.</p>
默认情况下, 通过 Rootless Podman 运行容器时, 容器内的 “root” (UID=0, GID=0) 会被映射为运行容器的用户, 其他 UID (GID) 则映射至宿主机上的高位 UID (GID), 这些高位 UID (GID) 往往并没有对应的宿主机用户(组), 则文件权限按照 “Others” 处理, 拥有的任何文件对象将被视为由 “nobody” (65534, kernel.overflowuid</code>) 拥有.</p>
可以通过 podman-unshare</code></a> 工具创建并进入一新用户命名空间, 以便捷地验证上述映射关系 (值得一提, 在调试 Rootless Podman 的权限问题时我们会经常和这个工具打交道). 如:</p>
> id
</span>uid=1000(hantong) gid=1000(hantong) groups=1000(hantong),4(adm),20(dialout),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev)
</span>> podman unshare
</span>> id
</span>uid=0(root) gid=0(root) groups=0(root),65534(nogroup)
</span>> cat /proc/self/uid_map
</span>         0       1000          1
</span>         1     100000      65536
</span>> cat /proc/self/gid_map
</span>         0       1000          1
</span>         1     100000      65536
</span>> exit
</span></code></pre>
可以看到, 容器内的 UID (GID) 0 被映射为宿主机的 UID (GID) 1000; 从 UID (GID) 1 开始的 65536 个 UID (GID) 逐个被映射为宿主机的 UID (GID) 100000、100001, 以此类推.</p>
这里的映射规则是由 /etc/subuid</code> 和 /etc/subgid</code> 文件定义的, 通常在使用 adduser</code> (addgroup</code>) 添加用户(组)时会自动设置:</p>
> cat /etc/subuid
</span>hantong:100000:65536
</span>> cat /etc/subgid
</span>hantong:100000:65536
</span></code></pre>
前面提到, 默认情况下容器中的 “root” 被映射为运行容器的用户, 对容器外资源的访问权限与当前用户 “基本” 一致. 参考下面的例子, 相信读者就知道 “映射” 是什么含义了:</p>
> ls -ildn /home/hantong
</span>143631 drwx------ 17 1000 1000 4096 Feb  8 21:53 /home/hantong
</span>> podman unshare ls -ildn /home/hantong
</span>143631 drwx------ 17 0 0 4096 Feb  8 21:53 /home/hantong
</span></code></pre>
> podman unshare touch /tmp/test
</span>> podman unshare ls -iln /tmp/test
</span>3432 -rw-r--r-- 1 0 0 0 Feb  8 21:54 /tmp/test
</span>> ls -iln /tmp/test
</span>3432 -rw-r--r-- 1 1000 1000 0 Feb  8 21:54 /tmp/test
</span></code></pre>
如果不幸地, 你的容器进程通过某些安全漏洞逃逸了容器, 那么它也只能以映射到的高位 UID (GID) 的权限 (或者说, “nobody” 的权限) 在宿主机上运行, 这大大降低了容器逃逸后的危害.</p>
网络命名空间</h4>
(TBD.)</p>
网络命名空间负责提供容器内网络与宿主机网络以及其他容器网络的隔离. 默认情况下, 各个容器有其独立的网络命名空间, 而不在同一网络命名空间中的进程无法直接通信.</p>
Docker Rootless 和旧版本 Podman 使用 slirp4netns</code> 用户态网络驱动来实现 Rootless 网络, 性能较差; Podman v5 以后, 默认使用 “性能更优” 的 pasta</code> 代替 slirp4netns</code>. 相对于 slirp4netns</code>, pasta</code> 的特点:</p>

pasta</code> 支持 IPv6;</li>
pasta</code> 使用主机中的接口名称, 从主机复制 IP 地址并使用主机中的网关地址.</li>
</ol>
下面是一个例子:</p>
> podman unshare --rootless-netns ip addr
</span>1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
</span># ...
</span>2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc fq state UNKNOWN group default qlen 1000
</span>    link/ether 52:3a:d5:14:43:4c brd ff:ff:ff:ff:ff:ff
</span>    inet 192.168.1.200/24 brd 192.168.1.255 scope global eth0
</span>       valid_lft forever preferred_lft forever
</span># ...
</span>> podman unshare ip addr
</span>1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
</span># ...
</span>2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 1000
</span>    link/ether bc:24:11:46:30:a6 brd ff:ff:ff:ff:ff:ff
</span>    altname enp6s18
</span>    altname enxbc24114630a6
</span>    inet 192.168.1.200/24 brd 192.168.1.255 scope global eth0
</span>       valid_lft forever preferred_lft forever
</span># ...
</span>3: lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 1000
</span>    link/ether bc:24:11:40:61:e6 brd ff:ff:ff:ff:ff:ff
</span>    altname enp6s19
</span>    altname enxbc24114061e6
</span>    inet 172.16.0.2/24 brd 172.16.0.255 scope global lan0
</span>       valid_lft forever preferred_lft forever
</span># ...
</span></code></pre>
> curl http://127.0.0.1:1111/ -I
</span>HTTP/1.1 200 OK
</span>content-type: text/html
</span>content-length: 12252
</span>date: Mon, 09 Feb 2026 05:11:24 GMT
</span>
</span>> podman unshare --rootless-netns curl http://127.0.0.1:1111/ -I
</span>curl: (7) Failed to connect to 127.0.0.1 port 1111 after 0 ms: Could not connect to server
</span></code></pre>
存储驱动</h3>
(TBD.)</p>

OverlayFS 和 VFS 的权限表现似乎有差异.</li>
</ol>
网络</h3>
(TBD.)</p>
参考文档 https://docs.podman.io/en/latest/markdown/podman-run.1.html#network-mode-net</a></p>
Podman 提供多种网络模式:</p>


bridge</code> (桥接).</p>
Rootful Podman 默认, 直接桥接到主机网络接口.</p>
</li>

none</code></p>
创建网络命名空间, 但是不配置网络, 容器内没有任何网络接口.</p>
</li>

container:id</code></p>
加入另一个容器的网络命名空间.</p>
(笔者注: 更推荐使用 Pod 管理需要通过网络相互访问的容器.)</p>
</li>

host</code></p>
复用主机的网络命名空间. 虽然性能很好, 但这也使容器能够完全访问宿主机的 abstract unix socket 以及绑定到 localhost 的 TCP / UDP socket, 存在安全隐患.</p>
</li>

pasta[:OPTIONS,…]</code></p>
Rootless Podman 默认, 创建一个新的网络命名空间, 使用 pasta</code> 创建用户态网络堆栈.</p>
</li>
</ol>
其他模式此处暂不展开, 如有需要参考官方文档.</p>
值得一提, pasta</code> 的性能对比于直接使用 host</code> 模式仍然有不小的差距. 笔者在个人的存储服务器上进行了简要测试: TCP 吞吐量由于 splice</code> 的使用下降幅度不大, 即便是重负载仍然能有 host</code> 模式下八九成; UDP 吞吐量则受机器负载影响大, 笔者测试时, 遇到机器本身处于重负载状态, UDP 吞吐量最差可能暴跌至 host</code> 模式下的两三成. 造成该问题的原因大抵是 Linux 内核本来对 UDP 优化就差, 缺乏 TCP splice</code> 那种零拷贝的机制; 此外 pasta 应该也没用上 UDP GSO / GRO, 浪费大量 CPU 时间, 在 CPU 受限时自然性能下降.</p>
配置 Podman</h2>


配置镜像仓库</p>
Podman 默认设置下无法像 Docker 那样不提供镜像源时默认从 docker.io</code> 拉取镜像.</p>
建议配置 registries.conf</code> 文件:</p>
> sudo nano /etc/containers/registries.conf 
</span></code></pre>
修改 unqualified-search-registries</code> 字段, 添加 docker.io</code>:</p>
unqualified-search-registries</span> =</span></span> ["docker.io"</span>]
</span></code></pre>
</li>
</ol>
运行 Rootless Podman 容器</h2>
完成上述配置后, 即可以非 root 用户运行 Podman 容器. 测试如下:</p>
> podman run hello
</span>!... Hello Podman World ...!
</span>
</span>         .--"--.
</span>       / -     - \
</span>      / (O)   (O) \
</span>   ~~~| -=(,Y,)=- |
</span>    .---. /`  \   |~~
</span> ~/  o  o \~~~~.----. ~~
</span>  | =(X)= |~  / (O (O) \
</span>   ~~~~~~~  ~| =(Y_)=-  |
</span>  ~~~~    ~~~|   U      |~~
</span>
</span>Project:   https://github.com/containers/podman
</span>Website:   https://podman.io
</span>Desktop:   https://podman-desktop.io
</span>Documents: https://docs.podman.io
</span>YouTube:   https://youtube.com/@Podman
</span>X/Twitter: @Podman_io
</span>Mastodon:  @Podman_io@fosstodon.org
</span></code></pre>
当然, Rootless Podman 的配置和使用由于命名空间等问题有和 Docker 不同的地方, 下面不完整地列举一些.</p>


需要配置 /etc/subuid</code> 和 /etc/subgid</code> 文件.</p>
一般来说, 通过 useradd</code> 命令创建用户时, 系统会自动为新用户在 /etc/subuid</code> 和 /etc/subgid</code> 中分配 UID 和 GID 范围; 如果是手动创建用户, 则需要手动添加相应条目. 例如, 为用户 hantong</code> 分配 UID 和 GID 范围:</p>
sudo</span></span> usermod --</span>add-subuids</span> 100000-165535 --</span>add-subgids</span> 100000-165535 hantong</span>
</span></code></pre>
请注意, 每个用户的子 UID (GID) 范围不应重叠, 否则可能导致权限冲突和安全问题.</p>
</li>

需要解除 Linux 对非 root 用户绑定 1024 以下端口的限制.</p>
如果需要绑定如 80 / 443 端口的话, 可以通过以下命令解除该限制:</p>
sudo</span></span> sysctl -</span>w</span> net.ipv4.ip_unprivileged_port_start=0</span>
</span></code></pre>
</li>

用户配置文件位置和生效顺序问题.</p>
以下三个目录保存了 Podman 的配置文件:</p>

/usr/share/containers</code></li>
/etc/containers</code></li>
${XDG_CONFIG_HOME}/containers</code> (默认 ~/.config/containers</code>)</li>
</ol>
包含以下配置文件:</p>


containers.conf</code></p>
按前述顺序, 后者配置项覆盖前者.</p>
</li>

storage.conf</code></p>
在 Rootless Podman 中, /etc/containers/storage.conf</code> 中的某些字段将被忽略:</p>
graphroot</span>=</span></span>""</span>
</span> container</span> </span>storage graph dir (default:</span> "/var/lib/containers/storage"</span>)
</span> Default</span> </span>directory to store all writable content created by container storage programs.</span>
</span>
</span>runroot</span>=</span></span>""</span>
</span> container</span> </span>storage run dir (default:</span> "/run/containers/storage"</span>)
</span> Default</span> </span>directory to store all temporary writable content created by container storage programs.</span>
</span></code></pre>
在 Rootless Podman 中, 这些字段默认为:</p>
graphroot</span>=</span></span>"${XDG_DATA_HOME}/containers/storage"</span>
</span>runroot</span>=</span></span>"${XDG_RUNTIME_DIR}/containers"</span>
</span></code></pre>
XDG_DATA_HOME</code> 默认为 ~/.local/share</code>, XDG_RUNTIME_DIR</code> 默认为 /run/user/<uid></code> (systemd).</p>
</li>

registries.conf</code></p>
按前述顺序读取.</p>
</li>

授权文件</p>
podman login</code> 和 podman logout</code> 命令使用的默认授权文件是 ${XDG_RUNTIME_DIR}/containers/auth.json</code>.</p>
</li>
</ol>
</li>

命名空间隔离带来的问题.</p>
Rootless Podman 在执行用户命名空间隔离时提供了以下模式, 需要我们了解:</p>


host</code> (默认): 映射当前用户的 UID (GID) 到容器内的 “root” (UID=0, GID=0), 其余 UID (GID) 按照前述映射规则依次映射为宿主机高位 UID (GID).</p>
> podman run -it --rm --userns=host --name="test" --replace debian:trixie-slim bash
</span>root@0df58777f431:/# id
</span>uid=0(root) gid=0(root) groups=0(root)
</span>root@0df58777f431:/# sleep 3000
</span>^C
</span>root@0df58777f431:/# useradd test
</span>root@0df58777f431:/# su test
</span>$ id
</span>uid=1000(test) gid=1000(test) groups=1000(test)
</span>$ sleep 3000
</span>^C
</span>$ exit
</span>root@0df58777f431:/# exit
</span>exit
</span></code></pre>
# 以容器内 root 用户 (UID=0) 运行 sleep 时
</span>> ps -ax -o pid,user,group,uid,gid,args | grep "sleep 3000"
</span>20953 hantong  hantong   1000  1000 sleep 3000
</span># 以容器内 test 用户 (UID=1000) 运行 sleep 时
</span>> ps -ax -o pid,user,group,uid,gid,args | grep "sleep 3000"
</span>21384 100999   100999   100999 100999 sleep 3000
</span></code></pre>
</li>

keep-id</code>: 类似 host</code>, 但是映射当前用户的 UID (GID) 到容器内的相同 UID (GID). 同时, 除非手动指定用户, 忽视镜像的 USER</code> 配置, 在当前用户的 UID 下运行 init 进程.</p>
> podman run -it --rm --userns=keep-id --name="test" --replace debian:trixie-slim bash
</span>hantong@cea54e0fd3fb:/$ id
</span>uid=1000(hantong) gid=1000(hantong) groups=1000(hantong)
</span>hantong@cea54e0fd3fb:/$ exit
</span>exit
</span>> id
</span>uid=1000(hantong) gid=1000(hantong) groups=1000(hantong),27(sudo)
</span></code></pre>
</li>

“nomap”: 不映射宿主机用户, 容器内的所有 UID (GID) 按照前述映射规则依次映射为宿主机高位 UID (GID).</p>
> podman run -it --rm --userns=nomap --name="test" --replace debian:trixie-slim bash
</span>root@f3794e591a2c:/# id
</span>uid=0(root) gid=0(root) groups=0(root)
</span>root@f3794e591a2c:/# sleep 3000
</span>^C
</span>root@f3794e591a2c:/# useradd test
</span>root@f3794e591a2c:/# su test
</span>$ sleep 3000
</span>^C
</span>$ exit
</span>root@f3794e591a2c:/# exit
</span>exit
</span></code></pre>
# 以容器内 root 用户 (UID=0) 运行 sleep 时
</span>> ps -ax -o pid,user,group,uid,gid,args | grep "sleep 3000"
</span>28326 100000   100000   100000 100000 sleep 3000
</span># 以容器内 test 用户 (UID=1000) 运行 sleep 时
</span>> ps -ax -o pid,user,group,uid,gid,args | grep "sleep 3000"
</span>28563 101000   101000   101000 101000 sleep 3000
</span></code></pre>
</li>
</ol>
很多时候, 我们需要将宿主机的某个目录挂载到容器内, 使用 Docker 外加关掉 (或者说根本没开启) SELinux 自然可以靠 “root” 的力量忽视 (暴力解决</del>) 权限问题, 但 Rootless Podman 就不行了.</p>
两种情况:</p>


镜像没有配置 USER</code>:</p>
此时, 默认以容器内的 “root” (UID=0, GID=0) 运行. 容器内的 “root” 在 Rootless Podman 默认的用户命名空间模式 (“–userns=host”) 下如前所述被映射到宿主机下运行容器的当前用户, 文件系统权限表现和当前用户基本</strong>一致.</p>
</li>

当镜像遵循最佳实践配置了 (rootless) USER=UID[:GID]</code>:</p>
此时, 容器内进程以容器内的该 UID (GID) 运行, 而容器内 UID (GID) 在 Rootless Podman 默认的用户命名空间模式 (“–userns=host”) 下如前所述被映射到宿主机下的高位 UID (GID), 此时文件系统权限表现和宿主机上的 “Others” 一样了.</p>
</li>
</ol>
实例:</p>
> podman run -d --restart=unless-stopped -v /home/hantong/.config/openlist:/opt/openlist/data -p 5244:5244 --name="openlist" --replace openlistteam/openlist:latest
</span>> podman logs openlist
</span>Error: Current user does not have write and/or execute permissions for the ./data directory: /opt/openlist/data
</span># ...
</span></code></pre>
#</span> ...
</span></span>ARG </span>USER=openlist
</span>ARG </span>UID=1001
</span>ARG </span>GID=1001
</span>#</span> ...
</span></span>RUN addgroup -g ${GID} ${USER} && \
</span>    adduser -D -u ${UID} -G ${USER} ${USER} && \
</span>    mkdir -p /opt/openlist/data
</span>#</span> ...
</span></span>USER ${USER}
</span>#</span> ...
</span></span>CMD [ "/entrypoint.sh" ]
</span></code></pre>
在这个案例中, “/entrypoint.sh” 是以容器内的 UID=1001、GID=1001 运行的, 被映射到宿主机下的 UID=101000、GID=101000. 显然, 其无法访问权限为 600, 归属 UID=1000、GID=1000 的的宿主机目录 /home/hantong</code>. 此时, 我们可以配置 Podman 的用户命名空间模式为 “keep-id”, 以使 init 进程 “以当前用户的 UID (GID) 运行”, 从而对 /home/hantong</code> 目录具有访问权限, 如:</p>
> podman run -d --userns=keep-id --restart=unless-stopped -v /home/hantong/.config/openlist:/opt/openlist/data -p 5244:5244 --name="openlist" --replace openlistteam/openlist:latest
</span>> podman logs openlist
</span>INFO[2026-02-08 07:14:43] reading config file: /opt/openlist/data/config.json 
</span>INFO[2026-02-08 07:14:43] load config from env with prefix:            
</span>INFO[2026-02-08 07:14:43] max buffer limit: 1502MB                     
</span>INFO[2026-02-08 07:14:43] mmap threshold: 4MB                          
</span>INFO[2026-02-08 07:14:43] init logrus...                               
</span>start HTTP server @ 0.0.0.0:5244
</span>> ps -ax -o pid,user,group,uid,gid,comm | grep openlist
</span>31334 101000   101000   101000 101000 openlist
</span>> podman exec -it openlist bash
</span>695025dade25:/opt/openlist$ id
</span>uid=1001(openlist) gid=1001(openlist) groups=1001(openlist)
</span>695025dade25:/opt/openlist$ ps -o pid,user,group,comm | grep openlist
</span>   1 openlist openlist openlist
</span>  26 openlist openlist bash
</span>  28 openlist openlist ps
</span>  29 openlist openlist grep
</span>695025dade25:/opt/openlist$ exit
</span>exit
</span></code></pre>
当然, 此时非 init 进程还是以 USER 配置的 UID (GID) 运行的:</p>
> ls -aln /home/hantong/.config/openlist
</span>total 276
</span>drwxrwxrwx  4   1000   1000   4096 Jan 31 16:36 .
</span>drwxrwxr-x 14   1000   1000   4096 Jan 31 16:23 ..
</span>-rw-r--r--  1 101000 101000   2899 Feb  8 15:14 config.json
</span>-rw-r--r--  1 101000 101000   4096 Jan 31 16:28 data.db
</span>-rw-r--r--  1 101000 101000  32768 Feb  8 15:14 data.db-shm
</span>-rw-r--r--  1 101000 101000 222512 Feb  8 15:14 data.db-wal
</span>drwxr--r--  2 101000 101000   4096 Jan 31 16:28 log
</span>drwxr-xr-x  2 101000 101000   4096 Jan 31 16:28 temp
</span></code></pre>
为了避免编辑配置文件还得 sudo</code> 的麻烦, 建议配置为 --userns=keep-id:uid=${UID},gid=${GID}</code>, 其中 UID, GID 为构建镜像时所配置的用户的数字 ID (或者直接指定用户覆盖镜像设置), 如:</p>
> podman run -d --userns=keep-id:uid=1001,gid=1001 --restart=unless-stopped -v /home/hantong/.config/openlist:/opt/openlist/data -p 5244:5244 --name="openlist" --replace openlistteam/openlist:latest
</span>4fd47db9916432a8d4631b99c6a6fedd9a9c94c8ca3580e40f0f6bde41b83102
</span>> ls -aln /home/hantong/.config/openlist
</span>total 260
</span>drwxrwxr-x  4 1000 1000   4096 Feb  8 16:13 .
</span>drwxrwxr-x 14 1000 1000   4096 Feb  8 16:13 ..
</span>-rw-r--r--  1 1000 1000   2842 Feb  8 16:13 config.json
</span>-rw-r--r--  1 1000 1000   4096 Feb  8 16:13 data.db
</span>-rw-r--r--  1 1000 1000  32768 Feb  8 16:13 data.db-shm
</span>-rw-r--r--  1 1000 1000 206032 Feb  8 16:13 data.db-wal
</span>drwxr--r--  2 1000 1000   4096 Feb  8 16:13 log
</span>drwxr-xr-x  2 1000 1000   4096 Feb  8 16:13 temp
</span></code></pre>
这个时候, 容器内的 init 进程和非 init 进程在宿主机上均(表现为)以当前用户 “降权” 运行, 文件系统权限表现和当前用户基本一致.</p>
</li>

Capabilities</p>
关于 Capabilities, 参考 https://man7.org/linux/man-pages/man7/capabilities.7.html</a>, 暂且理解为对权限控制的细化. 无论是 Docker 还是 Podman, 都限制了容器内进程的 Capabilities, 即便是 “root”.</p>
Podman 的默认 Capabilities</a> 和 Docker 的默认 Capabilities</a> 是不同的:</p>
Capability</th> Podman</th> Docker</th></tr></thead>

CHOWN</strong></td> ✔️</td> ✔️</td></tr>
DAC_OVERRIDE</strong></td> ✔️</td> ✔️</td></tr>
FSETID</strong></td> ✔️</td> ✔️</td></tr>
FOWNER</strong></td> ✔️</td> ✔️</td></tr>
MKNOD</strong></td> ❌</td> ✔️</td></tr>
NET_RAW</strong></td> ❌</td> ✔️</td></tr>
SETGID</strong></td> ✔️</td> ✔️</td></tr>
SETUID</strong></td> ✔️</td> ✔️</td></tr>
SETFCAP</strong></td> ✔️</td> ✔️</td></tr>
SETPCAP</strong></td> ✔️</td> ✔️</td></tr>
NET_BIND_SERVICE</strong></td> ✔️</td> ✔️</td></tr>
SYS_CHROOT</strong></td> ✔️</td> ✔️</td></tr>
KILL</strong></td> ✔️</td> ✔️</td></tr>
AUDIT_WRITE</strong></td> ❌</td> ✔️</td></tr>
</tbody></table>
在容器化现有应用程序时时, 需要注意两者的差异; 对终端用户来说没有什么直接影响, 但建议启动容器时配置 --security-opt=no-new-privileges</code> 以禁止容器进程获得额外权限, 或者直接禁用所有 Capabilities (--cap-drop=all</code>) 再按需添加 (--cap-add=CAP_NAME</code>), 防止类似 CAP_BPF</code> 这些后面才引入的高危 Capabilities 被意外添加.</p>
</li>
</ol>
编写 Rootless 友好的 Dockerfile</h2>
总体和编写普通 Dockerfile 没什么区别, 但需要注意以下几点:</p>


指定 rootless USER</code>, 需要是数字 ID.</p>
推荐: USER=65532:65532</code>.</p>
</li>

尽量使用 Distroless 镜像作为基础镜像.</p>


如果应用程序是完全静态编译的, 直接使用 scratch</code> (适合现代应用程序, 没有奇奇怪怪的依赖) 或 gcr.io/distroless/static</code> (适合传统应用程序, 仍然依赖系统 CA 之类的奇怪玩意).</p>
不同语言编写的项目的静态编译方法参考:</p>


对于 C / C++, 具体项目具体分析.</p>
</li>

对于 Go, 可以配置 CGO_ENABLED=0</code>, 如果项目以及项目的依赖没有依赖 CGO 的话.</p>
</li>

对于 Rust, 可以配置 target x86_64-unknown-linux-musl</code> (amd64) 或 aarch64-unknown-linux-musl</code> (arm64) 目标平台进行静态编译.</p>
> rustup target add x86_64-unknown-linux-musl
</span># ...
</span>> cd /tmp
</span>> cargo new test-static-build
</span>    Creating binary (application) `test-static-build` package
</span>note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
</span>> cd test-static-build
</span>> cargo build --release --target x86_64-unknown-linux-musl
</span>  Compiling test-static-build v0.1.0 (/tmp/test-static-build)
</span>    Finished `release` profile [optimized] target(s) in 1.22s
</span>> ldd /data/Compile/cargo-target-dir/x86_64-unknown-linux-musl/release/test-static-build
</span>        statically linked
</span></code></pre>
一般来说, 能编译为 x86_64-unknown-linux-gnu</code> 就能编译为 x86_64-unknown-linux-musl</code>, 除非依赖到某些奇奇怪怪的 C 库.</p>
</li>

…</p>
</li>
</ol>
</li>

如果应用程序依赖于 glibc, 可以使用 gcr.io/distroless/base-nossl</code>; 如果应用程序还依赖于 OpenSSL (v3.X), 可以使用 gcr.io/distroless/base</code>.</p>
</li>
</ol>
一些问题:</p>


尝试运行容器时, 报告 “error while loading shared libraries: XXX: cannot open shared object file: No such file or directory” 错误.</p>
此即缺失依赖库问题.</p>
这种情况下, 使用 ldd 查看依赖库, 再参考相关库的安装方法直接从完整镜像复制文件即可, 如笔者在打包 Resilio Sync 时的做法:</p>
#</span> ...
</span></span>ARG </span>DEBIAN_BASE_VERSION=trixie-slim
</span>ARG </span>DEBIAN_BASE_HASH=f6e2cfac5cf956ea044b4bd75e6397b4372ad88fe00908045e9a0d21712ae3ba
</span>#</span> ...
</span></span>FROM</span> --platform=linux/${TARGETARCH} debian:${DEBIAN_BASE_VERSION}@sha256:${DEBIAN_BASE_HASH} AS downloader
</span>#</span> ...
</span></span>RUN </span>set -e && \
</span>#</span> ...
</span></span>&& \
</span>ARCH=$(dpkg --print-architecture) \
</span>&& \
</span>case "</span>${ARCH}"</span></span> in \
</span>amd64) LIBARCH="</span>x86_64-linux-gnu"</span></span> ;; \
</span>arm64) LIBARCH="</span>aarch64-linux-gnu"</span></span> ;; \
</span>*) echo "</span>Unsupported architecture: ${ARCH}"</span></span> && exit 1 ;; \
</span>esac \
</span>&& \
</span>cp /lib/${LIBARCH}/libcrypt.so.1 /tmp/resilio-sync/lib/libcrypt.so.1
</span>#</span> ...
</span></span>FROM</span> scratch
</span>#</span> ...
</span></span>ENV </span>LD_LIBRARY_PATH=/opt/resilio-sync/lib
</span>#</span> ...
</span></span></code></pre>
(笔者评: Resilio Sync 怎么还在用 OpenSSL 1.1.X 啊, 硬要用就不能静态编译进程序里面么… C / C++ 的依赖灾难在这就体现了…)</p>
</li>

OpenSSL CA 问题.</p>
但凡最终应用程序报告 SSL 相关错误, 大抵是这里所述的问题.</p>
这种情况下, 可以在构建阶段安装 ca-certificates 包, 将 CA 文件复制到最终镜像中, 并正确配置环境变量, 如笔者在打包 qBittorrent 时的做法:</p>
#</span> ...
</span></span>ARG </span>ALPINE_BASE_VERSION=3.23.3
</span>ARG </span>ALPINE_BASE_HASH=25109184c71bdad752c8312a8623239686a9a2071e8825f20acb8f2198c3f659
</span>#</span> ...
</span></span>FROM</span> alpine:${ALPINE_BASE_VERSION}@sha256:${ALPINE_BASE_HASH}</span> AS</span> downloader</span>
</span>#</span> ...
</span></span>RUN </span>set -e && \
</span>    apk -U upgrade && apk add --no-cache \
</span>    ca-certificates=20251003-r0 \
</span>#</span> ...
</span></span>FROM scratch
</span>#</span> ...
</span></span>COPY</span> --from=downloader</span> /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt
</span>#</span> ...
</span></span>ENV </span>SSL_CERT_DIR=/etc/ssl/certs \
</span>    SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt
</span>#</span> ...
</span></span></code></pre>
(笔者评: 还是喜欢 Rustls + WebPKI, OpenSSL 这种岁月痕迹过于重的库, 唉…)</p>
</li>
</ol>
</li>
</ol>
使用 systemd 管理 Rootless Podman 容器</h2>
参考文档: https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html</a></p>
Podman 不像 Docker 那样有守护程序, 需要以其他方式管理容器的自动启动等. Podman 提供了 Quadlet, 以通过 systemd 来管理 Podman 容器.</p>
下面是一个示例 Quadlet 文件:</p>
[Unit]
</span>Description=FreeNGINX Distroless Container Service
</span>RequiresMountsFor=%t/containers
</span>
</span>[Container]
</span># * Specify the name of the container.
</span>ContainerName=freenginx
</span># * Specify the container image to use.
</span>Image=ghcr.io/han-rs/container-ci-freenginx:latest
</span># * Automatically pull the latest image.
</span>AutoUpdate=registry
</span># * Run the container in user namespace mode with the current user's ID.
</span># *
</span># * Don't modify this field unless you know what you're doing.
</span>UserNS=keep-id:uid=65532,gid=65532
</span># * Use the host's network stack for better performance.
</span>Network=host
</span># * Publish ports from the container to the host.
</span># *
</span># * If Network=host is used, these options will be ignored.
</span># * The format is [host_ip:]host_port:container_port[/protocol].
</span># * Please set these according to what you configured.
</span># PublishPort=80:80
</span># PublishPort=443:443
</span># PublishPort=443:443/udp
</span># * Persists configuration files.
</span>Volume=%h/.local/share/freenginx/conf:/opt/freenginx/conf
</span># * Persists logs.
</span>Volume=%h/.local/share/freenginx/logs:/opt/freenginx/logs
</span># * Persists SSL stuffs.
</span>Volume=%h/.local/share/freenginx/ssl:/opt/freenginx/ssl
</span># * Example of mounting a named volume.
</span># Volume=cloudflared.volume:/opt/cloudflared/shared-volume
</span># * Example of mounting a host directory.
</span># Volume=/host/dir:/container/dir
</span>
</span>[Service]
</span># * Always restart the container if it stops.
</span>Restart=always
</span># * Give the container more time to start.
</span>TimeoutStartSec=900
</span># * Generate configuration extracting real IP from HTTP headers added by Cloudflare.
</span>#
</span># * If you gate your servers behind Cloudflare, uncomment the following line.
</span># ExecStartPre=%h/.local/share/freenginx/scripts/cloudflare-real-ip-helper.sh
</span># * For Podman v5.4 or lower, we have to manually specify reload command.
</span>ExecReload=/usr/bin/podman exec freenginx /opt/freenginx/sbin/nginx -s reload
</span>
</span>[Install]
</span># * Enable the service to start at boot.
</span>WantedBy=default.target
</span></code></pre>
基本上, Podman Quadlet systemd 文件可以由 podman run</code> 命令逐参数转换而来, 官方文档也给出了对照表</a>, 编写并不困难.</p>
上面的例子基本上相当于:</p>
podman</span></span> run -</span>d</span> --</span>restart</span>=</span>unless-stopped \
</span></span></span>    --</span>restart</span>=</span>always \
</span></span></span>    --</span>userns</span>=</span>keep-id:uid=65532,gid=65532 \
</span></span></span>    --</span>network</span>=</span>host \
</span></span></span>    -</span>v</span> ~</span></span>/.local/share/freenginx/conf:/opt/freenginx/conf \
</span></span></span>    -</span>v</span> ~</span></span>/.local/share/freenginx/logs:/opt/freenginx/logs \
</span></span></span>    -</span>v</span> ~</span></span>/.local/share/freenginx/ssl:/opt/freenginx/ssl \
</span></span></span>    --</span>name</span>=</span>"</span>freenginx"</span></span> \
</span></span></span>    --</span>replace</span> \
</span></span></span>    ghcr.io/han-rs/container-ci-freenginx:latest</span>
</span></code></pre>
配置完成后, 可以通过 systemctl --user ${CMD} ${CONTAINER_NAME}.service</code> 来管理该容器, 如:</p>
> systemctl --user status freenginx.service
</span>● freenginx.service - FreeNGINX Distroless Container Service
</span>     Loaded: loaded (/home/hantong/.config/containers/systemd/freenginx.container; generated)
</span>     Active: active (running) since Sat 2026-02-07 19:29:12 CST; 21h ago
</span> Invocation: eda008ef44dc4e79b198a0c69a7ca32f
</span>    Process: 25667 ExecStartPre=/home/hantong/.local/share/freenginx/scripts/cloudflare-real-ip-helper.sh (code=exited, status=0/SUCCESS)
</span>   Main PID: 25696 (conmon)
</span>      Tasks: 134 (limit: 4915)
</span>     Memory: 467M (peak: 3.6G)
</span>        CPU: 16min 28.154s
</span># ...
</span></code></pre>
值得指出, 依托于 systemd, 像什么 ExecStartPre</code> 之类的钩子也可以使用了, 不再依赖容器本身去实现这些功能, 这允许容器打包者大幅度简化镜像:</p>
> podman images
</span>REPOSITORY                                TAG         IMAGE ID      CREATED       SIZE
</span>ghcr.io/han-rs/container-ci-freenginx     latest      f583dc3c0362  28 hours ago  3.95 MB
</span>ghcr.io/han-rs/container-ci-resilio-sync  latest      af6cae8d5f91  47 hours ago  38.3 MB
</span>ghcr.io/han-rs/container-ci-qbittorrent   latest      2bf49e5c41e5  2 days ago    45.5 MB
</span>ghcr.io/han-rs/container-ci-cloudflared   latest      a4bbf0388c6b  2 days ago    28 MB
</span># ...
</span></code></pre>
当然, 还有些注意事项和疑难杂症:</p>


自动启动</p>

需要执行 sudo loginctl enable-linger $USER</code>, 使得 rootless 用户的 systemd 服务能够在用户未登录时也能自动启动并驻留后台.</li>
不需要执行 systemctl --user enable ***</code>, Podman 创建的服务被 systemd 视为 “瞬态” (transient) 的.</li>
需要在 Quadlet 配置文件 [Install]</code> 项添加 WantedBy=default.target</code> 使容器自动启动. (存疑</strong>: 是 default.target</code> 还是 multi-user.target</code>, 还是两者均使用? 笔者个人部署时仅使用前者.)</li>
</ol>
</li>

笔者本人在部署过程中遇到 network-online.target</code> 始终没有 active (systemctl is-active network-online.target</code> 提示 inactive) 的问题, 导致:</p>

容器自动启动会延滞于服务器启动完成很久之后;</li>
启动或重启服务等待很久 (默认 90s 超时), 但能成功;</li>
…</li>
</ol>
根本原因暂未清楚, 或许是 netplan</code> + systemd-networkd</code> 的问题? 等待进一步研究.</del></p>
参考 https://github.com/containers/podman/issues/24796#issuecomment-2527822425</a>, 给出暂时性的解决方案:</p>
sudo sh -c "cat <<EOF > /etc/systemd/system/podman-network-online-dummy.service
</span>[Unit]
</span>Description=This service simply activates network-online.target
</span>After=network-online.target
</span>Wants=network-online.target
</span>
</span>[Service]
</span>ExecStart=/usr/bin/echo Activating network-online.target
</span>
</span>[Install]
</span>WantedBy=multi-user.target
</span>EOF"
</span>sudo systemctl daemon-reload
</span>sudo systemctl enable --now podman-network-online-dummy.service
</span># Check status
</span># sudo systemctl status podman-network-online-dummy.service
</span></code></pre>
</li>
</ol>
其他需要注意的是, 从 Podman v5 开始, podman generate systemd</code> 已经被弃用, 不再推荐使用.</p>
结语</h2>
总的来说, 如果不想折腾, 直接使用 rootful Docker 确实方便, root 解决一切权限问题, 但面对 “飞牛变肥牛”</a> 之类由于厂商漠视安全、产品存在大量安全漏洞不积极修复放任被在野攻击者利用的教训, 对于闭源应用或未得到广泛安全审计的开源应用, 还是建议使用 Rootless Podman 容器化隔离, 并配置 CPU 和内存用量限制; 即便是开源应用, 也建议使用 Rootless Podman 来隔离部署, 以防止由于配置错误或未知漏洞导致的安全问题.</p>
本文是笔者近日在个人存储服务器使用 Rootless Podman 隔离部署应用程序, 尤其是闭源应用程序的过程中总结的经验 (踩坑体验), 分享在此供读者参考, 相关成果开源在以下仓库中:</p>

container-ci-freenginx</a></li>
container-ci-qbittorrent</a></li>
container-ci-cloudflared</a></li>
container-ci-resilio-sync</a></li>
</ol>
由于笔者水平和精力有限, 文章中难免出现纰漏, 欢迎评论区批评指正、交流分享.</p>
参考文献</h2>


官方文档, 包括但不限于:</p>

官方指引: https://github.com/containers/podman/blob/main/docs/tutorials/rootless_tutorial.md</a></li>
官方常见问题总结: https://github.com/containers/podman/blob/main/rootless.md</a></li>
用户命名空间模式: https://docs.podman.io/en/latest/markdown/podman-run.1.html#userns-mode</a></li>
</ol>
</li>

How does rootless Podman work?</a></p>
</li>

探索 Linux Namespace: Docker 隔离的神奇背后</a></p>
</li>
</ol>


了解和使用 GPG
2026-02-01T00:00:00+00:00
前言</h2>
本文出现的所有命令的示例均在 Debian 13 上操作 GPG (GnuPG</a>) 2.4.7 版本完成. 本文参考、借鉴、总结了大量资料, 在文末给出相关链接, 在此先表达感谢.</p>
基本概念与术语</h2>
密码学基础</h3>
建议阅读 『从零开始了解 TLS 1.3 系列笔记 (六) —— 实用密码学之「对称加密、AEAD 与非对称密码学」』</a> 中的非对称密码学 (公钥密码学) 部分, 『从零开始了解 TLS 1.3 系列笔记 (五) —— 实用密码学之「密钥交换, Diffie–Hellman 与后量子加密」』</a> 中的后量子密码学部分, 此处不再赘述.</p>
应当了解:</p>

非对称密码学 (公钥密码学) 的基本概念;</li>
RSA 和 ECC 公钥密码系统的基本概念, ECC 公钥密码系统中如 Curve25519 和 X25519 以及 Ed25519 的关系;</li>
RSA 和 ECC 公钥密码系统的作用, 如数字签名等;</li>
常见的 EdDSA, 如基于 Curve25519 的 Ed25519, 基于 Curve448 的 Ed448;</li>
常见的 ECDSA, 如 NIST P-256 (secp256r1);</li>
ECDSA 和 EdDSA 的区别.</li>
</ol>
GPG</h3>
GPG (GnuPG</a>, GNU Privacy Guard) 是一款自由和开源软件 (FOSS), 通过对各类密码学原语的封装, 遵照 OpenPGP</a> 标准, 实现了加密 (E</strong>crypt)、签名 (S</strong>ign) 和认证 (A</strong>uthenticating) 功能, 以及密钥管理功能 (C</strong>ertify). PGP 早期为一具备类似功能的闭源专有程序1</a></sup>, 虽然如今称呼 PGP 等价于称呼 OpenPGP 了.</p>
GPG 生成并管理以下几种公私钥对:</p>


主密钥对</p>
包含主私钥 (sec) 和主公钥 (pub).</p>
虽然可以让主密钥对提供上述全部功能, 但一般不推荐那么做. 相反, 我们推荐仅授予主密钥对以密钥管理功能, 完成密钥准备工作后即离线保存主私钥, 仅在需要时加载, 包括但不限于:</p>

添加或吊销子密钥;</li>
添加、更改或吊销密钥关联身份 (UID);</li>
添加或更改本身或其他子密钥的到期时间;</li>
为了网络信任目的为其他密钥签名, 等.</li>
</ol>
后文我们再继续介绍.</p>
</li>

子密钥对</p>
包含子私钥 (ssb) 和子公钥 (sub), 按前述用途可细分为 ssb S / A / E, sub S / A / E.</p>
我们推荐为不同用途分别生成子密钥对.</p>
</li>
</ol>
以下称 “主/子密钥” 时, 均指公钥和私钥的组合, 即密钥对.</p>
安装 GPG</h2>
不再赘述, 现代 Linux 发行版一般默认安装, Windows 系统下可以安装 Kleopatra</a>, 会捎带着安装命令行版本的 GPG. 下面的示例均使用命令行操作.</p>
准备 GPG 密钥</h2>
生成主密钥</h3>
执行 gpg --full-gen-key --expert</code> 进行交互式生成.</p>
选择密钥类型</h4>
出于性能原因, 我们推荐选择 ECC 密钥类型, 除非需要兼容老设备等才选择 RSA. 虽然, ECC 和 RSA 一样并不具备后量子安全性, 但后量子安全的算法目前尚未成熟, OpenPGP 尚未跟进相关进展.</p>
由于我们希望主密钥专用于管理子密钥, 即执行 Certify 的功能, 我们选择 “(11) ECC (set your own capabilities)”, 然后手动设置主密钥功能 (初始时自带 Sign</code> 和 Certify</code> 的功能, 输入 S</code> 关闭签名功能即可, 然后按 Q</code> 保存).</p>
Please select what kind of key you want:
</span>   (1) RSA and RSA
</span>   (2) DSA and Elgamal
</span>   (3) DSA (sign only)
</span>   (4) RSA (sign only)
</span>   (7) DSA (set your own capabilities)
</span>   (8) RSA (set your own capabilities)
</span>   (9) ECC (sign and encrypt) *default*
</span>  (10) ECC (sign only)
</span>  (11) ECC (set your own capabilities)
</span>  (13) Existing key
</span>  (14) Existing key from card
</span>Your selection? 11
</span>
</span>Possible actions for this ECC key: Sign Certify Authenticate
</span>Current allowed actions: Sign Certify
</span>
</span>   (S) Toggle the sign capability
</span>   (A) Toggle the authenticate capability
</span>   (Q) Finished
</span>
</span>Your selection? S
</span>
</span>Possible actions for this ECC key: Sign Certify Authenticate
</span>Current allowed actions: Certify
</span>
</span>   (S) Toggle the sign capability
</span>   (A) Toggle the authenticate capability
</span>   (Q) Finished
</span>
</span>Your selection? Q
</span></code></pre>
选择 ECC 曲线</h4>
出于兼容性原因, 我们选择 Curve25519 而不是 Curve448; 出于安全考虑2</a></sup>, 不推荐 NIST 系列曲线、Brainpool 系列曲线或 secp256k1.</p>
Please select which elliptic curve you want:
</span>   (1) Curve 25519 *default*
</span>   (2) Curve 448
</span>   (3) NIST P-256
</span>   (4) NIST P-384
</span>   (5) NIST P-521
</span>   (6) Brainpool P-256
</span>   (7) Brainpool P-384
</span>   (8) Brainpool P-512
</span>   (9) secp256k1
</span>Your selection? 1
</span></code></pre>
配置有效期</h4>
出于安全考虑, 不建议配置密钥永不过期. 此处我们设置为 4 年.</p>
Please specify how long the key should be valid.
</span>         0 = key does not expire
</span>      <n>  = key expires in n days
</span>      <n>w = key expires in n weeks
</span>      <n>m = key expires in n months
</span>      <n>y = key expires in n years
</span>Key is valid for? (0) 4y
</span>Key expires at Fri Feb  1 15:45:55 2030 CST
</span>Is this correct? (y/N) y
</span></code></pre>
配置 UID</h4>
用户 ID 用于将密钥和真人关联, 同一个主密钥下可以有多个 UID 适应多个身份.</p>
GnuPG needs to construct a user ID to identify your key.
</span>
</span>Real name: Hantong Chen
</span>Email address: public-service@7rs.net
</span>Comment: 2026
</span>You selected this USER-ID:
</span>    "Hantong Chen (2026) <public-service@7rs.net>"
</span>
</span>Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
</span></code></pre>
额外说一句, 大部分情况下别真填自己的真名上去; 此外邮箱至少应该能够收邮件, 后面会用到; 公钥会包含电子邮件地址, 注意隐私和垃圾邮件问题.</p>
配置密码保护</h4>
输入密码, 按 Tab 移动到下一项, 再次输入密码, 按 Tab 移动到 <OK></code> 确认.</p>
┌─────────────────────────────────────────────────────────────┐
</span>│ Please enter the passphrase to                              │
</span>│ protect your new key                                        │
</span>│                                                             │
</span>│ Passphrases match.                                          │
</span>│                                                             │
</span>│ Passphrase: _______________________________________________ │
</span>│                                                             │
</span>│ Repeat: ___________________________________________________ │
</span>│ ┌─────────────────────────────────────────────────────────┐ │
</span>│ │                                                         │ │
</span>│ └─────────────────────────────────────────────────────────┘ │
</span>│        <OK>                                   <Cancel>      │
</span>└─────────────────────────────────────────────────────────────┘
</span></code></pre>
注意不要超时, 输入完毕后等待完成即可:</p>
We need to generate a lot of random bytes. It is a good idea to perform
</span>some other action (type on the keyboard, move the mouse, utilize the
</span>disks) during the prime generation; this gives the random number
</span>generator a better chance to gain enough entropy.
</span>We need to generate a lot of random bytes. It is a good idea to perform
</span>some other action (type on the keyboard, move the mouse, utilize the
</span>disks) during the prime generation; this gives the random number
</span>generator a better chance to gain enough entropy.
</span></code></pre>
小结</h4>
现在, 我们的主密钥就已经生成完毕了:</p>
gpg: revocation certificate stored as '/home/hantong/.gnupg/openpgp-revocs.d/6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2.rev'
</span>public and secret key created and signed.
</span>
</span>pub   ed25519 2026-02-02 [C] [expires: 2030-02-01]
</span>      6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2
</span>uid                      Hantong Chen (2026) <public-service@7rs.net>
</span></code></pre>
请务必牢记密码, 后面所有用到私钥的地方都会要求输入密码.</p>
可以使用 gpg --list-keys --keyid-format long</code> 和 gpg --list-secret-keys --keyid-format long</code> 列出所有公钥和私钥:</p>
> gpg --list-keys --keyid-format long
</span># 略去部分输出
</span>pub   ed25519/F95DD10B4BFF68A2 2026-02-02 [C] [expires: 2030-02-01]
</span>      6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2
</span>uid                 [ultimate] Hantong Chen (2026) <public-service@7rs.net>
</span></code></pre>
> gpg --list-secret-keys --keyid-format long
</span># 略去部分输出
</span>sec   ed25519/F95DD10B4BFF68A2 2026-02-02 [C] [expires: 2030-02-01]
</span>      6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2
</span>uid                 [ultimate] Hantong Chen (2026) <public-service@7rs.net>
</span></code></pre>
可以看到:</p>

长 ID: 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2</code></li>
短 ID: F95DD10B4BFF68A2</code></li>
主密钥用途: “[C]”</li>
主密钥创建日期: “2026-02-02”</li>
主密钥有效期止: “2030-02-01”</li>
UID: 信任状态 (完全信任, “ultimate”), Real Name (“Hantong Chen”), 备注 (“2026”) 和电子邮件 (“public-service#7rs.net”)</li>
</ol>
生成子密钥</h3>
PKI 体系有证书信任链的存在, GPG 的子密钥机制 (subkey) 承担了类似功能, 即仅当配置了信任主公钥, 才信任主密钥下的子密钥; 吊销主密钥则全部子密钥失去信任; 吊销单个子密钥不影响其他子密钥或主密钥.</p>
我们建议并在前述步骤中配置主密钥仅承担签发的功能, 接下来需要添加子密钥分别承担签名/认证/加密的功能.</p>
使用 gpg --expert --edit-key <key-id></code> 进入编辑模式, 下面是示例操作过程:</p>
> gpg --expert --edit-key 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2
</span>gpg (GnuPG) 2.4.7; Copyright (C) 2024 g10 Code GmbH
</span>This is free software: you are free to change and redistribute it.
</span>There is NO WARRANTY, to the extent permitted by law.
</span>
</span>Secret key is available.
</span>
</span>sec  ed25519/F95DD10B4BFF68A2
</span>     created: 2026-02-02  expires: 2030-02-01  usage: C
</span>     trust: ultimate      validity: ultimate
</span>[ultimate] (1). Hantong Chen (2026) <public-service@7rs.net>
</span>
</span>gpg> addkey
</span>Please select what kind of key you want:
</span>   (3) DSA (sign only)
</span>   (4) RSA (sign only)
</span>   (5) Elgamal (encrypt only)
</span>   (6) RSA (encrypt only)
</span>   (7) DSA (set your own capabilities)
</span>   (8) RSA (set your own capabilities)
</span>  (10) ECC (sign only)
</span>  (11) ECC (set your own capabilities)
</span>  (12) ECC (encrypt only)
</span>  (13) Existing key
</span>  (14) Existing key from card
</span>Your selection? 10
</span>Please select which elliptic curve you want:
</span>   (1) Curve 25519 *default*
</span>   (2) Curve 448
</span>   (3) NIST P-256
</span>   (4) NIST P-384
</span>   (5) NIST P-521
</span>   (6) Brainpool P-256
</span>   (7) Brainpool P-384
</span>   (8) Brainpool P-512
</span>   (9) secp256k1
</span>Your selection? 1
</span>Please specify how long the key should be valid.
</span>         0 = key does not expire
</span>      <n>  = key expires in n days
</span>      <n>w = key expires in n weeks
</span>      <n>m = key expires in n months
</span>      <n>y = key expires in n years
</span>Key is valid for? (0) 4y
</span>Key expires at Fri Feb  1 16:22:25 2030 CST
</span>Is this correct? (y/N) y
</span>Really create? (y/N) y
</span>We need to generate a lot of random bytes. It is a good idea to perform
</span>some other action (type on the keyboard, move the mouse, utilize the
</span>disks) during the prime generation; this gives the random number
</span>generator a better chance to gain enough entropy.
</span>
</span>sec  ed25519/F95DD10B4BFF68A2
</span>     created: 2026-02-02  expires: 2030-02-01  usage: C
</span>     trust: ultimate      validity: ultimate
</span>ssb  ed25519/29774A85FD26125D
</span>     created: 2026-02-02  expires: 2030-02-01  usage: S
</span>[ultimate] (1). Hantong Chen (2026) <public-service@7rs.net>
</span>
</span>gpg> addkey
</span>Please select what kind of key you want:
</span>   (3) DSA (sign only)
</span>   (4) RSA (sign only)
</span>   (5) Elgamal (encrypt only)
</span>   (6) RSA (encrypt only)
</span>   (7) DSA (set your own capabilities)
</span>   (8) RSA (set your own capabilities)
</span>  (10) ECC (sign only)
</span>  (11) ECC (set your own capabilities)
</span>  (12) ECC (encrypt only)
</span>  (13) Existing key
</span>  (14) Existing key from card
</span>Your selection? 11
</span>
</span>Possible actions for this ECC key: Sign Authenticate
</span>Current allowed actions: Sign
</span>
</span>   (S) Toggle the sign capability
</span>   (A) Toggle the authenticate capability
</span>   (Q) Finished
</span>
</span>Your selection? S
</span>
</span>Possible actions for this ECC key: Sign Authenticate
</span>Current allowed actions:
</span>
</span>   (S) Toggle the sign capability
</span>   (A) Toggle the authenticate capability
</span>   (Q) Finished
</span>
</span>Your selection? A
</span>
</span>Possible actions for this ECC key: Sign Authenticate
</span>Current allowed actions: Authenticate
</span>
</span>   (S) Toggle the sign capability
</span>   (A) Toggle the authenticate capability
</span>   (Q) Finished
</span>
</span>Your selection? Q
</span>Please select which elliptic curve you want:
</span>   (1) Curve 25519 *default*
</span>   (2) Curve 448
</span>   (3) NIST P-256
</span>   (4) NIST P-384
</span>   (5) NIST P-521
</span>   (6) Brainpool P-256
</span>   (7) Brainpool P-384
</span>   (8) Brainpool P-512
</span>   (9) secp256k1
</span>Your selection? `1
</span>Invalid selection.
</span>Your selection? 1
</span>Please specify how long the key should be valid.
</span>         0 = key does not expire
</span>      <n>  = key expires in n days
</span>      <n>w = key expires in n weeks
</span>      <n>m = key expires in n months
</span>      <n>y = key expires in n years
</span>Key is valid for? (0) 4y
</span>Key expires at Fri Feb  1 16:23:08 2030 CST
</span>Is this correct? (y/N) y
</span>Really create? (y/N) y
</span>We need to generate a lot of random bytes. It is a good idea to perform
</span>some other action (type on the keyboard, move the mouse, utilize the
</span>disks) during the prime generation; this gives the random number
</span>generator a better chance to gain enough entropy.
</span>
</span>sec  ed25519/F95DD10B4BFF68A2
</span>     created: 2026-02-02  expires: 2030-02-01  usage: C
</span>     trust: ultimate      validity: ultimate
</span>ssb  ed25519/29774A85FD26125D
</span>     created: 2026-02-02  expires: 2030-02-01  usage: S
</span>ssb  ed25519/11E7B3A29E772EB3
</span>     created: 2026-02-02  expires: 2030-02-01  usage: A
</span>[ultimate] (1). Hantong Chen (2026) <public-service@7rs.net>
</span>
</span>gpg> addkey
</span>Please select what kind of key you want:
</span>   (3) DSA (sign only)
</span>   (4) RSA (sign only)
</span>   (5) Elgamal (encrypt only)
</span>   (6) RSA (encrypt only)
</span>   (7) DSA (set your own capabilities)
</span>   (8) RSA (set your own capabilities)
</span>  (10) ECC (sign only)
</span>  (11) ECC (set your own capabilities)
</span>  (12) ECC (encrypt only)
</span>  (13) Existing key
</span>  (14) Existing key from card
</span>Your selection? 12
</span>Please select which elliptic curve you want:
</span>   (1) Curve 25519 *default*
</span>   (2) Curve 448
</span>   (3) NIST P-256
</span>   (4) NIST P-384
</span>   (5) NIST P-521
</span>   (6) Brainpool P-256
</span>   (7) Brainpool P-384
</span>   (8) Brainpool P-512
</span>   (9) secp256k1
</span>Your selection? 1
</span>Please specify how long the key should be valid.
</span>         0 = key does not expire
</span>      <n>  = key expires in n days
</span>      <n>w = key expires in n weeks
</span>      <n>m = key expires in n months
</span>      <n>y = key expires in n years
</span>Key is valid for? (0) 4y
</span>Key expires at Fri Feb  1 16:23:27 2030 CST
</span>Is this correct? (y/N) y
</span>Really create? (y/N) y
</span>We need to generate a lot of random bytes. It is a good idea to perform
</span>some other action (type on the keyboard, move the mouse, utilize the
</span>disks) during the prime generation; this gives the random number
</span>generator a better chance to gain enough entropy.
</span>
</span>sec  ed25519/F95DD10B4BFF68A2
</span>     created: 2026-02-02  expires: 2030-02-01  usage: C
</span>     trust: ultimate      validity: ultimate
</span>ssb  ed25519/29774A85FD26125D
</span>     created: 2026-02-02  expires: 2030-02-01  usage: S
</span>ssb  ed25519/11E7B3A29E772EB3
</span>     created: 2026-02-02  expires: 2030-02-01  usage: A
</span>ssb  cv25519/AE4E4336187491D9
</span>     created: 2026-02-02  expires: 2030-02-01  usage: E
</span>[ultimate] (1). Hantong Chen (2026) <public-service@7rs.net>
</span>
</span>gpg> save
</span></code></pre>
常用的命令:</p>


addkey</code>: 添加子密钥</p>
gpg> addkey
</span>Please select what kind of key you want:
</span>   (3) DSA (sign only)
</span>   (4) RSA (sign only)
</span>   (5) Elgamal (encrypt only)
</span>   (6) RSA (encrypt only)
</span>   (7) DSA (set your own capabilities)
</span>   (8) RSA (set your own capabilities)
</span>  (10) ECC (sign only)
</span>  (11) ECC (set your own capabilities)
</span>  (12) ECC (encrypt only)
</span>  (13) Existing key
</span>  (14) Existing key from card
</span>Your selection?
</span></code></pre>
子密钥的密钥类型并不要求和主密钥一致, 不过我们沿用 ECC.</p>
对于签名 (S</code>) 用途, 我们选择 ECC (sign only)</code>; 对于认证 (A</code>) 用途, 我们选择 ECC (set your own capabilities)</code>; 对于加密 (E</code>) 用途, 我们选择 ECC (encrypt only)</code>. 接下来的选择 ECC 曲线和配置密钥有效期和配置主密钥时的步骤一致.</p>
特别地, 认证 (A</code>) 用途选择 ECC (set your own capabilities)</code> 时, 类似配置主密钥的密钥用途那样, 一开始会让我们手动选择密钥用途:</p>
Possible actions for this ECC key: Sign Authenticate
</span>Current allowed actions: Sign
</span>
</span>   (S) Toggle the sign capability
</span>   (A) Toggle the authenticate capability
</span>   (Q) Finished
</span>
</span>Your selection?
</span></code></pre>
这里默认情况下是签名用途的, 我们输入 A</code> 添加认证用途, 再输入 S</code> 去掉签名用途, 最后输入 Q</code> 完成用途设置.</p>
</li>

key <key-id></code>: 选中 <key-id></code> 指示的密钥.</p>
选中时, 密钥前会带有 *</code> 号; 再次输入相同 ID 即为取消选中.</p>
</li>

delkey</code>: 删除子密钥</p>
需要提前选中子密钥.</p>
</li>

expire</code>: 更改密钥有效期.</p>
需要提前选中子密钥, 否则默认修改主密钥的有效期.</p>
</li>

save</code>: 保存并退出编辑模式.</p>
千万别忘记执行此命令, 否则前面的操作都白做了.</p>
</li>
</ol>
导出主密钥吊销证书</h3>
前面生成主密钥时, 还生成了一个吊销证书:</p>
gpg: revocation certificate stored as '/home/hantong/.gnupg/openpgp-revocs.d/6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2.rev'
</span></code></pre>
吊销证书是需要吊销主密钥但丢失主私钥时的兜底手段, 需要妥善保存.</p>
导出公钥</h3>
执行 gpg --output <pub-key-file> --armor --export <key-id></code> 导出公钥, 例如:</p>
> gpg --output 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2.pub --armor --export 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2
</span></code></pre>
此即将 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2</code> 指示的 GPG 密钥的公钥以 ASCII 装甲格式 (--armor</code>, 或者说 PEM 格式, 人类可读) 导出于当前文件夹的 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2.pub</code> 文件中.</p>
GPG 导出的公钥包含主公钥和全部的子公钥</strong>, 以及有效期、子密钥吊销信息、UID 等必要信息, 并使用主私钥签名防止被篡改.</p>
导出私钥</h3>
执行 gpg --output <key-file> --armor --export-secret-keys <key-id>!</code> 导出主私钥, 例如:</p>
> gpg --output 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2.primary.key --armor --export-secret-keys 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2!
</span></code></pre>
此即将 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2</code> 指示的 GPG 密钥的主私钥</strong>以 ASCII 装甲格式导出于当前文件夹的 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2.primary.key</code> 文件中. 注意, 这里的 !</code> 是必须的.</p>
执行 gpg --output <key-file> --armor --export-secret-subkeys <key-id></code> 导出子私钥, 例如:</p>
> gpg --output 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2.sub.key --armor --export-secret-subkeys 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2
</span></code></pre>
此即将 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2</code> 指示的 GPG 密钥的全部子私钥</strong>以 ASCII 装甲格式导出于当前文件夹的 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2.sub.key</code> 文件中.</p>
随后离线保存主私钥, 以及备份子私钥, 以转移至其他机器上使用.</p>
删除本机密钥</h3>
在导出密钥后, 我们执行 gpg --delete-secret-keys <key-id></code> 执行交互式删除私钥, 如:</p>
> gpg --delete-secret-keys 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2
</span></code></pre>
如果需要在当前机器上使用子密钥, 则只需要删除主私钥, 提示删除子私钥时取消即可. 操作完成后如果你尝试列出私钥, 会发现主私钥已经被移除了 (提示 sec#</code>), 仅剩子私钥, 如:</p>
> gpg --list-secret-keys --keyid-format long
</span># 略去部分输出
</span>sec#  ed25519/F95DD10B4BFF68A2 2026-02-02 [C] [expires: 2030-02-01]
</span>      6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2
</span>uid                 [ultimate] Hantong Chen (2026) <public-service@7rs.net>
</span>ssb   ed25519/29774A85FD26125D 2026-02-02 [S] [expires: 2030-02-01]
</span>ssb   ed25519/11E7B3A29E772EB3 2026-02-02 [A] [expires: 2030-02-01]
</span>ssb   cv25519/AE4E4336187491D9 2026-02-02 [E] [expires: 2030-02-01]
</span></code></pre>
如果打算在当前机器上彻底删除, 则一路确认删除主私钥和子私钥后, 执行 gpg --delete-keys <key-id></code> 删除公钥, 如:</p>
> gpg --delete-keys 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2
</span></code></pre>
小结</h3>
到这里, 我们已经完成了 GPG 密钥生成的全部操作, 没有特殊情况, 可以直接移步应用章节了.</p>
公布 GPG 公钥</h2>
虽然 GPG 采用点对点的信任体系, 没有 PKI 那样的中心化信任机构, 但为了便利起见, 我们仍然可以将公钥上传到公钥服务器 (Key Server), 以便对等方方便获取和信任该公钥.</p>
需要注意, 上传公钥到公钥服务器存在风险</strong>. 首先, 这是不可逆的操作, 一旦上传, 即使后续吊销该密钥, 该密钥仍然可以被下载和使用; 此外, 公钥服务器一般不会删除已经上传的公钥, 即使该公钥已经吊销. 更详细的风险说明参阅 『2021 年，用更现代的方法使用PGP（下） - 安全风险和争议， 被玩坏的KeyServer』</a>. 除非你非常确定需要上传公钥, 否则不建议上传公钥到公钥服务器.</p>
上传公钥到公钥服务器的命令如下:</p>
> gpg --keyserver hkps://keys.openpgp.org --send-keys 6D5497B80A0F26FDCED00EFCF95DD10B4BFF68A2
</span></code></pre>
吊销 GPG 密钥</h2>
如果一个主/子密钥或者 UID 不再使用了, 将其删除是没有意义的, 因为我们已经将公钥分发给了对等方, 他们仍然会信任该密钥; 此外, 如果私钥泄露, 删除密钥并不能阻止他人继续使用该密钥. 为此, 我们需要吊销该密钥或 UID, 以告知对等方该密钥或 UID 不再可信, 方式包括:</p>


使用前面导出的吊销证书文件吊销主密钥:</p>
gpg</span></span> --</span>import</span> <</span>path-to-revocation-certificate-file></span>
</span></span></code></pre>
</li>

使用主私钥吊销密钥:</p>
gpg</span></span> --</span>edit-key</span> <</span>key-id></span>
</span></span></code></pre>
在交互式界面中按前面所述选中需要吊销的子密钥, 输入 revkey</code> 吊销; 不选中任何子密钥时即吊销主密钥.</p>
</li>
</ol>
完成吊销后, 重新导出公钥并分发给对等方即可宣告吊销状态; 如果上传了公钥到公钥服务器, 也需要重新上传吊销后的公钥. 密钥吊销是不可逆的操作, 请谨慎执行.</p>
GPG 应用</h2>
下文示例仍然使用前面生成的 GPG 密钥, 信息再次指出如下:</p>

签名用途子密钥 ID: 29774A85FD26125D</code></li>
认证用途子密钥 ID: 11E7B3A29E772EB3</code></li>
加密用途子密钥 ID: AE4E4336187491D9</code></li>
</ol>
Git commit 签名</h3>
下面是一个简单例子说明如何使用 GPG 签名 Git commit.</p>
> export GPG_TTY=$(tty)
</span>> cd /tmp
</span>> git init ./test-gpg
</span>> cd test-gpg
</span>> echo "Hello, GPG!" > README.md
</span>> git add *
</span>> git commit -S29774A85FD26125D -m "Initial commit with GPG signature"
</span></code></pre>
输入 GPG 密钥密码后, 即可完成签名提交:</p>
> git log --show-signature
</span>commit 745048eeb6e87f27d5e5a8aa1f6e33f3543b8942 (HEAD -> main)
</span>gpg: Signature made Mon Feb  2 17:09:22 2026 CST
</span>gpg:                using EDDSA key 652C18ED73F115A6F9369B9029774A85FD26125D
</span>gpg: Good signature from "Hantong Chen (2026) <public-service@7rs.net>" [ultimate]
</span>Author: Hantong Chen <public-service@7rs.net>
</span>Date:   Mon Feb 2 17:09:22 2026 +0800
</span>
</span>    Initial commit with GPG signature
</span></code></pre>
可以修改 ~/.gitconfig</code> 配置文件, 以便每次提交时自动使用指定的 GPG 密钥签名, 如:</p>
[user]
</span></span>name</span> =</span></span> Hantong Chen
</span>email</span> =</span></span> public-</span>service@7rs</span>.</span>net
</span>signingkey</span> =</span></span> 29774A85FD26125D
</span></code></pre>
显然, 我们使用的是具备签名 (S</strong>) 用途的子密钥 ID, 后面不再赘述.</p>
Github GPG 配置</h4>
打开 Add new GPG key</a> 页面, 填写 Title, 将前面导出的公钥文件内容全部复制粘贴至 Key 的文本框中确认即可. 添加完毕的效果如下图所示:</p>
</p>
完成添加后, 如果邮箱还没有在 Github 上添加 (图中可见 Email address 是 Unverified 的) 就去添加一下即可, 和本文无关, 此处不赘述.</p>
一切配置正确后, 带有签名的 commit 即会显示为 Verified (此处随意截取了一个 commit, 非本文生成的 commit):</p>
</p>
可以配置 Vigilant mode</code>:</p>
</p>
上述流程可能存在时效性, 以官方文档 GitHub Docs: Adding a GPG key to your GitHub account</a> 说明的最新流程为准.</p>
Gitea / Forgejo GPG 配置</h4>
打开 https://{YOUR_GIT_SERVER_HOST}/user/settings/keys</a>, 添加 GPG 密钥:</p>
</p>
如果 GPG 密钥的电子邮件和当前用户一致电子邮件不匹配, 则会要求执行一次签名确认:</p>
> echo "[REDACTED]" | gpg -a --default-key F95DD10B4BFF68A2 --detach-sig
</span>gpg: using "F95DD10B4BFF68A2" as default secret key for signing
</span>-----BEGIN PGP SIGNATURE-----
</span>
</span>[REDACTED]
</span>-----END PGP SIGNATURE-----
</span></code></pre>
将执行结果 (“-----BEGIN PGP SIGNATURE-----</code>” 和 “-----END PGP SIGNATURE-----</code>” 之间的部分, 包括这两行) 复制粘贴至确认框中完成确认.</p>
疑难杂症</h4>


“gpg: signing failed: Inappropriate ioctl for device”</p>
出现该错误时, 一般是因为 GPG_TTY</code> 环境变量未正确设置.</p>
解决方案: 需要执行 export GPG_TTY=$(tty)</code>, 或者添加至 ~/.bashrc</code> 等 shell 配置文件中.</p>
</li>

“not a tty”</p>
使用 zsh 时, 在 VSCode 远程开发等场景中, 将 export GPG_TTY=$(tty)</code> 添加至 ~/.zshrc</code>, 可能出现 “not a tty” 错误.</p>
解决方案: 需要在 ~/.zshenv</code> 中添加而不是 ~/.zshrc</code>.</p>
</li>

其他奇奇怪怪无法弹出 GPG 密码输入窗口的问题.</p>
解决方案: 建议重新打开终端再尝试一下.</p>
</li>
</ol>
文件加解密</h3>
gpg</span></span> [</span>--</span>output <output-</span>file>]</span> --</span>encrypt</span> --</span>recipient</span> <</span>recipient-key-id></span> <</span>input-file></span>
</span></span></code></pre>
即: 使用 <recipient-key-id></code> 密钥对的公钥加密 <input-file></code> 文件, 输出加密结果至 <output-file></code>, 如果未指定 --output <output-file></code>, 默认输出至 <input-file>.gpg</code>.</p>
gpg</span></span> --</span>output</span> <</span>decrypted-file></span> -</span>-decrypt <</span>encrypted-file></span>
</span></span></code></pre>
即: 使用和加密时使用的公钥成对的私钥解密 <encrypted-file></code> 文件, 输出解密结果至 <decrypted-file></code>.</p>
一个例子:</p>
> cd /tmp
</span>> echo "Hello, GPG file encryption" > secret.test
</span>> gpg --output secret.test.gpg --encrypt --recipient AE4E4336187491D9 secret.test
</span># 提示输入密码时输入密码; 短时间内重复加密不会再提示输入密码
</span>> gpg --output secret.decrypted.test --decrypt secret.test.gpg
</span>gpg: encrypted with cv25519 key, ID AE4E4336187491D9, created 2026-02-02
</span>      "Hantong Chen (2026) <public-service@7rs.net>"
</span>> cat secret.decrypted.test
</span>Hello, GPG file encryption
</span></code></pre>
签名和验签</h3>
gpg</span></span> --</span>armor</span> [</span>-u <your-</span>key-</span>id>]</span> --</span>output</span> <</span>output-sig-file></span> -</span>-detach-sign <</span>file-to-be-signed></span>
</span></span></code></pre>
即: 使用 <your-key-id></code> 密钥对的私钥 (不提供则使用 GPG 配置的默认密钥) 签名 <file-to-be-signed></code> 文件, 生成 PEM 格式的签名 (--armor</code>, -a</code>) 并保存至 <output-sig-file></code> 而不是嵌入待签名的文件内 (--detach-sign</code>).</p>
gpg</span></span> [</span>-u <your-</span>key-</span>id>]</span> --</span>verify</span> <</span>sig-file></span> <</span>file-to-be-verified></span>
</span></span></code></pre>
即: 使用 <your-key-id></code> 密钥对的公钥 (不提供则自动匹配), 对 <file-to-be-verified></code> 文件, 读取并验证 <sig-file></code> 中的签名, 如果签名有效且文件未被篡改, 则输出 “Good signature” 信息.</p>
一个例子:</p>
> cd /tmp
</span>> echo "Hello, GPG signing" > signing.test
</span>> gpg --armor -u 29774A85FD26125D --output signing.test.sig --detach-sign signing.test
</span>> gpg --verify signing.test.sig signing.test
</span>gpg: Signature made Mon Feb  2 23:01:40 2026 CST
</span>gpg:                using EDDSA key 652C18ED73F115A6F9369B9029774A85FD26125D
</span>gpg: Good signature from "Hantong Chen (2026) <public-service@7rs.net>" [ultimate]
</span></code></pre>
这是相当常见的用途, 例如 Debian 软件包管理系统就使用 GPG 对软件包进行签名, 在早期 HTTPS 并不成熟时用以保证软件包在网络传输时不被篡改:</p>
> cat /etc/apt/sources.list.d/debian.sources
</span>Types: deb deb-src
</span>URIs: http://deb.debian.org/debian
</span>Suites: trixie trixie-updates trixie-backports
</span>Components: main contrib non-free non-free-firmware
</span>Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
</span>
</span>Types: deb deb-src
</span>URIs: http://deb.debian.org/debian-security
</span>Suites: trixie-security
</span>Components: main contrib non-free non-free-firmware
</span>Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
</span>> gpg --show-keys /usr/share/keyrings/debian-archive-keyring.gpg
</span>pub   rsa4096 2021-01-17 [SC] [expires: 2029-01-15]
</span>      1F89983E0081FDE018F3CC9673A4F27B8DD47936
</span>      Revocable by: 80E976F14A508A48E9CA3FE9BC372252CA1CF964
</span>      Revocable by: FBFABDB541B5DC955BD9BA6EDB16CF5BB12525C4
</span>      Revocable by: 8C823DED10AA8041639E12105ACE8D6E0C14A470
</span>      Revocable by: 309911BEA966D0613053045711B4E5FF15B0FD82
</span>      Revocable by: C74F6AC9E933B3067F52F33FA459EC6715B0705F
</span>uid                      Debian Archive Automatic Signing Key (11/bullseye) <ftpmaster@debian.org>
</span>sub   rsa4096 2021-01-17 [S] [expires: 2029-01-15]
</span>
</span>pub   rsa4096 2021-01-17 [SC] [expires: 2029-01-15]
</span>      AC530D520F2F3269F5E98313A48449044AAD5C5D
</span>      Revocable by: 80E976F14A508A48E9CA3FE9BC372252CA1CF964
</span>      Revocable by: FBFABDB541B5DC955BD9BA6EDB16CF5BB12525C4
</span>      Revocable by: 8C823DED10AA8041639E12105ACE8D6E0C14A470
</span>      Revocable by: 309911BEA966D0613053045711B4E5FF15B0FD82
</span>      Revocable by: C74F6AC9E933B3067F52F33FA459EC6715B0705F
</span>uid                      Debian Security Archive Automatic Signing Key (11/bullseye) <ftpmaster@debian.org>
</span>sub   rsa4096 2021-01-17 [S] [expires: 2029-01-15]
</span># 其余输出省略
</span></code></pre>
可以看到, 该公钥文件包含了多个主密钥, 每个主密钥下有一个签名用途的子密钥.</p>
(碎碎念: 本文的写作动机之一就是笔者想自行维护一个 APT 软件源, 对官方源不包含的一些较新的开源软件使用 Github Actions 执行可信自动构建并打包为 deb 包…)</p>
结语</h2>
(唉, 年纪大了, 先总结到这里, 假装有个结语吧; 后面看情况增删补改.)</p>
参考资料</h2>
本文参考了大量资料, 在此不完整列出, 以表感谢:</p>

简明 GPG 概念</a></li>
使用 GPG</a></li>
val’s Blog - GPG 使用指南</a></li>
GPG配置、命令、实例与apt-key密钥测试</a></li>
An abridged guide to using ed25519 PGP keys with GnuPG and SSH</a></li>
GPG 筆記 - 產生 ECC 金鑰及加解密檔案</a></li>
…</li>
</ol>




WikiPedia: GNU Privacy Guard</a>. ↩</a></p>
</li>

参阅 https://safecurves.cr.yp.to/</a>. ↩</a></p>
</li>
</ol>
</footer>


TLS 加密 ClientHello (Encrypted Client Hello, ECH)
2025-10-05T00:00:00+00:00
本译文材料参见 [draft-ietf-tls-esni](https://github.com/han-rs/draft-ietf-tls-esni), 手动构建为 HTML. 全文字数颇多, 难免错漏, 还请谅解, 欢迎反馈交流.


混合公钥加密 (hybrid public key encryption, HPKE) 方案
2025-10-05T00:00:00+00:00
本译文材料参见 [draft-irtf-cfrg-hpke](https://github.com/han-rs/draft-irtf-cfrg-hpke), 手动构建为 HTML. 全文字数颇多, 难免错漏, 还请谅解, 欢迎反馈交流.


从零开始了解 TLS 1.3 系列笔记 (六) —— 实用密码学之「对称加密、AEAD 与非对称密码学」
2025-09-17T00:00:00+00:00

一些密码学高频英文术语需要我们了解</p>

加密 (encrypt), 解密 (decrypt)</li>
密文 (ciphertext), 明文 (plaintext)</li>
对称加密 (symmetric encryption), 非对称加密 (asymmetric encryption)</li>
“cipher”: 一般指 “加密算法”, 但有些翻译会直译为 “密码”, 需要和 “password” 区分.</li>
</ol>
</blockquote>
密码学中, 依据加解密密钥是否相同, 可以将加密算法分为对称加密和非对称加密两大类.</p>
对称加密</h2>
对称加密, 即加密和解密使用相同的密钥. 这种加密方式的优点是加解密速度快, 适合处理大量数据. 常见的对称加密算法包括 AES 和 Chacha20 等.
其中绝大多数都是 “块密码算法 (Block Cipher)” 或者叫 “分组密码算法</strong>”, 这种算法一次只能加密固定大小的块</strong> (例如 128 位), 少部分是 “流密码算法</strong> (Stream Cipher)”, 流密码算法允许将数据逐字节地加密为密文流.
可以使用称为分组密码工作模式</em>的技术, 让分组密码算法也能做到流式加密, 我们会在后文详细了解.</p>
用于加密/解密的密钥也被称为共享密钥(需要在通信双方之间共享). 可以是 PSK, 如从密码利用 KDF 派生得到, 或编码为 Base58 / Base64 格式; 或者通过密钥交换方案协商或传输.</p>

小贴士</p>
对称加密所使用的密钥一般是 128 / 192 / 256 位的二进制数据, 直接使用不便于存储和传输, 因此通常会编码为 Base58 / Base64 格式.</p>
原始 (按 HEX 格式给出):</p>
02c324648931b89e3e8a0fc42c96e8e3be2e42812986573a40d46563bceaf75110
</span></code></pre>
Base58 编码:</p>
pbPRqYDxnKZfs8j4KKiqYmx6nzipAjTJf1oCD1WKgy99
</span></code></pre>
Base64 编码:</p>
AsMkZIkxuJ4+ig/ELJbo474uQoEphlc6QNRlY7zq91EQ
</span></code></pre>
</blockquote>
大多数现代对称密钥密码算法都是抗量子的 (quantum-resistant), 当使用长度足够的密钥时 (如 AES-256), 即便是量子计算机也无法破坏其安全性.</p>
对称加密方案</h3>
我们知道, 单纯使用加密算法只能保证数据的安全性, 并不能满足我们对消息真实性、完整性与不可否认性的需求, 因此通常我们会将对称加密算法跟其他算法组合成一个对称加密方案来使用:</p>

KDF (如果是密码作 PSK 的模式, 需要使用 KDF 从密码学强度低的密码派生出密码学强度高的伪随机密钥)</li>
分组密码工作模式 (如 CBC 或 CTR) + 消息填充算法 (如 PKCS7): 分组密码算法, 如 AES, 需要借助这两种算法, 才能加密任意大小的数据 (即所谓的数据流). 而一个流密码加密方案本身就能加密任意长度的数据, 因此不需要分组密码模式与消息填充算法.</li>
密码算法.</li>
消息认证算法: 如 HMAC, 用于验证消息的真实性、完整性、不可否认性.</li>
</ol>
如 AES-256-CTR-HMAC-SHA256 就表示一个使用 AES-256 与 Counter 分组模式 (CTR) 进行加密, 使用 HMAC-SHA256 进行消息认证的加密方案.</p>
分组密码工作模式</h3>
前面我们提到分组密码工作模式可以让分组密码算法也能加密任意长度的数据. 其中涉及一些概念值得我们了解.</p>
加密方案的名称中就带有具体的分组模式名称, 如:</p>

AES-256-GCM - AES 密码算法 + 256 位加密密钥 + Galois Counter Mode (GCM) 分组模式</li>
AES-128-CTR - AES 密码算法 + 128 位加密密钥 + Counter (CTR) 分组模式</li>
</ul>
分组密码工作模式背后的主要思想是把明文分成多个长度固定的组, 再在这些分组上重复应用分组密码算法进行加密/解密, 以实现安全地加密/解密任意长度的数据.
某些分组模式 (如 CBC) 要求将输入拆分为分组, 并使用填充算法将最末尾的分组填充到块大小, 也有些分组模式 (如 CTR、CFB、OFB、CCM、EAX 和 GCM) 不需要, 因为它们在每个步骤中, 都直接在明文部分和内部密码状态之间执行异或 (XOR) 运算.</p>
使用 “分组模式” 加密大量数据的流程基本如下:</p>

使用加密密钥 + IV (Initialization Vector, 初始向量) 初始化加密算法状态</li>
加密数据的第一个分组</li>
使用加密密钥和其他参数转换加密算法的当前状态</li>
加密下一个分组</li>
再次转换加密状态</li>
</ol>
依此类推, 直到处理完所有输入数据. 解密的流程类似.</p>
值得注意的是, 显然, 使用 CTR / GCM 分组模式时, 密文的大小与明文相同</strong>, 必要时应当进行填充 (padding) 以掩盖明文的真实长度.</p>
IV</h4>
IV 也被称作 salt 或者 nonce</strong>, 通常是一个随机数, 主要作用是往密文中添加随机性, 使同样的明文被多次加密也会产生不同的密文, 从而确保密文的不可预测性.</p>
IV 的大小应与密码块大小相同.</p>
IV 通常无需保密, 但应当足够随机 (GCM 模式下除外). 绝不允许重用 (nonce 即 number once, 一次性的数字).</p>
GCM 分组模式</h4>
GCM (Galois Counter Mode) 是一种广泛使用的分组密码工作模式, 结合了 CTR 模式的加密和 Galois 域上的消息认证</strong>. GCM 模式下的 AES 加密过程除了得到密文外, 还会得到一个认证标签</strong> (authentication tag), 一般附在密文后面.</p>
AE(AD)</h3>
AE(AD) 即 Authenticated Encryption (with Associated Data), (带关联数据的)认证加密, 我们前面已经提到过这个名词, 其包含了 “认证” 和 “加密” 两大部分.</p>

认证 (Authentication): 通常使用 HMAC, Poly1305, 或者 GCM 分组模式自带.</li>
加密 (Encryption): 使用对称加密算法, 如 AES 或 ChaCha.</li>
</ol>
正确实现了消息认证的对称加密方案, 如 AES-256-CTR-HMAC-SHA256, AES-128-GCM, AES-256-GCM 或 ChaCha20-Poly1305 等, 均可称为 AE(AD) 加密方案. 今天的大多数应用程序应该优先选用 AEAD 加密方案进行对称加密, 而不是自己造轮子, 由于密码学的复杂性, 自己造轮子往往会出错.</p>

性能小贴士: AES 和 Chacha 怎么选择?</p>

机器 CPU 支持 AES 硬件加速 (大部分现代 CPU 都支持), 使用 AES.</li>
机器 CPU 不支持 AES 硬件加速, 如 2014 年以前的 x86 架构处理器, 或者移动端相当一部分 ARM 架构处理器, 或者路由器所使用的大部分的 MIPS 架构处理器. 此时使用 ChaCha 会更快 (本来就是为移动端特别优化的).</li>
如果机器 CPU 足够现代且性能强劲, AES 和 ChaCha 差别不大, 在 HTTPS 场景下基本不可能是加密能力瓶颈, 任选其一即可.</li>
</ol>
如果想测试, 可以尝试运行:</p>
openssl</span></span> speed -</span>evp</span> aes-128-gcm</span>
</span>openssl</span></span> speed -</span>evp</span> chacha20-poly1305</span>
</span></code></pre>
参考输出:</p>
></span> openssl speed</span></span> -</span>evp</span> chacha20-poly1305</span>
</span>...</span></span> (略</span></span>) ...</span></span>
</span>The</span></span> '</span>numbers'</span></span> are in 1000s of bytes per second processed.</span>
</span>type</span></span>              2 bytes     31 bytes    136 bytes   1024 bytes   8192 bytes  16384 bytes</span>
</span>ChaCha20-Poly1305</span></span>   135090.41k   398677.07k   685502.68k  4633523.20k  5013787.99k  5053565.35k</span>
</span>></span> openssl speed</span></span> -</span>evp</span> aes-128-gcm</span>
</span>...</span></span> (略</span></span>) ...</span></span>
</span>The</span></span> '</span>numbers'</span></span> are in 1000s of bytes per second processed.</span>
</span>type</span></span>              2 bytes     31 bytes    136 bytes   1024 bytes   8192 bytes  16384 bytes</span>
</span>AES-128-GCM</span></span>      16855.33k   246339.19k  1061738.45k  4942513.83k 13130011.57k 14806788.78k</span>
</span></code></pre>
结果显示, 在笔者的机器上, AES-128-GCM 的加密速度 (14.8 GB/s) 明显快于 ChaCha20-Poly1305 (5.1 GB/s).
然而, 5 GB/s 是 40 Gbps 的网络带宽才能达到的速度了, 还只用到了一个核心.</p>
</blockquote>
对称加密算法</h3>
以下列举一些常见的对称加密算法.</p>
安全的:</p>

AES (Advanced Encryption Standard, 高级加密标准): 目前最流行的对称加密算法, 由 NIST 于 2001 年发布. 支持 128, 192 和 256 位密钥长度. AES 是一种分组密码算法, 块大小为 128 位, 使用 128 位的 IV. AES-GCM 是目前最常用的对称加密方案之一.</li>
ChaCha: Salsa 改进版变种, 包括 Chacha20 等. 使用 128 / 256 位密钥和 64 位 IV. ChaCha20-Poly1305 也是一种流行的对称加密方案, 结合了 ChaCha20 流密码和 Poly1305 消息认证码.</li>
其他: 包括但不限于 RC5, RC6, 韩国的 ARIA (类似 AES), 中国的 SM4 (类似 AES) 等.</li>
</ul>
由于出现安全问题已弃用的:</p>

DES</li>
3DES</li>
RC4</li>
Blowfish</li>
…</li>
</ul>


在介绍完对称加密后, 我们来了解一下非对称加密. 在此之前, 我们先了解一下非对称密码学(公钥密码学)的基本概念.</p>
</blockquote>
公钥密码学</h2>

公钥密码系统的密钥始终以公钥/私钥对(密钥对</strong>, Key Pair)的形式出现, 公钥密码系统提供数学框架和算法来生成密钥对. 公钥通常与所有人共享, 而私钥则保密. 公钥密码系统在设计时就确保了在预期的算力下, 几乎不可能从其公开的公钥逆向演算出对应的私钥.</li>
公钥密码系统主要有三大用途: 加密与解密</strong>、签名与验证</strong>、密钥交换</strong>. 每种算法都需要使用到公钥和私钥, 比如由公钥加密的消息只能由私钥解密, 由私钥签名的消息需要用公钥验证. 由于加密解密、签名验证均需要两个不同的密钥, 故公钥密码学也被称为非对称密码学.</li>
</ol>
比较著名的公钥密码系统有: RSA、ECC、(EC)DH. 不同的公钥密码系统可以提供以下一项或多项功能:</p>

执行密钥对生成: 随机生成私钥和对应的公钥;</li>
执行加解密: 通过公钥加密, 通过私钥解密;</li>
作为密钥交换算法;</li>
执行数字签名 (消息认证): 通过私钥对消息进行签名, 通过公钥验证签名.</li>
</ul>
公钥密码系统的密钥交换功能, 我们已经在前面的文章讲述过, 在此不再赘述; 公钥密码系统的数字签名功能, 我们会在后文单独介绍.</p>
非对称加密</h3>
应用公钥密码系统的加(解)密功能即称非对称加(解)密. 非对称加密安全性相对于对称加密高, 但缺点也明显:</p>


算法更为复杂, 加解密速度比对称加密慢非常多.</p>
</li>

只能加密/解密很短的消息.</p>
如在 RSA 系统中, 输入消息需要被转换为大整数, 例如使用 OAEP 填充, 然后才能被加密为密文. (密文实质上就是另一个大整数.)</p>
一些非对称密码系统, 如 ECC, 不直接提供加密能力, 需要结合使用更复杂的方案才能实现加解密.</p>
</li>
</ul>
为此, 现代密码学协议一般混合使用对称加密和非对称加密</strong> 以发挥各自的优势, 如使用非对称加密方案来安全地生成、交换对称加密所需的共享密钥, 然后使用对称加密方案来加密实际的消息内容.</p>


KEM: 仅使用非对称加密算法加密另一个密钥, 实际数据的加解密由该密钥完成. 前面介绍 TLS 1.3 后量子密码学改进时提到过 ML-KEM, 这就是一个典型的 KEM.</p>
RSA-OAEP, RSA-KEM, ECIES-KEM 和 PSEC-KEM. 都是 KEM 加密方案.</p>
</li>

IKS: 集成加密方案, 在 KEM 技术上添加 KDF 等其他密码学算法达成更高安全性, 此处不展开.</p>
</li>
</ol>
RSA 公钥密码系统</h3>
RSA 密码系统是最早的公钥密码系统之一, 它基于模幂的数学和 RSA 问题的计算难度以及密切相关的整数分解问题 (IFP). RSA 算法以其作者的首字母命名, 并在计算机密码学的早期广泛使用.</p>
RSA 密码系统是典型的公钥密码系统, 完整提供了密钥对生成、加解密、密钥交换和数字签名等功能.</p>
RSA 私钥长度可以是 1024, 2048, 3072 或 4096 位及更长, 但 3072 位是目前的推荐最小长度, 过长的密钥也会导致加解密速度过慢.</p>
示例</h4>
2048 位 RSA 公钥示例 (表示为 2048 位十六进制整数模数 n 和 24 位公指数 e):</p>
n = 0xa709e2f84ac0e21eb0caa018cf7f697f774e96f8115fc2359e9cf60b1dd8d4048d974cdf8422bef6be3c162b04b916f7ea2133f0e3e4e0eee164859bd9c1e0ef0357c142f4f633b4add4aab86c8f8895cd33fbf4e024d9a3ad6be6267570b4a72d2c34354e0139e74ada665a16a2611490debb8e131a6cffc7ef25e74240803dd71a4fcd953c988111b0aa9bbc4c57024fc5e8c4462ad9049c7f1abed859c63455fa6d58b5cc34a3d3206ff74b9e96c336dbacf0cdd18ed0c66796ce00ab07f36b24cbe3342523fd8215a8e77f89e86a08db911f237459388dee642dae7cb2644a03e71ed5c6fa5077cf4090fafa556048b536b879a88f628698f0c7b420c4b7
</span>e = 0x010001
</span></code></pre>
以 RSA PKCS#8 PEM ASN.1 格式编码:</p>
-----BEGIN PUBLIC KEY-----
</span>MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApwni+ErA4h6wyqAYz39p
</span>f3dOlvgRX8I1npz2Cx3Y1ASNl0zfhCK+9r48FisEuRb36iEz8OPk4O7hZIWb2cHg
</span>7wNXwUL09jO0rdSquGyPiJXNM/v04CTZo61r5iZ1cLSnLSw0NU4BOedK2mZaFqJh
</span>FJDeu44TGmz/x+8l50JAgD3XGk/NlTyYgRGwqpu8TFcCT8XoxEYq2QScfxq+2FnG
</span>NFX6bVi1zDSj0yBv90uelsM226zwzdGO0MZnls4AqwfzayTL4zQlI/2CFajnf4no
</span>agjbkR8jdFk4je5kLa58smRKA+ce1cb6UHfPQJD6+lVgSLU2uHmoj2KGmPDHtCDE
</span>twIDAQAB
</span>-----END PUBLIC KEY-----
</span></code></pre>
2048 位 RSA 私钥示例, 对应于上述给定的公钥 (表示为十六进制 2048 位整数模数 n 和 2048 位秘密指数 d):</p>
n = 0xa709e2f84ac0e21eb0caa018cf7f697f774e96f8115fc2359e9cf60b1dd8d4048d974cdf8422bef6be3c162b04b916f7ea2133f0e3e4e0eee164859bd9c1e0ef0357c142f4f633b4add4aab86c8f8895cd33fbf4e024d9a3ad6be6267570b4a72d2c34354e0139e74ada665a16a2611490debb8e131a6cffc7ef25e74240803dd71a4fcd953c988111b0aa9bbc4c57024fc5e8c4462ad9049c7f1abed859c63455fa6d58b5cc34a3d3206ff74b9e96c336dbacf0cdd18ed0c66796ce00ab07f36b24cbe3342523fd8215a8e77f89e86a08db911f237459388dee642dae7cb2644a03e71ed5c6fa5077cf4090fafa556048b536b879a88f628698f0c7b420c4b7
</span>d = 0x10f22727e552e2c86ba06d7ed6de28326eef76d0128327cd64c5566368fdc1a9f740ad8dd221419a5550fc8c14b33fa9f058b9fa4044775aaf5c66a999a7da4d4fdb8141c25ee5294ea6a54331d045f25c9a5f7f47960acbae20fa27ab5669c80eaf235a1d0b1c22b8d750a191c0f0c9b3561aaa4934847101343920d84f24334d3af05fede0e355911c7db8b8de3bf435907c855c3d7eeede4f148df830b43dd360b43692239ac10e566f138fb4b30fb1af0603cfcf0cd8adf4349a0d0b93bf89804e7c2e24ca7615e51af66dccfdb71a1204e2107abbee4259f2cac917fafe3b029baf13c4dde7923c47ee3fec248390203a384b9eb773c154540c5196bce1
</span></code></pre>
以传统的 RSA PKCS#1 PEM ASN.1 格式编码, 看起来更长一些:</p>
-----BEGIN RSA PRIVATE KEY-----
</span>MIIEowIBAAKCAQEApwni+ErA4h6wyqAYz39pf3dOlvgRX8I1npz2Cx3Y1ASNl0zf
</span>hCK+9r48FisEuRb36iEz8OPk4O7hZIWb2cHg7wNXwUL09jO0rdSquGyPiJXNM/v0
</span>4CTZo61r5iZ1cLSnLSw0NU4BOedK2mZaFqJhFJDeu44TGmz/x+8l50JAgD3XGk/N
</span>lTyYgRGwqpu8TFcCT8XoxEYq2QScfxq+2FnGNFX6bVi1zDSj0yBv90uelsM226zw
</span>zdGO0MZnls4AqwfzayTL4zQlI/2CFajnf4noagjbkR8jdFk4je5kLa58smRKA+ce
</span>1cb6UHfPQJD6+lVgSLU2uHmoj2KGmPDHtCDEtwIDAQABAoIBABDyJyflUuLIa6Bt
</span>ftbeKDJu73bQEoMnzWTFVmNo/cGp90CtjdIhQZpVUPyMFLM/qfBYufpARHdar1xm
</span>qZmn2k1P24FBwl7lKU6mpUMx0EXyXJpff0eWCsuuIPonq1ZpyA6vI1odCxwiuNdQ
</span>oZHA8MmzVhqqSTSEcQE0OSDYTyQzTTrwX+3g41WRHH24uN479DWQfIVcPX7u3k8U
</span>jfgwtD3TYLQ2kiOawQ5WbxOPtLMPsa8GA8/PDNit9DSaDQuTv4mATnwuJMp2FeUa
</span>9m3M/bcaEgTiEHq77kJZ8srJF/r+OwKbrxPE3eeSPEfuP+wkg5AgOjhLnrdzwVRU
</span>DFGWvOECgYEAyIk7F0S0AGn2aryhw9CihDfimigCxEmtIO5q7mnItCfeQwYPsX72
</span>1fLpJNgfPc9DDfhAZ2hLSsBlAPLUOa0Cuny9PCBWVuxi1WjLVaeZCV2bF11mAgW2
</span>fjLkAXT34IX+HZl60VoetSWq9ibfkJHeCAPnh/yjdB3Vs+2wxNkU8m8CgYEA1Tzm
</span>mjJq7M6f+zMo7DpRwFazGMmrLKFmHiGBY6sEg7EmoeH2CkAQePIGQw/Rk16gWJR6
</span>DtUZ9666sjCH6/79rx2xg+9AB76XTFFzIxOk9cm49cIosDMk4mogSfK0Zg8nVbyW
</span>5nEb//9JCrZ18g4lD3IrT5VJoF4MhfdBUjAS1jkCgYB+RDIpv3+bNx0KLgWpFwgN
</span>Omb667B6SW2ya4x227KdBPFkwD9HYosnQZDdOxvIvmUZObPLqJan1aaDR2Krgi1S
</span>oNJCNpZGmwbMGvTU1Pd+Nys9NfjR0ykKIx7/b9fXzman2ojDovvs0W/pF6bzD3V/
</span>FH5HWKLOrS5u4X3JJGqVDwKBgQCd953FwW/gujld+EpqpdGGMTRAOrXqPC7QR3X5
</span>Beo0PPonlqOUeF07m9/zsjZJfCJBPM0nS8sO54w7ESTAOYhpQBAPcx/2HMUsrnIj
</span>HBxqUOQKe6l0zo6WhJQi8/+cU8GKDEmlsUlS3iWYIA9EICJoTOW08R04BjQ00jS7
</span>1A1AUQKBgHlHrV/6S/4hjvMp+30hX5DpZviUDiwcGOGasmIYXAgwXepJUq0xN6aa
</span>lnT+ykLGSMMY/LABQiNZALZQtwK35KTshnThK6zB4e9p8JUCVrFpssJ2NCrMY3SU
</span>qw87K1W6engeDrmunkJ/PmvSDLYeGiYWmEKQbLQchTxx1IEddXkK
</span>-----END RSA PRIVATE KEY-----
</span></code></pre>
RSA 密钥生成</h4>
略, 相关应用参见加密库的文档.</p>
RSA 加解密</h4>
RSA 一次只能加密/解密一个(大)整数, 一般采用 OAEP 对消息编码为一个个整数再逐个加解密.</p>
RSA 签名与验证</h4>
参见后文介绍数字签名算法.</p>
ECC 公钥密码系统</h3>
ECC 椭圆曲线密码学于 1985 年被首次提出, 并于 2004 年开始被广泛应用. ECC 被认为是 RSA 的继任者, 新一代的非对称加密算法. 其最大的特点在于相同密码强度下, ECC 的密钥和签名的大小都要显著低于 RSA. 256 位的 ECC 密钥, 安全性与 3072 位的 RSA 密钥安全性相当. ECC 的密钥对生成、密钥交换与签名算法的速度都要比 RSA 快.</p>
ECC 中的椭圆曲线可以以多种形式呈现, 这些形式被证明是同构</strong>的:</p>


魏尔施特拉斯 (Weierstrass) 形式: 这是最常见的椭圆曲线形式, 其方程为 $y^2=x^3+ax+b$</p>
如: $y^2=x^3+7$ (secp256k1, 加密货币领域常用).</p>

需要指出, NSA 推荐的 secp256r1 (NIST P-256, prime256v1, nist256p1) 和 secp256k1 名称只有一字之差, k 和 r 的不同. 其中 k 表示 Koblitz (ECC 发明人), 而 r 表示随机, 即参数是随机选取的, 但美国国家安全局 NSA 并没有公布随机数的挑选规则, 有质疑称 NSA 可能对随机数动过手脚, 让破解难度大幅降低.</p>
</blockquote>
</li>

蒙哥马利 (Montgomery) 形式: 其方程为 $By^2=x^3+Ax^2+x$</p>
如 Curve25519: $y^2 = x^3+486662x^2+x$.</p>
</li>

爱德华兹 (Edwards) 形式: 其方程为 $x^2+y^2=1+dx^2y^2$</p>
如 Ed448: $x^2+y^2=1-39081x^2y^2$. (也可以写成蒙哥马利形式, 称 Curve448).</p>
一般而言, Edwards 形式性能更好, 如 Ed25519 是基于 Curve25519 同构地 “扭曲” 而来, 专为计算速度优化而设计的.</p>
</li>
</ul>
我们推荐使用 Curve52219 / Ed25519 以及 Curve448 / Ed448, 其性能和安全性均优于 NSA 推荐的 NIST P-256 (secp256r1), NIST P-384 (secp384r1), NIST P-521 (secp521r1) 等曲线. 参见 https://safecurves.cr.yp.to</a>.</p>

轶事一则</p>
参考: https://www.cnblogs.com/greencollar/p/14363535.html</a></p>
Daniel J. Bernstein 是世界著名的密码学家, 他在大学曾经开设过一门 UNIX 系统安全的课程给学生, 结果一学期下来, 发现了 UNIX 程序中的 91 个安全漏洞; 他早年在美国依然禁止出口加密算法时, 曾因为把自己设计的加密算法发布到网上遭到了美国政府的起诉, 他本人抗争六年, 最后美国政府撤销所有指控, 目前另一个非常火的高性能安全流密码 ChaCha20 也是出自 Bernstein 之手.</p>
Curve25519 自 2006 年发表以来, 除了学术界无人问津. 但自 2013 年斯诺登曝光棱镜计划后, 该算法突然大火. Curve25519 安全性高, 不同于 NIST 推荐的 P-256 等曲线, Curve25519 的参数是公开透明的, 任何人都可以验证其安全性, 而 NSA 推荐的 NIST P-256 等曲线方程的系数使用了来历不明的随机种子, 在密码学上难以验证其安全性; 此外, Curve25519 的设计也充分考虑了缓存攻击等, 尽可能避免分支跳转, 在实践上安全性也非常高.</p>
</blockquote>
数字签名算法 (digital signature algorithm, DSA)</h2>
在密码学中, 数字签名为数字文档提供消息身份验证、完整性和不可否认性. 数字签名基于公钥密码系统, 消息签名由私有密钥执行, 消息验证由相应的公钥执行.</p>
数字签名的过程本质还是加解密, 但是加解密的对象变成了消息的哈希值: 使用私钥签名 (加密哈希值), 公钥验证 (解密后比对实际的哈希值).</p>
RSA 数字签名算法</h3>
即使用 RSA 公钥密码系统的数字签名算法.</p>

刚刚好, 哈希值就是一个大整数.</p>
</blockquote>
ECC 数字签名算法</h3>
即使用 ECC 公钥密码系统的数字签名算法. ECC 相对于 RSA, 在相同的安全强度下, 使用更短的密钥长度, 因此在计算和存储方面更为高效.</p>
常用的 ECC 数字签名算法包括:</p>


ECDSA: 在经典 Weierstrass 形式的有限域上使用加密椭圆曲线.</p>

出于特定实体影响, 目前的 ECC 证书一般使用 ECDSA 数字签名算法.</p>
需要指出, DSA 是 digital signature algorithm (数字签名算法) 的缩写, 但也可能特指 FIPS 186 Digital Signature Standard (DSS) 中定义的数字签名算法. 一般地, ECDSA 特指使用了 NIST P-256, NIST P-384 或 NIST P-521 曲线的 NIST DSA 的椭圆曲线实现.</p>
</blockquote>
</li>

EdDSA: 在 Edwards 形式的有限域上使用加密椭圆曲线.</p>
常用变体包括 Ed25519 (使用 Ed25519 曲线, SHA512 哈希算法) 或 Ed448 (使用 Ed448 曲线, SHAKE256 哈希算法).</p>
</li>
</ol>
我们推荐使用 EdDSA 作为数字签名算法, 原因前面已经提到过.</p>
数字证书</h2>
(本节内容大部分摘录自 https://thiscute.world/posts/about-tls-cert</a>) 的总结, 向原作者表示感谢!)</p>
我们已经熟悉了对称密码与非对称密码两个密码学体系:</p>

对称密码算法: 计算速度快、安全强度高, 但是缺乏安全保存、管理乃至交换密钥的手段 (PSK 一旦泄露, 则所有使用该密钥加密的通信均不再安全).</li>
非对称密码算法: 计算速度慢, 但是它给出了安全的密钥交换算法 DHE/ECDHE, 且公钥是可公开的, 这降低了密钥的保存与管理难度.</li>
</ul>
但是问题来了:</p>

公钥该如何分发? 比如 Alice 跟 Bob 交换公钥时, 如何确定收到的确实是对方的公钥, 也就是说如何确认公钥的真实性、完整性、认证其来源身份? (DH 是匿名的无认证的, 无法防止中间人攻击)</li>
如果 Alice 的私钥泄漏了, 她该如何作废自己旧的公钥?</li>
</ul>
数字证书与公钥基础架构就是为了解决上述问题而设计的.</p>
首先简单介绍下 PKI (Public Key Infrastructure, 公钥基础架构), 它是一组由硬件、软件、参与者、管理政策与流程组成的基础架构, 其目的在于创造、管理、分配、使用、存储以及撤销数字证书. PKI 是一个总称, 而并非指单独的某一个规范或标准, 因此显然数字证书的规范 (X.509)、存储格式等都是 PKI 的一部分.</p>
公钥证书</h3>
前面我们介绍了公钥密码系统存在的一个问题是 “在分发公钥时, 难以确认公钥的真实性、完整性及其来源身份”. PKI 通过数字证书和证书认证机构来解决这个问题.</p>
数字证书指的其实就是公钥证书 (也可直接简称为证书). 在现代网络通讯中通行的公钥证书格式标准名为 X.509 v3, 由 RFC5280</a> 定义, 被广泛应用在 TLS 等众多加密通讯协议中.</p>
一个公钥证书内容应当包括:</p>


证书</p>

序列号 (Serial Number): 用以识别每一张证书, 在作废证书的时候会用到它.</li>
版本: 证书的规范版本.</li>
公钥 (Public Key): 证书所包含的公钥.</li>
公钥指纹: 即公钥的 Hash 值, 当前大部分证书都使用 SHA256 计算此指纹.</li>
公钥用途 (Key Usage + Extended Key Usage): 记录了此证书可用于哪些用途, 如数字签名、身份认证等.</li>
主体 (Subject): 即姓名、组织、邮箱、地址等证书拥有者的个人信息.</li>
证书有效期的开始时间、结束时间 (Not Before + Not After): 为了确保安全性, 每个证书都会记录一个自身的有效期.</li>
签发者 (Issuer): 签发此证书的实体.</li>
其他拓展信息.</li>
</ul>
</li>

数字签名 (Signature): 对整个证书计算数字签名, 来确保这些数据的真实性、完整性, 确保证书未被恶意篡改/伪造.</p>
此数字签名由证书签发者使用其私钥+证书内容计算得出.</p>
</li>

数字签名算法 (Signature Algorithm): 证书所使用的签名算法, 常用的有 RSA-SHA-256 与 ECDSA-SHA-256.</p>
</li>
</ul>
每个证书都有唯一的 ID, 这样在私钥泄漏的情况下, 我们可以通过公钥基础设施的 OCSP (Online Certificate Status Protocol) 协议吊销某个证书. 吊销证书的操作还是比较罕见的, 毕竟私钥泄漏并不容易遇到, 因此这里就略过不提了, 有需要的可以自行搜索.</p>
感兴趣的, 可以使用浏览器查看证书详情的功能查看一下自己常用网站的证书, 了解一下证书的具体内容, 这里是旧版 Firefox 查看谷歌网站的示例:</p>

  
</div>
证书签发机构 (CA) 与证书链</h3>
前面介绍证书内容时, 提到了签发者会使用签发者私钥和证书内容生成数字签名, 显然需要使用签发者公钥来验证被签发证书中的签名. 但是问题又来了, 签发者的公钥该如何分发? 这不又回到了最初的问题吗?</p>
为此, PKI 引入了一个可信第三方 (Trusted third party, TTP) 来解决这个问题.</p>
在 Alice 与 Bob 的案例中, 就是说还有个可信第三方 Eve, 他使用自己的私钥为自己的公钥证书签了名, 生成了一个自签名</em>证书, 并且已经提前将这个自签名证书分发(比如当面交付、预置在操作系统中等手段)给了 Alice 跟 Bob.</p>


现在 Alice 首先使用自己的公钥以及个人信息制作了自己的公钥证书, 但是这个证书还缺乏一个 Issuer 以及数字签名.</p>
</li>

Alice 找到 Eve, 将这个 CSR 文件提交给 Eve, 希望 Eve 为自己的证书签名. 此时, 我们称之为提交CSR</strong> (Certificate Signing Request, CSR)</p>
</li>

Eve 验证了 Alice 的身份后, 再使用这个 CSR 签发出完整的证书文件 (Issuer 就填 Eve, 然后 Eve 使用自己的私钥计算出证书的数字签名, 这样就得到了最终的证书), 交付给 Alice.</p>
Eve 曾经 “跨越千里之遥”, 将自己的公钥证书分发给了 Bob, 所以在给 Alice 签发证书时, 他显然可能会要求 Alice 给付签名费</em>. 目前许多证书机构就是靠这个赚钱的, 当然也有非盈利的证书颁发机构, 如 ZeroSSL 等 (真的是做慈善么).</p>
</li>

现在 Alice 再将经 Eve 签名的证书发送给 Bob</p>
</li>

Bob 收到证书后, 看到 Issuer 是 Eve, 于是找出以前 Eve 给他的自签名</em>证书, 然后使用其中的公钥验证收到的证书.</p>
如果验证成功, 就说明证书的内容是经过 Eve 认证的. 如果 Eve 没老糊涂了, 那这个证书应该确实就是 Alice 的. 否则, 这是某个攻击者伪造的证书.</p>
</li>
</ul>
在现实世界中, Eve 这个角色被称作 CA (Certification Authority, 证书认证机构), 全世界只有几十家这样的权威机构, 它们都通过了各大软件厂商的严格审核</em>, 从而将根证书(CA 证书)直接内置于主流操作系统与浏览器中, 也就是说早就提前分发给了因特网世界的几乎所有用户. 由于许多操作系统或软件的更新迭代缓慢, 根证书的有效期通常都在十年以上.</p>
但是, 如果 CA 机构直接使用自己的私钥处理各种证书签名请求, 这将是非常危险的. 因为全世界有海量的 HTTPS 网站, 也就是说有海量的证书需求, 可一共才几十家 CA 机构. 频繁的动用私钥会产生私钥泄漏的风险, 如果这个私钥泄漏了, 那将直接影响海量网站的安全性.</p>
PKI 架构使用数字证书链的机制来解决这个问题:</p>

  
</div>


CA 机构首先生成自己的根证书与私钥, 并使用私钥给根证书签名</p>
因为私钥跟证书本身就是一对, 因此根证书也被称作自签名证书.</p>
</li>

CA 交付根证书给各大软硬件厂商, 内置在主流的操作系统与浏览器中.</p>
</li>

CA 使用私钥签发一些所谓的中间证书, 之后就把私钥雪藏了, 非必要不会再拿出来使用.</p>
根证书的私钥通常离线存储在安全地点; 中间证书的有效期通常会比根证书短一些; 部分中间证书会被作为备份使用, 平常不会启用.</p>

CA 机构使用这些中间证书的私钥, 为用户提交的所有 CSR 请求签名.</li>
CA 机构也可以使用中间证书的私钥, 为子一级 CA 机构签发中间证书, 形成更长的证书链.</li>
不同 CA 机构也可能执行交叉签名, 共同为对方的中间证书签名. 客户端只要安装有其中任何一个根证书, 就能验证该中间证书.</li>
</ul>
</li>
</ul>
上述这个全球互联网上, 由证书认证机构、操作系统与浏览器内置的根证书、TLS 加密认证协议、OCSP 证书吊销协议等等组成的架构, 我们可以称它为 Web PKI</strong>.</p>
Web PKI 通常是可信</em>的, 但是并不意味着它们可靠</em>.</p>

可以说, 谁掌握</em>了 CA, 谁就能对如今互联网安全所仰赖的 TLS 通信执行 MitM.</p>
</blockquote>
在更高安全性要求的场景中, 搭建私有 PKI 架构是有必要的, 如支付场景下银行 APP 等要求安装特定数字证书, 即安装了一个由支付机构控制的私有 CA 证书, 或者以 U 盾形式存在的硬件介质的证书; 又或者内部通讯系统, 也会使用私有 CA 证书来签发内部服务器的证书. 这种情况下, 私有 CA 证书需要被提前手动安装在客户端设备上, 否则会提示不受信任的证书错误.</p>
TLS 证书主体 (Subject)</h3>
TLS 证书的主体字段包含了证书持有者的身份信息, 我们主要关注其中的通用名称 (Common Name, CN) 和主体备用名称 (Subject Alternative Name, SAN).</p>
CN 是证书的 “主域名”, SAN 则是该证书所覆盖的所有域名或 IP 地址. 由于 CN 字段只能有一个, 无法满足单证书保护多个子域的需求, 实际上已被弃用, 我们通过 SAN 字段来指定证书所覆盖的域名/IP 地址.</p>
一般地, 我们使用的证书均为域名证书, 但也有 IP 证书 (只能是公网 IP, 难以自动化申请, 而且收费一般不便宜, 目前应该只有 ZeroSSL 提供了免费</em>的 IP 证书), 如著名的 https://1.1.1.1</code>.</p>
SAN 支持配置泛域名, 即 *.example.com</code> 的形式, 但不支持多级泛域名, 即 *.*.example.com</code> 的形式; *.example.com</code> 只能匹配到同级子域名 a.example.com</code>, 不能匹配 a.b.example.com</code> 等.</p>
SAN 可以设置很多个, 如:</p>

  
</div>
补充内容: 证书以及公私钥的(文本)编码</h2>
由于历史原因, 实践上对证书以及公私钥的存储格式可谓五花八门, 这里参考了 RFC 7468 以及 https://thiscute.world/posts/about-tls-cert/#pki</a>, 试图做一个实用意义上比较全面的总结.</p>
基本概念</h3>


X.509: PKI 标准, 规定了证书应该包含哪些信息 (但是未定义证书该如何存储). PKIX 即 “Public Key Infrastructure X.509”.</p>
</li>

ASN.1 (Abstract Syntax Notation One, 抽象语法标记法第 1 部分): 一种用于描述数据结构的标准, 广泛应用于通信协议和加密标准中. ASN.1 定义了数据的语法和语义, 使得不同系统之间能够理解和交换数据. 被应用于 X.509 证书、PKCS 标准等.</p>
感兴趣的, 可以参考 https://letsencrypt.org/zh-cn/docs/a-warm-welcome-to-asn1-and-der/</a> 的总结.</p>
</li>

DER (Distinguished Encoding Rules, 可辨别编码规则): ASN.1 的一种序列化规则, 用于将 ASN.1 数据结构编码为二进制格式. 定义于 X.690 标准中.</p>
DER 编码的证书通常</em>使用 .cer</code> 或 .der</code> 作为文件扩展名, 但也有使用 .crt</code> 的 (RFC 7468 要求使用此拓展名保存文本格式), 更有使用 .cer</code> 保存 PEM 格式的证书的. 在实践上, 尝试以纯文本形式打开看看就知道了.</p>
</li>

PEM (Privacy-Enhanced Mail, 隐私增强邮件): “隐私增强邮件” 自身已鲜少使用, 但其定义的基于文本的编码格式, 如今被广泛应用于证书(链)和公私钥的文本编码中. PEM 格式可以理解为对 DER 编码的证书或密钥进行 Base64 编码并添加封装边界.</p>
</li>

PKCS (Public Key Cryptography Standards, 公钥密码学标准).</p>
</li>
</ol>
PEM 格式</h3>
(以下来自 RFC7468</a>, 但是由于历史因素, 实践中 PEM 格式的使用也存在不完全符合 RFC 7468 的定义的情况)</p>
文本编码以一行包含 “-----BEGIN </code>”、标签和 “-----</code>” 开始, 并以一行包含 “-----END </code>”、标签和 “-----</code>” 结束. 在这些行 (或称“封装边界“) 之间, 是根据 RFC4648 第 4 节进行 Base64 编码的数据 (PEM RFC1421</a> 称这部分数据为 “封装文本部分”). 封装边界之前允许存在数据, 解析器在处理此类数据时绝不能</strong>出错. 此外, 解析器必须</strong>忽略空白字符及其他非 Base64 字符, 且必须</strong>支持不同的换行规范.</p>
编码数据的类型由 “-----BEGIN </code>” (前置封装边界) 行中的类型标签决定. 例如, “-----BEGIN CERTIFICATE-----</code>” 表示内容是一个 PKIX 证书. 生成器必须</strong>在 “-----END </code>” (后置封装边界) 行使用与对应 “-----BEGIN </code>” 行相同的标签. 标签由区分大小写的、全大写的零个或多个字符组成; 不得包含连续空格或连字符, 首尾也不得出现空格或连字符. 若标签不匹配, 解析器可以</strong>选择忽略后置封装边界中的标签而非报错: 现存实现中部分要求标签匹配, 部分不作要求.</p>
“BEGIN” 或 “END” 与标签之间必须严格用一个空格字符 (SP) 分隔. 封装边界两端的连字符 (即短横线 “-”) 必须正好五个, 不能多也不能少.</p>
标签类型暗示编码数据遵循特定语法. 解析器必须</strong>能够优雅处理不符合规范的数据. 但需注意本文档发布前的解析器或生成器行为并不统一. 合法的解析器可能</strong>将内容解释为其他标签类型, 但应注意安全考量章节讨论的潜在风险. 本文档描述的标签标识的容器格式不与特定加密算法绑定, 这符合算法敏捷性原则. 这些格式采用 RFC5280</a> 第 4.1.1.2 节所述的 ASN.1 AlgorithmIdentifier 结构.</p>
与传统 PEM 编码 RFC1421</a>、OpenPGP ASCII armor 及 OpenSSH 密钥文件格式不同, 文本编码不</em>定义也不允许在数据旁编码头信息. 前置封装边界与 Base64 数据之间允许存在空白, 但生成器绝不能</strong>产生此类空白 (保留此空白区域是对 PEM “封装头部分” 定义的沿袭).</p>
PKCS #1 标准</h3>
专用于编码 RSA 公私钥, PEM 标签为 “RSA PUBLIC KEY” 和 “RSA PRIVATE KEY”.</p>
示例:</p>
-----BEGIN RSA PUBLIC KEY-----
</span>MIIBCgKCAQEApwni+ErA4h6wyqAYz39pf3dOlvgRX8I1npz2Cx3Y1ASNl0zfhCK+
</span>9r48FisEuRb36iEz8OPk4O7hZIWb2cHg7wNXwUL09jO0rdSquGyPiJXNM/v04CTZ
</span>o61r5iZ1cLSnLSw0NU4BOedK2mZaFqJhFJDeu44TGmz/x+8l50JAgD3XGk/NlTyY
</span>gRGwqpu8TFcCT8XoxEYq2QScfxq+2FnGNFX6bVi1zDSj0yBv90uelsM226zwzdGO
</span>0MZnls4AqwfzayTL4zQlI/2CFajnf4noagjbkR8jdFk4je5kLa58smRKA+ce1cb6
</span>UHfPQJD6+lVgSLU2uHmoj2KGmPDHtCDEtwIDAQAB
</span>-----END RSA PUBLIC KEY-----
</span></code></pre>
-----BEGIN RSA PRIVATE KEY-----
</span>MIIEowIBAAKCAQEApwni+ErA4h6wyqAYz39pf3dOlvgRX8I1npz2Cx3Y1ASNl0zf
</span>hCK+9r48FisEuRb36iEz8OPk4O7hZIWb2cHg7wNXwUL09jO0rdSquGyPiJXNM/v0
</span>4CTZo61r5iZ1cLSnLSw0NU4BOedK2mZaFqJhFJDeu44TGmz/x+8l50JAgD3XGk/N
</span>lTyYgRGwqpu8TFcCT8XoxEYq2QScfxq+2FnGNFX6bVi1zDSj0yBv90uelsM226zw
</span>zdGO0MZnls4AqwfzayTL4zQlI/2CFajnf4noagjbkR8jdFk4je5kLa58smRKA+ce
</span>1cb6UHfPQJD6+lVgSLU2uHmoj2KGmPDHtCDEtwIDAQABAoIBABDyJyflUuLIa6Bt
</span>ftbeKDJu73bQEoMnzWTFVmNo/cGp90CtjdIhQZpVUPyMFLM/qfBYufpARHdar1xm
</span>qZmn2k1P24FBwl7lKU6mpUMx0EXyXJpff0eWCsuuIPonq1ZpyA6vI1odCxwiuNdQ
</span>oZHA8MmzVhqqSTSEcQE0OSDYTyQzTTrwX+3g41WRHH24uN479DWQfIVcPX7u3k8U
</span>jfgwtD3TYLQ2kiOawQ5WbxOPtLMPsa8GA8/PDNit9DSaDQuTv4mATnwuJMp2FeUa
</span>9m3M/bcaEgTiEHq77kJZ8srJF/r+OwKbrxPE3eeSPEfuP+wkg5AgOjhLnrdzwVRU
</span>DFGWvOECgYEAyIk7F0S0AGn2aryhw9CihDfimigCxEmtIO5q7mnItCfeQwYPsX72
</span>1fLpJNgfPc9DDfhAZ2hLSsBlAPLUOa0Cuny9PCBWVuxi1WjLVaeZCV2bF11mAgW2
</span>fjLkAXT34IX+HZl60VoetSWq9ibfkJHeCAPnh/yjdB3Vs+2wxNkU8m8CgYEA1Tzm
</span>mjJq7M6f+zMo7DpRwFazGMmrLKFmHiGBY6sEg7EmoeH2CkAQePIGQw/Rk16gWJR6
</span>DtUZ9666sjCH6/79rx2xg+9AB76XTFFzIxOk9cm49cIosDMk4mogSfK0Zg8nVbyW
</span>5nEb//9JCrZ18g4lD3IrT5VJoF4MhfdBUjAS1jkCgYB+RDIpv3+bNx0KLgWpFwgN
</span>Omb667B6SW2ya4x227KdBPFkwD9HYosnQZDdOxvIvmUZObPLqJan1aaDR2Krgi1S
</span>oNJCNpZGmwbMGvTU1Pd+Nys9NfjR0ykKIx7/b9fXzman2ojDovvs0W/pF6bzD3V/
</span>FH5HWKLOrS5u4X3JJGqVDwKBgQCd953FwW/gujld+EpqpdGGMTRAOrXqPC7QR3X5
</span>Beo0PPonlqOUeF07m9/zsjZJfCJBPM0nS8sO54w7ESTAOYhpQBAPcx/2HMUsrnIj
</span>HBxqUOQKe6l0zo6WhJQi8/+cU8GKDEmlsUlS3iWYIA9EICJoTOW08R04BjQ00jS7
</span>1A1AUQKBgHlHrV/6S/4hjvMp+30hX5DpZviUDiwcGOGasmIYXAgwXepJUq0xN6aa
</span>lnT+ykLGSMMY/LABQiNZALZQtwK35KTshnThK6zB4e9p8JUCVrFpssJ2NCrMY3SU
</span>qw87K1W6engeDrmunkJ/PmvSDLYeGiYWmEKQbLQchTxx1IEddXkK
</span>-----END RSA PRIVATE KEY-----
</span></code></pre>
如今已经统一转向使用 PKCS #8 格式保存私钥, 公钥则按 RFC7468</a> Section 13 所述的格式保存.</p>
ANSI X9.62 (ITU-T X.894) 标准</h3>
类似 PKCS #1 标准, 但此标准仅用于编码 ECC 私钥, PEM 标签为 “EC PRIVATE KEY”.</p>
示例 (使用 openssl ecparam -name secp384r1 -genkey -noout -out privkey.pem</code> 生成):</p>
-----BEGIN EC PRIVATE KEY-----
</span>MIGkAgEBBDDhhKJcKC7jnRbKLYKAzY1f/9aC9JGGuqqo2d4FejHSi/TOZiLf3JhP
</span>xAb+IJdQYEqgBwYFK4EEACKhZANiAARPyjgUZlw+IWfP/+PD8m1HZRWbEvUB+ai9
</span>pTV63SI7MWw5OzM3qKwTUNP+NK3xFt14A5lJwFMzl5AB7QhJYarW5ra3e2yhP8Vn
</span>oC9E7Om31FLwVX+AHTM4Rg0ZQQoqH0c=
</span>-----END EC PRIVATE KEY-----
</span></code></pre>
类似地, 如今已经统一转向使用 PKCS #8 格式保存私钥.</p>
PKCS #7 / CMS 标准</h3>

PKCS #7 / CMS, 是一个多用途的证书描述格式. 它包含一个数据填充规则, 这个填充规则常被用在需要数据填充的分组加密、数字签名等算法中.</p>
由于历史原因, 有使用 PKCS #7 标准保存证书的, 后缀通常使用 .p7b</code> 或者 .p7c</code>, 可以使用 DER 或 PEM 格式保存:</p>

 
</div>
以下内容摘抄自 RFC7468</a> Section 8 和 Section 9.</p>
</blockquote>
PKCS #7 加密消息语法结构使用 “PKCS7” 标签进行编码. 编码内容必须</strong>是 BER (强烈推荐 DER 格式) 编码的 ASN.1 ContentInfo 结构, 如 RFC2315</a> 所述.</p>
-----BEGIN PKCS7-----
</span>MIHjBgsqhkiG9w0BCRABF6CB0zCB0AIBADFho18CAQCgGwYJKoZIhvcNAQUMMA4E
</span>CLfrI6dr0gUWAgITiDAjBgsqhkiG9w0BCRADCTAUBggqhkiG9w0DBwQIZpECRWtz
</span>u5kEGDCjerXY8odQ7EEEromZJvAurk/j81IrozBSBgkqhkiG9w0BBwEwMwYLKoZI
</span>hvcNAQkQAw8wJDAUBggqhkiG9w0DBwQI0tCBcU09nxEwDAYIKwYBBQUIAQIFAIAQ
</span>OsYGYUFdAH0RNc1p4VbKEAQUM2Xo8PMHBoYdqEcsbTodlCFAZH4=
</span>-----END PKCS7-----
</span></code></pre>
标签 “CERTIFICATE CHAIN” 曾用于表示仅包含证书列表的退化 (degenerated) PKCS #7 结构 (参见 RFC2315</a> 第 9 节). 多个现代工具已不再支持此标签. 生成器绝不能</strong>生成 “CERTIFICATE CHAIN” 标签. 解析器绝不能</strong>将 “CERTIFICATE CHAIN” 视为等同于 “PKCS7”. PKCS #7 是一个已被 CMS RFC5652</a> 长期取代的旧规范. 在 CMS 可作为替代方案时, 实现绝不能</strong>生成 PKCS #7.</p>
CMS 结构使用 “CMS” 标签进行编码. 编码内容必须</strong>是 BER (强烈推荐 DER 格式) 编码的 ASN.1 ContentInfo 结构, 如 RFC5652</a> 所述.</p>
-----BEGIN CMS-----
</span>MIGDBgsqhkiG9w0BCRABCaB0MHICAQAwDQYLKoZIhvcNAQkQAwgwXgYJKoZIhvcN
</span>AQcBoFEET3icc87PK0nNK9ENqSxItVIoSa0o0S/ISczMs1ZIzkgsKk4tsQ0N1nUM
</span>dvb05OXi5XLPLEtViMwvLVLwSE0sKlFIVHAqSk3MBkkBAJv0Fx0=
</span>-----END CMS-----
</span></code></pre>
CMS 是 IETF 对 PKCS #7 的继承. RFC5652</a> 第 1.1.1 节描述了自 PKCS #7 v1.5 以来的变更. 实现方案在可选时必须</strong>生成 CMS 格式, 以促进互操作性和前向兼容性.</p>
PKCS #8 标准</h3>

此标准专用于编码私钥, 且允许对私钥加密, 是现代非对称密钥存储的事实标准.</p>
私钥建议使用 .key</code> 作为文件扩展名, 但也有相当一部分人使用通用拓展名 .pem</code> 的.</p>
可以使用 openssl pkcs8 -topk8 -inform PEM -in private-key.pem -outform PEM -nocrypt -out private-key-pkcs8.pem</code> 来将传统私钥转换为 PKCS #8 格式.</p>
以下内容摘抄自 RFC7468</a> Section 10 和 Section 11.</p>
</blockquote>
未加密的 PKCS #8 私钥信息语法结构 (PrivateKeyInfo, 现更名为非对称密钥包 OneAsymmetricKey) 使用 “PRIVATE KEY” 标签编码. 编码内容必须</strong>是 BER (强烈推荐 DER 格式) 编码的 ASN.1 PrivateKeyInfo 结构, 如 PKCS #8 RFC5208</a> 所述, 或 OneAsymmetricKey 结构, 如 RFC5958</a> 所述. 两者语义相同, 可通过版本号区分.</p>
-----BEGIN PRIVATE KEY-----
</span>MIGHTAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQglQanBRiYVPX7F2Rd
</span>4CqyjEN0K4qfHw4tM/yMIh21wamhRANCAARsxaI4jT1b8zbDlFziuLngPcExbYzz
</span>ePAHUmgWL/ZCeqlODF/l/XvimkjaWC2huu1OSWB9EKuG+mKFY2Y5k+vF
</span>-----END PRIVATE KEY-----
</span></code></pre>
加密的 PKCS #8 私钥信息语法结构 (EncryptedPrivateKeyInfo, RFC5958</a> 中名称相同) 使用 “ENCRYPTED PRIVATE KEY” 标签编码. 编码内容必须</strong>是 BER (强烈推荐 DER 格式) 编码的 ASN.1 PrivateKeyInfo 结构, 如 PKCS #8 RFC5208</a> 和 RFC5958</a> 所述.</p>
-----BEGIN ENCRYPTED PRIVATE KEY-----
</span>MIHNMEAGCSqGSIb3DQEFDTAzMBsGCSqGSIb3DQEFDDAOBAghhICA6T/51QICCAAw
</span>FAYIKoZIhvcNAwcECBCxDgvI59i9BIGIY3CAqlMNBgaSI5QiiWVNJ3IpfLnEiEsW
</span>Z0JIoHyRmKK/+cr9QPLnzxImm0TR9s4JrG3CilzTWvb0jIvbG3hu0zyFPraoMkap
</span>8eRzWsIvC5SVel+CSjoS2mVS87cyjlD+txrmrXOVYDE+eTgMLbrLmsWh3QkCTRtF
</span>QC7k0NNzUHTV9yGDwfqMbw==
</span>-----END ENCRYPTED PRIVATE KEY-----
</span></code></pre>
PKCS #12 标准</h3>
PKCS #12 是一个归档文件格式, 不是文本编码, 但这里也顺带说一下了. 主要用于存储多个私钥及相关的 X.509 证书, 常用拓展名为 .p12</code>, .pfx</code>. 因为保存了私钥, 为了安全性它通常是加密的, 需要解密后才能使用.</p>
安卓开发者应该比较熟悉, APK 签名证书通常就是使用 PKCS #12 格式存储的, 拓展名为 .keystore</code> 或者 .jks</code> 而已.</p>
公钥 (Public Key) PEM 编码标准 (RFC 7468 Section 13)</h3>
公钥信息结构 (SubjectPublicKeyInfo) 使用 “PUBLIC KEY” 标签进行编码. 编码内容必须</strong>是 BER (强烈推荐 DER 格式) 编码的 ASN.1 SubjectPublicKeyInfo 结构, 如 RFC5280</a> 第 4.1.2.7 节所述.</p>
-----BEGIN PUBLIC KEY-----
</span>MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEn1LlwLN/KBYQRVH6HfIMTzfEqJOVztLe
</span>kLchp2hi78cCaMY81FBlYs8J9l7krc+M4aBeCGYFjba+hiXttJWPL7ydlE+5UG4U
</span>Nkn3Eos8EiZByi9DVsyfy9eejh+8AXgp
</span>-----END PUBLIC KEY-----
</span></code></pre>
证书 (Certificate) PEM 编码标准 (RFC 7468 Section 5)</h3>

这里的 “证书”, 指互联网 X.509 公钥基础设施证书及证书吊销列表 (Certificate Revocation Lists, CRL) 规范 RFC5280</a> 中的 “证书”.</p>
以下内容摘抄自 RFC7468</a> Section 5.</p>
</blockquote>
5.1. 编码</p>
公钥证书使用 “CERTIFICATE” 标签进行编码.</p>
编码内容必须</strong>是 BER (强烈推荐 DER 格式) 编码的 ASN.1 Certificate 结构, 如 RFC5280</a> 第 4 节所述.</p>
-----BEGIN CERTIFICATE-----
</span>MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G
</span>A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y
</span>aXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdudVRMUyBjZXJ0aWZpY2F0
</span>ZSBhdXRob3JpdHkwHhcNMTEwNTIzMjAzODIxWhcNMTIxMjIyMDc0MTUxWjB9MQsw
</span>CQYDVQQGEwJCRTEPMA0GA1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2Vy
</span>dGlmaWNhdGUgYXV0aG9yaXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdu
</span>dVRMUyBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkwWTATBgcqhkjOPQIBBggqhkjOPQMB
</span>BwNCAARS2I0jiuNn14Y2sSALCX3IybqiIJUvxUpj+oNfzngvj/Niyv2394BWnW4X
</span>uQ4RTEiywK87WRcWMGgJB5kX/t2no0MwQTAPBgNVHRMBAf8EBTADAQH/MA8GA1Ud
</span>DwEB/wQFAwMHBgAwHQYDVR0OBBYEFPC0gf6YEr+1KLlkQAPLzB9mTigDMAoGCCqG
</span>SM49BAMCA0gAMEUCIDGuwD1KPyG+hRf88MeyMQcqOFZD0TbVleF+UsAGQ4enAiEA
</span>l4wOuDwKQa+upc8GftXE2C//4mKANBC6It01gUaTIpo=
</span>-----END CERTIFICATE-----
</span></code></pre>
以上为示例.</p>
历史上曾使用过 “X509 CERTIFICATE” 标签, 以及较少使用的 “X.509 CERTIFICATE” 标签. 符合本文件的生成器必须</strong>生成 “CERTIFICATE” 标签, 绝不能</strong>生成 “X509 CERTIFICATE” 或 “X.509 CERTIFICATE” 标签. 解析器绝不能</strong>将 “X509 CERTIFICATE” 或 “X.509 CERTIFICATE” 视为等同于 “CERTIFICATE”, 但有效的例外可能是为了向后兼容性 (可能附带警告).</p>
5.2. 说明性文本</p>
已知许多工具在 PKIX 证书的 BEGIN 行之前和 END 行之后会输出说明性文本, 比其他类型的证书更为常见. 如果输出此类文本, 应使其与证书相关, 例如提供证书中关键数据元素的文本表示.</p>
Subject: CN=Atlantis
</span>Issuer: CN=Atlantis
</span>Validity: from 7/9/2012 3:10:38 AM UTC to 7/9/2013 3:10:37 AM UTC
</span>-----BEGIN CERTIFICATE-----
</span>MIIBmTCCAUegAwIBAgIBKjAJBgUrDgMCHQUAMBMxETAPBgNVBAMTCEF0bGFudGlz
</span>MB4XDTEyMDcwOTAzMTAzOFoXDTEzMDcwOTAzMTAzN1owEzERMA8GA1UEAxMIQXRs
</span>YW50aXMwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAu+BXo+miabDIHHx+yquqzqNh
</span>Ryn/XtkJIIHVcYtHvIX+S1x5ErgMoHehycpoxbErZmVR4GCq1S2diNmRFZCRtQID
</span>AQABo4GJMIGGMAwGA1UdEwEB/wQCMAAwIAYDVR0EAQH/BBYwFDAOMAwGCisGAQQB
</span>gjcCARUDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDAzA1BgNVHQEE
</span>LjAsgBA0jOnSSuIHYmnVryHAdywMoRUwEzERMA8GA1UEAxMIQXRsYW50aXOCASow
</span>CQYFKw4DAh0FAANBAKi6HRBaNEL5R0n56nvfclQNaXiDT174uf+lojzA4lhVInc0
</span>ILwpnZ1izL4MlI9eCSHhVQBHEp2uQdXJB+d5Byg=
</span>-----END CERTIFICATE-----
</span></code></pre>
5.3. 文件扩展名</p>
尽管 PKIX 结构的文本编码可以出现在任何地方, 但已知许多工具在序列化 PKIX 结构时会提供输出此编码的选项. 为了促进互操作性并将 DER 编码与文本编码分开, 证书的文本编码应使用 “.crt” 扩展名. 实现应意识到, 尽管有此建议, 许多工具仍默认使用 “.cer” 扩展名对证书进行此类文本编码.</p>
本节不会以任何方式干扰官方的 application/pkix-cert 注册 RFC2585</a> (其中规定 “每个 ‘.cer’ 文件包含一个 DER 格式编码的证书”), 而仅是阐明一种广泛存在的事实上的替代方案.</p>

证书链 (Certificate chain) 通常是多个证书的集合, 但似乎并没有一个统一的标准来表示它.</p>
实践上, 可以将多个 PEM 编码的证书直接串联在一个文件中, RFC7468</a> 也允许这么干.</p>
</blockquote>
PKCS #10 标准</h3>

这个标准是为证书请求语法 (Certificate Request Syntax) 准备的, 不过笔者个人没怎么见过, 但还是顺带说一下了.</p>
以下内容摘抄自 RFC7468</a> Section 7.</p>
</blockquote>
PKCS #10 证书请求使用 “CERTIFICATE REQUEST” 标签进行编码. 编码内容必须</strong>是 BER (强烈推荐 DER 格式) 编码的 ASN.1 CertificationRequest 结构, 如 RFC2986</a> 所述.</p>
-----BEGIN CERTIFICATE REQUEST-----
</span>MIIBWDCCAQcCAQAwTjELMAkGA1UEBhMCU0UxJzAlBgNVBAoTHlNpbW9uIEpvc2Vm
</span>c3NvbiBEYXRha29uc3VsdCBBQjEWMBQGA1UEAxMNam9zZWZzc29uLm9yZzBOMBAG
</span>ByqGSM49AgEGBSuBBAAhAzoABLLPSkuXY0l66MbxVJ3Mot5FCFuqQfn6dTs+9/CM
</span>EOlSwVej77tj56kj9R/j9Q+LfysX8FO9I5p3oGIwYAYJKoZIhvcNAQkOMVMwUTAY
</span>BgNVHREEETAPgg1qb3NlZnNzb24ub3JnMAwGA1UdEwEB/wQCMAAwDwYDVR0PAQH/
</span>BAUDAwegADAWBgNVHSUBAf8EDDAKBggrBgEFBQcDATAKBggqhkjOPQQDAgM/ADA8
</span>AhxBvfhxPFfbBbsE1NoFmCUczOFApEuQVUw3ZP69AhwWXk3dgSUsKnuwL5g/ftAY
</span>dEQc8B8jAcnuOrfU
</span>-----END CERTIFICATE REQUEST-----
</span></code></pre>
标签 “NEW CERTIFICATE REQUEST” 也被广泛使用. 符合本文档的生成器必须</strong>生成 “CERTIFICATE REQUEST” 标签. 解析器可以</strong>将 “NEW CERTIFICATE REQUEST” 视为等同于 “CERTIFICATE REQUEST”.</p>
补充内容 2: An Interface and Algorithms for Authenticated Encryption (RFC 5116)</h2>

为了更好地理解 AEAD, 这里提供 RFC5116</a> 的翻译, 供读者参考学习.</p>
</blockquote>
1. 引言</h3>
认证加密 (Authenticated Encryption) 是一种加密形式, 除了为加密的明文提供机密性之外, 还提供了一种检查其完整性和真实性的方法.
带关联数据的认证加密 (Authenticated Encryption with Associated Data), 或简称 AEAD</strong>, 增加了检查某些关联数据 (AD) 的完整性和真实性的能力, 这些关联数据也被称为 “附加认证数据” (AAD</strong>, Additional Authenticated Data), 且未被加密.</p>
2. AEAD 接口</h3>
AEAD 算法具有两种操作: 认证加密和认证解密. 这些算法的输入和输出在下面以八位字节字符串的形式定义.</p>
实现可以</strong>接受额外的输入. 例如, 可以提供一个输入来允许用户在不同的实现策略之间进行选择. 然而, 此类扩展绝不能</strong>影响与其他实现的互操作性.</p>
2.1. 认证加密</h4>
认证加密操作具有四个输入, 每个输入都是一个八位字节字符串:</p>

一个秘密密钥 (secret key</strong>) K, 它必须</strong>以均匀随机或伪随机的方式生成.</li>
一个随机数 (nonce</strong>) N. 对于密钥的任何特定值, 提供给认证加密操作不同调用的每个随机数必须</strong>是不同的, 除非每个随机数都是零长度. 能够生成不同随机数的应用程序必须</strong>使用第 3.2 节中定义的随机数形成方法, 并可以使用任何其他满足唯一性要求的方法. 其他应用程序必须</strong>使用零长度随机数.</li>
一个明文 (plaintext) P, 其中包含要要认证且需要被加密的数据.</li>
关联数据 (associated data) A, 其中包含要认证但不需要被加密的数据.</li>
</ul>

敲黑板: nonce 必须唯一, 但不必保密.</p>
</blockquote>
有一个单一输出:</p>

一个密文 C, 其长度至少与明文一样长, 或者</li>
一个指示请求的加密操作无法执行的指示.</li>
</ul>
所有输入和输出都是可变长度的八位字节字符串, 其长度遵守以下限制:</p>

密钥 K 中的八位字节数在 1 到 255 之间. 对于每个 AEAD 算法, K 的长度必须</strong>是固定的.
对于密钥的任何特定值, 要么 1) 提供给认证加密操作不同调用的每个随机数必须是不同的, 要么 2) 每个随机数必须是零长度. 如果使用零长度随机数与特定密钥一起, 则与该密钥一起使用的每个随机数必须具有零长度. 否则, 随机数的八位字节数应为十二 (12). 可以与特定密钥一起使用不同长度的随机数. 有些算法不能与零长度随机数一起使用, 但其他算法可以; 参见第 4 节. 符合推荐随机数长度的应用程序将避免根据所使用的算法构造不同长度的随机数. 此指导有助于将算法特定逻辑保持在应用程序之外.</li>
明文 P 中的八位字节数可以为零.</li>
关联数据 A 中的八位字节数可以为零.</li>
密文 C 中的八位字节数可以为零.</li>
</ul>
本规范不对随机数、明文、密文或附加认证数据设置最大长度限制. 然而, 特定 AEAD 算法可以进一步限制这些输入和输出的长度. 特定 AEAD 实现可以进一步限制其输入和输出的长度. 如果特定 AEAD 算法的实现被要求处理超出可接受长度范围的输入, 或超出该实现支持的长度范围的输入, 它必须返回错误代码, 并且不得输出任何其他信息. 特别是, 不得返回部分加密或部分解密的数据.</p>
明文 P 同时提供机密性和消息认证. 当 P 的长度为零时, AEAD 算法充当输入 A 的消息认证码.</p>
关联数据 A 用于保护需要认证但不需要保密的信息. 例如, 在使用 AEAD 保护网络协议时, 此输入可以包括地址、端口、序列号、协议版本号以及其他指示如何处理、转发或处理明文或密文的字段. 在许多情况下, 希望认证这些字段, 尽管它们必须保持明文以允许网络或系统正常运行. 当此数据包含在输入 A 中时, 可以在不将数据复制到明文中提供认证.
秘密密钥 K 不得包含在任何其他输入 (N、P 和 A) 中. (此限制并不意味着必须检查这些输入的值以确保它们不包含匹配密钥的子字符串; 相反, 它意味着密钥不得明确复制到这些输入中. )</p>

敲黑板: TLS 里面, TLS Record 的 TLV 结构, 类型和长度是不能加密的, 故作为 AAD.</p>
</blockquote>
随机数在算法内部被认证, 因此没有必要将其包含在 AD 输入中. 如果对应用程序方便, 可以将随机数包含在 P 或 A 中.</p>
随机数可以与密文一起存储或传输, 或者可以在认证解密操作之前立即重建. 只需向解密模块提供足够的信息以允许其构造随机数即可. (例如, 系统可以使用特定格式的序列号作为随机数, 在这种情况下, 可以从密文的顺序推断出来.) 由于认证解密过程会检测不正确的随机数值, 如果随机数被不正确重建并输入到认证解密操作中, 不会导致安全失败. 任何随机数重建方法都需要考虑加密和解密过程之间密文丢失或重新排序的可能性.</p>
应用程序不得假设密文的任何特定结构或格式.</p>
2.2. 认证解密</h4>
认证解密操作具有四个输入: K、N、A 和 C, 如上定义. 它只有一个单一输出, 要么是明文值 P, 要么是一个特殊符号 FAIL, 表示输入不是认证的. 当使用输入 K、N、P 和 A 通过加密操作生成 C (对于 N、P 和 A 的某些值) 时, 密文 C、随机数 N 和关联数据 A 对于密钥 K 是认证的. 认证解密操作将以高概率返回 FAIL, 只要输入 N、P 和 A 是由遵守随机数的对手精心制作的, 且该对手不知道秘密密钥(假设 AEAD 算法是安全的).</p>
2.3. 数据格式</h4>
本文档未指定 AEAD 输入和输出的任何特定编码, 因为编码不影响 AEAD 算法提供的安全服务.</p>
在选择应用程序数据格式时, 应用程序应将密文 C 放置在认证解密操作的其他输入所需的任何其他数据之后. 例如, 如果随机数和密文都出现在数据包中, 前者应先于后者. 此规则有助于 AEAD 算法的高效和简单的硬件实现.</p>
3. AEAD 算法的使用指导</h3>
本节提供必须遵循的建议, 以安全地使用 AEAD 算法.</p>
如果应用程序无法满足随机数生成的唯一性要求, 则它必须使用零长度随机数. 下面定义的随机化或有状态算法适合与此类应用程序一起使用. 否则, 应用程序应使用长度为十二个八位字节的随机数. 由于鼓励算法支持该长度, 应用程序应使用该长度以辅助互操作性.</p>
3.1. Nonce 生成要求</h4>

略, 简要总结: 重复使用 nonce 会有严重的安全问题, 具体因特定 AEAD 算法而异; nonce 必须唯一, 但不必保密, 可以将 nonce 直接附加在密文前面, 又或者像 TLS 那样, 通过握手协商出一个初始值, 然后每次加密时依据顺序号生成.</p>
</blockquote>
3.2. 推荐的 Nonce 构造方法</h4>
(略)</p>
4. AEAD 算法规范要求</h3>
每个 AEAD 算法必须只接受固定密钥长度 K_LEN 的密钥, 并且不得要求所提供的密钥具有任何特定的数据格式. 需要这种结构 (例如, 包含特定奇偶校验格式子密钥的算法) 的算法将需要在内部提供它.</p>
每个 AEAD 算法必须接受长度在零到 P_MAX Bytes (含零和 P_MAX) 之间的任何明文, 其中 P_MAX 值是该算法特有的. P_MAX 的值必须大于零, 并且应至少为 65536 (2^16) Bytes. 此大小是网络数据包的典型上限. 其他应用程序可能使用更大的 P_MAX 值,  因此通用算法支持更高的值是可取的.</p>

某些 AEAD 算法存在 “漏洞”, 一旦发送了一定数量的消息, 它们就不再安全, 为此, TLS 1.3 引入了 KeyUpdate 机制.</p>
</blockquote>
每个 AEAD 算法必须接受长度在零到 A_MAX Bytes (含零和 A_MAX) 之间的任何关联数据,  其中 A_MAX 值是该算法特有的. A_MAX 的值必须大于零, 并且应至少为 65536 (2^16) Bytes. 其他应用程序可能使用更大的 A_MAX 值,  因此通用算法支持更高的值是可取的.</p>
每个 AEAD 算法必须接受长度在 N_MIN 和 N_MAX Bytes (含 N_MIN 和 N_MAX) 之间的任何随机数 (nonce), 其中 N_MIN 和 N_MAX 的值是该算法特有的. N_MAX 和 N_MIN 的值可以相等. 每个算法应接受长度为 12 Bytes 的随机数. 下面描述的随机化或有状态算法的 N_MAX 值可以为零.</p>
AEAD 算法可以以任何方式构造其密文输出; 例如, 密文可以包含一个认证标签. 每个算法都应选择一种有利于高效处理的结构.
认证加密算法可以包含或使用随机源, 例如, 用于生成包含在密文输出中的内部初始化向量. 这种 AEAD 算法被称为随机化算法; 但请注意, 只有加密是随机的, 而解密始终是确定性的. 随机化算法的 N_MAX 值可以为零.</p>
认证加密算法可以包含在加密操作的调用之间维护的内部状态信息, 例如, 允许构造用作算法内部随机数的不同值. 这种 AEAD 算法被称为有状态算法. 即使应用程序输入零长度随机数, 此方法也可以用于算法以提供良好的安全性. 有状态算法的 N_MAX 值可以为零.</p>
AEAD 算法的规范必须包含上面定义的 K_LEN、P_MAX、A_MAX、N_MIN 和 N_MAX 值. 此外, 它必须指定最大可能密文的八位字节数, 我们将其表示为 C_MAX.</p>
每个 AEAD 算法必须提供一个描述, 说明明文长度与密文长度之间的关系. 这种关系不得依赖于外部参数, 例如认证强度参数 (例如, 认证标签长度). 这种依赖性会通过创建一种情况来使算法的使用复杂化, 即 AEAD 注册表中的信息不足以确保互操作性.</p>
每个 AEAD 算法规范应描述由于意外重复使用随机数值而导致的安全降级.</p>
每个 AEAD 算法规范应提供详细安全分析的参考文献. 本文档未指定特定的安全模型, 因为文献中已使用了几种不同的模型. 安全分析应定义或引用一个安全模型.</p>
如上所述, 随机化或有状态的算法应使用这些术语来描述自己.</p>
5. AEAD 算法</h3>
(以下简要总结, 不再翻译原文)</p>
K_LEN</th> P_MAX</th> A_MAX</th> N_MIN</th> N_MAX</th> C_MAX</th></tr></thead>

密钥长度</td> 明文最大长度</td> AAD 最大长度</td> Nonce 最低长度</td> Nonce 最大长度</td> 密文最大长度</td></tr>
</tbody></table>
单位均为 Bytes (即 <&[u8]>::len</code>).</p>
5.1. AES-128-GCM</h4>
K_LEN</th> P_MAX</th> A_MAX</th> N_MIN</th> N_MAX</th> C_MAX</th></tr></thead>

16</td> 2^36 - 31</td> 2^61 - 1</td> 12</td> 12</td> 2^36 - 15</td></tr>
</tbody></table>

对于 GCM, C.len = P.len + 16, 多出来的 16 Bytes 是认证标签.</p>
</blockquote>
GCM 模式下, 加密操作重复使用 nonce 值会严重削弱安全性, 必须保证 nonce 的唯一性.</p>
5.2. AES-256-GCM</h4>
除 K_LEN 为 32 Bytes 外, 其他均与 AES-128-GCM 相同.</p>
5.3. AES-128-CCM</h4>
K_LEN</th> P_MAX</th> A_MAX</th> N_MIN</th> N_MAX</th> C_MAX</th></tr></thead>

16</td> 2^24 - 1</td> 2^64 - 1</td> 12</td> 12</td> 2^24 + 15</td></tr>
</tbody></table>

对于 CCM, C.len = P.len + 16, 多出来的 16 Bytes 是认证标签.</p>
</blockquote>
CCM 模式下, 加密操作重复使用 nonce 值会严重削弱安全性, 必须保证 nonce 的唯一性.</p>
5.4. AES-256-CCM</h4>
除 K_LEN 为 32 Bytes 外, 其他均与 AES-128-CCM 相同.</p>
5.5. (非 RFC 5116 所列, 此处简要补充) Chacha20-Poly1305 (RFC 8439)</h4>
K_LEN</th> P_MAX</th> A_MAX</th> N_MIN</th> N_MAX</th> C_MAX</th></tr></thead>

32</td> 274,877,906,880 (2^38 - 64)</td> 2^64 - 1</td> 12</td> 12</td> 274,877,906,896 (2^38 - 48)</td></tr>
</tbody></table>

C.len = P.len + 16, 多出来的 16 Bytes 是认证标签.</p>
</blockquote>
类似地, 加密操作重复使用 nonce 值会严重削弱安全性, 必须保证 nonce 的唯一性.</p>
5.6. (非 RFC 5116 所列, 此处简要补充) XChacha20-Poly1305 (draft-irtf-cfrg-xchacha-03)</h4>

XChacha20 是 Chacha20 的变种, 使用 192-bit (24 Bytes) 的 nonce.</p>
</blockquote>
K_LEN</th> P_MAX</th> A_MAX</th> N_MIN</th> N_MAX</th> C_MAX</th></tr></thead>

32</td> ~2^80 (TBD)</td> 2^64 - 1</td> 24</td> 24</td> ~2^80 (TBD)</td></tr>
</tbody></table>

C.len = P.len + 16, 多出来的 16 Bytes 是认证标签.</p>
</blockquote>
类似地, 加密操作重复使用 nonce 值会严重削弱安全性, 必须保证 nonce 的唯一性.</p>
6. IANA Considerations</h3>
(略)</p>
7. 其他考虑</h3>
可以使用 encrypt-then-MAC</code> (加密后 MAC) 策略组合加密算法和消息认证码算法提供 AEAD.</p>
(其余略)</p>

小结</h2>
阅读完本文, 我们应当已经熟悉了对称加密和非对称密码学(公钥密码学)的基本概念, 以及下面这些术语:</p>

RSA 公钥密码系统</li>
ECC 公钥密码系统</li>
</ol>
使用到的椭圆曲线: Curve25519 / Ed25519, Curve448 / Ed448 等</p>

X25519 (ECDH) / X448 (EdDH).</li>
ECDSA</li>
EdDSA (Ed25519 / Ed448).</li>
</ul>
此外, 我们还应熟悉 PEM 格式下证书、公私钥的文本编码方式, 以及其与 DER 的关系.</p>
再有, 我们应当熟悉 AEAD 算法基本流程, 了解 AAD, nonce 的概念与作用, 熟记常用的 AEAD 算法, 铭记对于绝大多数 (本文所列全部) AEAD 算法来说, nonce 必须唯一.</p>


从零开始了解 TLS 1.3 系列笔记 (五) —— 实用密码学之「密钥交换, Diffie–Hellman 与后量子加密」
2025-09-16T00:00:00+00:00
导语</h2>
在密码学中, 密钥建立 (key establishment)</a>, 或称密钥交换</strong> (key exchange, KE), 是一个过程或协议. 通过该过程或协议, 通信双方共享密钥.</p>
密钥交换过程一定基于公私钥加密, 也就是非对称加密, 我们将在后续章节详细介绍.</p>
密钥交换可以分为两类:</p>


在密钥协商</strong>中, 双方都对密钥的生成做出贡献, 因此没有一方能单独决定最终的密钥.</p>
如 Diffie-Hellman 密钥交换协议 (DH), 或 ECDH (Elliptic-Curve DH, 椭圆曲线 DH). 大多数不严谨的场景, 密钥交换和密钥协商指的是一件事.</p>
</li>

在密钥传输</strong>中, 一方生成密钥并将其传输给另一方.</p>
如 RSA 密钥交换过程, 一方通过私钥加密随机会话密钥, 并将其发送到另一方, 另一方使用相应公钥将其解密.</p>
由于此过程是静态的, 高度依赖 RSA 的安全性, 在 TLS 1.3 中已被弃用, 即便是 TLS 1.2 中也不推荐使用.</p>
</li>
</ol>
通过密码学设计, 密钥交换方案 (Key exchange schemes) 允许通信双方安全地交换加密密钥, 通常这个过程发生在加密通讯开始时, 例如在 TLS 握手阶段.</p>
大体上, 密钥协商可以基于匿名(无认证</strong>)的密钥交换协议 (如 DH), 密码或预共享密钥 (pre-shared key, PSK), 数字证书或许多元素的组合. 某些通信协议仅建立并从头到尾使用同一个共享密钥, 而另一些通信协议随着时间的流逝不断更改共享密钥.</p>

小贴士</p>
由于密钥交换协议自身是匿名的, 密钥协商在一些需要消息完整性的场景 (如 TLS) 会配合签名算法组成最终的加密方案, 如 TLS 1.2 的加密套件有 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384</code>, 即:</p>

ECDHE: Ephemeral ECDH, 密钥交换方案;</li>
ECDSA: 数字签名方案;</li>
AES-256-GCM: 对称加密方案;</li>
SHA384: 消息摘要算法.</li>
</ul>
这里超前提一下, 后面会继续介绍相关内容.</p>
</blockquote>
Diffie-Hellman 密钥交换 (DHKE)</h2>
DHKE 是最早的公钥协议之一, 允许两个没有事先了解的当事方在不安全的渠道上安全地交换共享密钥. 请注意, DHKE 可以对抗嗅探攻击 (即直接读取数据包), 但无法对抗中间人攻击 MitM (无认证, 中间人可以冒充).</p>
DHKE 的实现包括经典的基于离散对数的 DH, 和基于椭圆曲线的 ECDH.</p>
从混合颜色解释</h3>

  
</p>
这是来自维基百科的一幅经典图片, 利用混合颜色来解释 DH 的工作原理:</p>

Alice 和 Bob 公开同意使用黄色;</li>
Alice 选择一个秘密的红色, 并将其与黄色混合, 得到橙色;</li>
Bob 选择一个秘密的海洋绿色, 并将其与黄色混合, 得到浅天蓝色;</li>
Alice 和 Bob 交换他们混合后的颜色, 我们依然假设混合颜色难以分离出原始颜色;</li>
Alice 将 Bob 交换过来的浅天蓝色与她的秘密颜色混合, 得到黄褐色;</li>
Bob 将 Alice 交换过来的橙色与他的秘密颜色混合, 也得到黄褐色;</li>
</ol>
到此, Alice 和 Bob 都得到了相同的颜色, 即共享密钥, 而中间人 Eve 只能看到黄色, 橙色和浅天蓝色, 无法计算出黄褐色.</p>
经典 DH</h3>
对于传统基于离散对数的 DH, 其过程类似于前面的颜色混合解释.</p>
首先介绍一点数学背景知识:</p>

模幂: 是指求 $g$ 的 $a$ 次幂模 $p$ 的值 $c$ 的过程, 记作 $c = g^a \mod p$, 其中 $p$ 是一个质数;</li>
离散对数, 即模幂的逆运算, 是指已知 $g$, $p$, $c$, 求 $a$ 的过程</li>
模幂运算律: $g^{ab} \mod p = {(g^a \mod p)}^b \mod p$</li>
</ol>
模幂过程计算非常快, 然而离散对数求解被认为在 $p$ 足够大的情况下是在现有计算能力下无法完成的, 此即离散对数难题</strong> (discrete logarithm problem, DLP). 经典的 DHKE 就是基于 DLP 设计的.</p>
那么类似地就有 DHKE 的过程:</p>

Alice 和 Bob 公开同意使用一个大质数 $p$ 和一个生成元 $g$ (通常 $g$ 是 2 或 5, 不需要很大), 在代码层面是写死的;</li>
Alice 选择一个秘密整数 $a$, 并计算 $A = g^a \mod p$, 将 $A$ 发送给 Bob;</li>
Bob 选择一个秘密整数 $b$, 并计算 $B = g^b \mod p$, 将 $B$ 发送给 Alice;</li>
Alice 收到 $B$ 后, 计算共享密钥 $S_1 = B^a \mod p$;</li>
Bob 收到 $A$ 后, 计算共享密钥 $S_2 = A^b \mod p$;</li>
</ol>
由模幂的运算律可以找到 $S_1 = S_2$, 即 Alice 和 Bob 都得到了相同的共享密钥 $S$; 而中间人获得 $A$ 和 $B$ 后, 只能通过离散对数求解 $a$ 或 $b$.</p>
在最常见的 DHKE 实现中 (RFC 3526), 基数是 $g = 2$, 模数 $p$ 是一个 1536 到 8192 比特的大质数. 而整数 $A$ $B$ 通常会使用非常大的数字以防范暴力破解. 对于这种离散对数问题 (DLP), 目前还不存在有效的算法.</p>
ECDH</h3>
ECDH 应用椭圆曲线代替了 DH 中的模幂.</p>
我们依然有运算律:</p>
$$(a * G) * b = (b * G) * a$$</p>
其中 $a, b$ 为常数, $G$ 为椭圆曲线上的某一点的坐标 $(x, y)$.</p>
类似地有 ECDH 的过程:</p>

Alice 和 Bob 公开同意使用一个椭圆曲线和基点 $G$;</li>
Alice 生成一个随机的 ECC 密钥对: $A = a * G$, 将公钥 $A$ 发送给 Bob;</li>
Bob 生成一个随机的 ECC 密钥对: $B = b * G$, 将公钥 $B$ 发送给 Alice;</li>
Alice 收到 $B$ 后, 计算共享密钥 $S_1 = a * B$;</li>
Bob 收到 $A$ 后, 计算共享密钥 $S_2 = b * A$</li>
</ol>
显然, $S_1 = S_2$, 即 Alice 和 Bob 都得到了相同的共享密钥 $S$, 而私钥 $a$, $b$ 的安全性, 则类似地由 ECDLP 问题提供保证, 即「通过公开的 $kG$ 以及 $G$ 这两个参数, 目前没有有效的手段能快速求解出 $k$ 的值. 」</p>
示例</h4>

如果读者还是对 (EC)DH 感到陌生, 相信 X25519 这个名字会更熟悉一些, 这是 TLS 1.3 中最常用的密钥交换算法.</p>
以下内容参考自 深入理解 X25519</a>, 在此表示感谢.</p>
</blockquote>
Curve25519 是一种椭圆曲线, 由 Daniel J. Bernstein 在 2005 年设计, 其设计目标是提供高安全性和高性能的椭圆曲线密码学 (ECC) 操作. Curve25519 的名称来源于其使用的素数 $2^{255} - 19$, 该素数定义了曲线所在的有限域. 而 X25519 是基于 Curve25519 的密钥交换协议, 具体来说, X25519 是一种椭圆曲线 Diffie-Hellman (ECDH) 密钥交换协议的实现. 关于 ECC 公钥密码学的更详细内容, 我们将在下一章介绍.</p>
值得记忆的常识:</p>

X25519 协议对应的私钥是 32 字节.</li>
X25519 协议对应的公钥是 32</strong> 字节.</li>
</ol>
DHE (Diffie-Hellman Ephemeral, 临时 DH)</h3>
前面介绍的经典 DH 与 ECDH 协议流程, 都是在最开始时交换一次密钥, 之后就一直使用该密钥通讯. 因此如果密钥被破解, 整个会话的所有信息对攻击者而言就完全透明了.</p>
为了进一步提高安全性, 密码学家提出了「完全前向保密 (Perfect Forward Secrecy, PFS)」的概念, 并在 DHKE 与 ECDH 的基础上提出了支持 PFS 的 DHE / ECDHE 协议.</p>
PFS 是指长期使用的主密钥泄漏不会导致过去的会话密钥泄漏, 从而保护过去进行的通讯不受密码或密钥在未来暴露的威胁.</p>
DHE / ECDHE 协议的流程与前面介绍的 DH / ECDH 类似, 但每次通讯时都会重新生成一对密钥对, 计算出新的共享密钥随密文发送供下一轮使用. 这样即使某次会话的密钥被破解, 也不会影响到之前或之后的会话.</p>
(一个小问题: 如果能破解一次, 那么破解下一次应该也不难了?</del>)</p>
量子计算机的影响</h3>
在量子计算机面前, DLP 可以通过 Shor 算法解决, 因此 DH 和 ECDH 在量子计算机面前不再安全. 值得庆幸的是, 当前量子计算机还远未达到能破解这些加密算法的规模, 但从长远来看, 我们需要考虑量子安全的密钥交换算法.</p>
后量子密码学 (Post-Quantum Cryptography, PQC) 应用: 混合密钥交换 (Hybrid Key Exchange)</h2>

相信读者一定提到过 X25519MLKEM768, X25519Kyber768Draft00 这样的名字, 这是 TLS 1.3 中的混合密钥交换方案, 本节简要介绍.</p>
</blockquote>
前面提到, 量子计算机的出现对 (EC)DH 的密码学安全保证构成威胁, 因此需要考虑量子安全的密钥交换算法. 目前, NIST 在 FIPS. 203</a> 中标准化了 ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, 基于模格的密钥封装机制), 各大厂商亦跟进用之替代了先前测试阶段的 Kyber (ML-KEM 的前身).</p>
在介绍混合密钥交换之前, 先简要介绍一下 KEM.</p>
KEM (Key Encapsulation Mechanism, 密钥封装机制)</h3>
如其名, 密钥封装机制核心就是对密文的封装 (encapsulate) 与解封装 (decapsulate), 示意图如下:</p>

  
</div>
主要流程为:</p>

Alice 生成一对公私钥 $(pk, sk)$, 并将公钥 $pk$ 发送给 Bob; 公钥也称封装密钥 (encapsulation key), 私钥也称解封装密钥 (decapsulation key);</li>
Bob 使用公钥 $pk$ 执行 Encaps 操作, 获得一个密钥和关联的封装密文</strong>; Bob 将关联密文发送给 Alice, 密钥则作为共享密钥使用;</li>
Alice 使用私钥 $sk$ 对关联密文执行 Decaps 解封装操作, 获得共享密钥;</li>
</ol>
到此, Alice 和 Bob 得到了相同的共享密钥.</p>
而 ML-KEM 是 KEM 中的一种, 其安全性基于模格 (Module-Lattice) 问题, 目前已知的量子计算机无法有效解决.</p>
稍微跑题, 还有 ML-DSA, 作为数字签名算法 (DSA), 应用于 TLS 证书验证模块 (draft-ietf-tls-mldsa).</p>
TLS 1.3 中的混合密钥交换</h3>
(也许是)出于兼容性考虑, 目前 TLS 1.3 中的后量子密钥交换方案均以混合密钥交换的形式出现.</p>
感谢 @jschauma 总结的一图流</a>,  (图示为 X25519Kyber768, 但其他的基于 ML-KEM 的混合密钥交换方案也是类似的流程):</p>

  
</div>
简单地来说, 就是在原 (EC)DH 的基础上, 额外增加了 KEM 的公钥交换与密文交换过程: 客户端将 PQC 公钥拼接在客户端向服务端共享的 (EC)DH 公钥后, 服务端将封装密文拼接在服务端向客户端共享的 (EC)DH 公钥后, 双方最终将通过 (EC)DH 得到的共享密钥与 KEM 拿到的或解封装出来的共享密钥拼接起来, 就得到了最终的共享密钥, 是不是非常简单粗暴呢.</p>

碎碎念</p>
后量子算法的引入, 直接导致 ClientHello 消息体积暴增, 如 X25519MLKEM768, 会额外多出 32 字节的用于回落的 X25519 公钥, 以及 1184 字节的 ML-KEM-768 的公钥, 加上原有的 500 字节左右, 大概是 1700 字节左右, 已经超过了 IPv4 TCP 最大 MSS (1500 - 20 - 20 = 1460 Bytes) 导致需要分包, 一旦丢包, 握手延迟蹭蹭涨.</p>

 
</div>
即便使用纯 PQC, 也只是堪堪减少 32 Bytes, 于事无补.</p>
</blockquote>

小结</h2>
读完本文, 我们应该已经熟悉以下术语及相应的流程:</p>

密钥交换 (Key Exchange, KE)</li>
密钥协商</strong> (Key Agreement)</li>
密钥传输 (Key Transport)</li>
Diffie-Hellman (DH</strong>)</li>
椭圆曲线 Diffie-Hellman (ECDH</strong>)

Curve25519, X25519</strong></li>
secp256r1 (NIST P-256</strong>), etc.</li>
</ul>
</li>
临时 Diffie-Hellman (DHE</strong>)</li>
完全前向保密 (Perfect Forward Secrecy, PFS)</li>
后量子安全; 密钥封装机制 (Key Encapsulation Mechanism, KEM)

ML-KEM (Module-Lattice-based KEM)</li>
</ul>
</li>
混合密钥交换 (Hybrid Key Exchange)</li>
</ul>


从零开始了解 TLS 1.3 系列笔记 (四) —— 实用密码学之「HMAC、HKDF 与安全随机数」
2025-09-15T00:00:00+00:00
导语</h2>
MAC (Message Authentication Code, 消息认证码)、HMAC (Hash-based MAC, 哈希消息认证码)和 KDF (Key Derivation</strong> Function, 密钥派生</strong>函数) 在密码学中发挥着重要作用. 让我们解释一下何时需要 MAC, 如何计算 HMAC 以及它与 KDF 的关系.</p>
MAC</h3>
MAC 由给定密钥和消息计算而来:</p>
MAC = f(key, message)
</span></code></pre>
通常, 它的表现类似于加密哈希函数:</p>

难以分析</strong>: 密钥或消息的微小变化会生成完全不同的 MAC 值.</li>
不可逆</strong>: 从其哈希值逆向演算出输入值应该是不可行的. 这意味着没有比暴力破解更好的破解方法.</li>
抗碰撞</strong>: 几乎不可能找到具有相同哈希值的两条不同消息.</li>
</ul>
例如, MAC 码可以通过 HMAC-SHA256 算法计算, 如下所示:</p>
HMAC-SHA256('key', 'some msg') = 32885b49c8a1009e6d66662f8462e7dd5df769a7b725d1d546574e6d5d6e76ad
</span></code></pre>
MAC 码是数字真实性代码</em> (digital authenticity code), 类似于数字签名 (digital signature), 但具有预共享密钥 (pre-shared key).</p>
MAC 算法</h3>
包括但不限于:</p>

HMAC</a> (Hash-based MAC, 哈希消息认证码), 如 HMAC-SHA256;</li>
KMAC</a> (Keccak-based MAC, 基于 Keccak 的消息认证码);</li>
基于对称密码算法的 MAC, 如 Poly1305</strong></a> (Bernstein 一次性身份验证) 等等.</li>
其他, 如 SipHash</a> (一种快速的、加密的哈希函数, 适用于哈希表).</li>
</ul>
MAC 主要应用</h3>
MAC 码主要用于验证消息未被篡改. 如当通信双方持有相同的共享密钥时, 发送方可以计算消息的 MAC 码并将其附加到消息中; 接收方收到消息后, 使用相同的密钥计算消息的 MAC 码, 并将其与附加的 MAC 码进行比较; 如果两个 MAC 码匹配, 则消息被认为是完整且未被篡改的.</p>
认证加密 (Authenticated Encryption, AE)</h3>
使用 MAC 码的另一种场景是认证加密.</p>
加密方:</p>

首先, 我们派生一密钥.</li>
使用该密钥加密消息.</li>
使用该密钥和原始消息</strong>计算 MAC 码, 并将其附加到第二步的输出中.</li>
</ol>
接收方:</p>

使用一密钥解密密文, 此密钥并不一定是正确的.</li>
使用该密钥和解密结果计算 MAC 码, 并将其与附加的 MAC 码进行比较; 如果两个 MAC 码匹配, 则密钥一致, 解密成功且密文未被篡改; 否则, 密钥不正确或密文被篡改.</li>
</ol>

背景知识</p>
可能大家并不熟悉 AE 这个术语, 但 AEAD (Authenticated Encryption with Associated Data, 带关联数据的认证加密) 应该就是熟面孔了. AEAD 是 AE 的一种扩展, 允许在认证加密过程中包含未加密的关联数据 (Associated Data, AD), 如路由信息等需要中间盒处理的信息. 例如, TLS 1.3 中使用的 AES-{128|256}-GCM 和 ChaCha20-Poly1305 都是 AEAD 加密方案, 我们将在介绍对称加密方案时再提到.</p>
</blockquote>
由此, 我们同时验证了通信双方持有相同的共享密钥 (即认证, AE 代表 Authenticated Encryption, 经过认证的加密), 以及消息未被篡改 (完整性).</p>
基于 MAC 的伪随机生成函数 (PRF, Pseudo-Random Function)</h3>
MAC 码的另一个应用是作 PRF. 我们可以从某个盐和一个随机数(种子)开始.我们可以计算 next_seed</code> 如下:</p>
next_seed = MAC(salt, seed)
</span></code></pre>
每次计算上述公式后, 下一个伪随机数都会被 “随机变化”, 我们可以用它来生成一定范围内的下一个随机数.</p>
HMAC 和密钥派生</h2>
简单计算 MAC = H(key || msg)</code> 来获取 MAC 被认为是不安全的</a>. 建议改用 HMAC 算法, 例如 HMAC-SHA256.</p>

背景知识</p>

大多数哈希函数存在长度拓展攻击, 即在不知道密钥的情况下, 可以通过已知的 H(key || msg)</code> 来计算有效的 H(key || msg || extra)</code>;</li>
计算 MAC = H(msg || key)</code>, 则存在哈希冲突的可能性;</li>
计算 MAC = H(key || msg || key)</code> 仍然被证明是不安全的;</li>
HMAC 计算 HMAC = H(key || H(key || msg))</code>, 采用双重哈希, 消除 msg 长度影响, 目前尚未被证明不安全; 对于 SHA-3 (Keccak) 则不需要双重哈希, 只需 HMAC = H(key || msg)</code>, 因为 SHA-3 不易受长度拓展攻击.</li>
</ol>
</blockquote>
什么是 HMAC</a></h3>
HMAC (Hash-based Message Authentication Code, 哈希消息认证码) 是一种基于哈希函数的 MAC 算法. 它使用一个密钥和一个消息, 通过两次哈希计算得到 MAC 码.</p>
$$\operatorname {HMAC} (K,m)=\operatorname {H} {\Bigl (}{\bigl (}K’\oplus opad{\bigr )}\parallel \operatorname {H} {\bigl (}\left(K’\oplus ipad\right)\parallel m{\bigr )}{\Bigr )}$$</p>
其中:</p>

$\operatorname {H}$ 是 HMAC 过程所使用的加密哈希函数, 如 SHA-256;</li>
$m$ 是消息;</li>
$K$ 是一个密钥;</li>
$K’$ 是密钥 $K$ 经过右侧补 0 填充或哈希后(必要时右侧补 0)的结果, 以确保其长度等于哈希函数的块大小 (block size);</li>
$ipad$ 和 $opad$ 分别是内填充 (inner padding) 和外填充 (outer padding), 长度与块大小相同, 分别由值为 0x5c, 0x36 的重复字节组成;</li>
$\oplus$ 表示按位异或 (XOR) 操作;</li>
$\parallel$ 表示拼接.</li>
</ul>
HMAC 用于验证消息真实性和完整性, 有时还用于密钥派生.</p>
KDF</h3>
KDF (Key Derivation Function, 密钥派生函数) 是一种将可变长度密码转换为固定长度密钥的函数:</p>
key = KDF(password)
</span></code></pre>
我们可以使用 SHA-256 对密码进行哈希处理, 使用哈希值作密钥, 这就是一个简单的 KDF. 但请不要这样做, 因为它不安全: 简单哈希容易受到字典攻击 (查表法).</p>
为此, 我们可以引入盐 (salt) 执行 HMAC 操作, 此即 HKDF</strong> (HMAC-based KDF), 具体内容见下文.</p>
使用 HKDF 进行密钥派生不如现代 KDF 安全, 如 PBKDF2, Bcrypt, Scrypt, Argon2 等.</p>
KDF: 从密码(或密钥)派生密钥</h2>
PBKDF2, Bcrypt, Scrypt, Argon2 等 KDF 函数, 通过引入盐并结合多次迭代来增加密码破解的难度, 迭代过程也称 key stretching (密钥拉伸)</a>.</p>
要计算安全的 KDF, 需要一些 CPU 时间来派生密钥 + 一些内存. 因此, 派生密钥是计算成本高昂的, 因此密码破解的尝试也会面临高昂计算成本.</p>
当现代 KDF 与适当的配置参数一起使用时, 破解密码的速度会很慢 (例如, 每秒只能作 5-10 次尝试, 而不是每秒数千或数百万次尝试).</p>
上述现代 KDF 均未申请专利, 可公开使用.</p>
由于本系列主要介绍 TLS 1.3, 因此不再赘述现代 KDF 的细节 (我们只用到了 HKDF), 有兴趣的读者可参考 Practical Cryptography for Developers Book</a>. 下一节对 HKDF 的介绍, 主要翻译自 RFC 5869</a>.</p>
HKDF (RFC 5869)</h2>
本文档规定了一个简单的基于 HMAC 的 KDF, 它可以作为各种协议和应用程序中的 (加密) 组件. KDF 旨在支持广泛的应用程序和需求, 并在使用加密哈希函数方面是保守的.</p>
1. 引言</h3>
KDF 是加密系统的基本和必要组件. 其目标是获取一些初始密钥材料源, 并从中派生出一个或多个具备强加密强度的密钥.</p>
本文档规定了一个简单的基于 HMAC 的 KDF, 名为 HKDF, 它可以作为各种协议和应用程序中的 (加密) 组件, 并且已经在几个 IETF 协议中使用, 包括 IKEv2、PANA 和 EAP-AKA. 本文档旨在以通用化的方式, 促进其在未来协议和应用中的采纳, 并防止多种 KDF 机制的无序发展. 它不是要求更改现有协议的呼吁, 也不会更改或更新使用此 KDF 的现有规范.</p>
HKDF 遵循 “提取然后扩展” (extract-then-expand) 的范式, 其中 KDF 在逻辑上由两个模块组成. 第一阶段获取输入密钥材料并从中 “提取” 固定长度的伪随机密钥 K. 第二阶段将密钥 K “扩展” 为几个额外的伪随机密钥 (KDF 的输出).</p>
在许多应用程序中, 输入密钥材料不一定均匀分布, 攻击者可能对其有部分了解 (例如, 由密钥交换协议计算的 Diffie-Hellman 值), 甚至对其有部分控制 (如在一些熵收集应用程序中). 因此, “提取” 阶段的目标是将输入密钥材料可能分散的熵 “集中” 到一个短而高强度的伪随机密钥</strong> (pseudorandom key, PRK</strong>) 中. 在一些应用程序中, 输入可能已经是一个良好的 PRK; 在这些情况下, “提取” 阶段不是必需的, “扩展” 部分可以单独使用. 第二阶段, 将伪随机密钥 “扩展” 到所需长度; 输出密钥的数量和长度取决于需要密钥的特定加密算法.</p>
请注意, 一些现有的 KDF 规范要么只考虑第二阶段, 要么没有明确区分 “提取” 和 “扩展” 阶段, 经常导致设计缺陷. 本规范的目标是适应广泛的 KDF 需求, 同时最小化对底层哈希函数的假设. 提取然后扩展“ 范式很好地支持了这一目标.</p>
2. HKDF</h3>
2.1. 符号系统</h4>
HMAC-Hash 表示使用哈希函数 “Hash” 的 HMAC 函数. HMAC 始终有两个参数: 第一个是密钥, 第二个是输入(或消息). (请注意, 在提取步骤中,  IKM 用作 HMAC 输入, 而不是 HMAC 密钥.)</p>
当消息由多个元素组成时, 我们在第二个参数中将其串接 (表示为 |); 例如, HMAC(K, elem1 | elem2 | elem3).</p>
本文档中的关键词 “必须” (“MUST” / “SHALL” / “REQUIRED”)、“绝不能” (“MUST NOT” / “SHALL NOT”), “推荐” (“SHOULD” / “RECOMMENDED”)、“不推荐” (“SHOULD NOT” / “NOT RECOMMENDED”), “可以/可能/可选” (“MAY” / “OPTIONAL”) 按照 BCP 14, RFC 2119 中的描述进行解释.</p>
2.2. 第一步: 提取 (extract)</h4>
HKDF-Extract(salt, IKM) -> PRK
</span></code></pre>
可选:</p>

Hash</code>: 用于 HMAC 的哈希函数, HashLen 是其输出长度 (以字节为单位);</li>
</ul>
入参:</p>

salt</code>: 可选的随机盐值 (一个非秘密随机值); 如果未提供, 则将其设置为 HashLen 字节的零值;</li>
IKM</code>: 输入密钥材料 (input key material);</li>
</ul>
输出:</p>

PRK</code>: 输出的长度为 HashLen 字节的伪随机密钥 (pseudorandom key).</li>
</ul>
PRK 由以下公式计算:</p>
PRK = HMAC-Hash(salt, IKM)
</span></code></pre>
2.3. 第二步: 扩展 (expand)</h4>
HKDF-Expand(PRK, info, L) -> OKM
</span></code></pre>
可选:</p>

Hash</code>: 用于 HMAC 的哈希函数, HashLen 是其输出长度 (以字节为单位);</li>
</ul>
入参:</p>

PRK</code>: 伪随机密钥 (pseudorandom key), 长度至少为 HashLen 字节 (通常, 这是由 HKDF-Extract 生成的输出);</li>
info</code>: 可选的上下文和应用程序特定信息 (可以是零长度);</li>
L</code>: 所需输出密钥材料 (output keying material) 的长度 (以字节为单位); L 必须小于或等于 255 * HashLen;</li>
</ul>
输出:</p>

OKM</code>: 输出的密钥材料 (output keying material), 长度为 L 字节;</li>
</ul>
OKM 由以下公式计算:</p>
N = ceil(L/HashLen)
</span>T = T(1) | T(2) | T(3) | ... | T(N)
</span>OKM = first L bytes of T
</span></code></pre>
其中:</p>
T(0) = empty string (zero length)
</span>T(1) = HMAC-Hash(PRK, T(0) | info | 0x01)
</span>T(2) = HMAC-Hash(PRK, T(1) | info | 0x02)
</span>T(3) = HMAC-Hash(PRK, T(2) | info | 0x03)
</span>...
</span></code></pre>
3. HKDF 的使用注意事项</h3>
本节讨论 HKDF 的一些使用注意事项.</p>
3.1. 关于盐 (salt)</h4>
HKDF 被定义为可以在有或没有随机盐值的情况下运行. 这样做是为了适应那些无法获得盐值的应用程序. 然而, 我们强调, 使用盐值可以显著增强 HKDF 的强度, 确保哈希函数不同用途之间的独立性, 支持 “源独立地” 提取, 并强化支持 HKDF 设计的分析结果.</p>
随机盐值与初始密钥材料在两个方面有根本不同: 它不是保密的, 并且可以重复使用. 因此, 许多应用程序都可以应用盐值. 例如, 一个通过将 HKDF 应用于可再生熵池 (例如, 采样的系统事件) 来持续生成输出的伪随机数生成器 (PRNG) 可以固定一个盐值, 并将其用于 HKDF 的多个应用, 而无需保护盐值的秘密性. 在另一个应用领域, 一个从 Diffie-Hellman 交换中导出加密密钥的密钥协商协议可以从通信双方作为密钥协商一部分交换和认证的公开随机数中导出盐值 (这是 IKEv2 中采用的方法).</p>
理想情况下, 盐值是长度为 HashLen 的随机或伪随机字符串. 然而, 即使是质量较低的盐值 (尺寸较短或熵有限) 也可能对输出密钥材料的安全性做出显著贡献; 因此, 鼓励应用程序设计者在应用程序能够获取此类值时, 向 HKDF 提供盐值.</p>
值得注意的是, 虽然不常见, 但某些应用程序甚至可能拥有保密的盐值; 在这种情况下, HKDF 提供了更强的安全保证. 这种应用程序的一个例子是 IKEv1 的 “公钥加密模式”, 其中提取器的 “盐值” 是从秘密随机数计算出来的; 类似地, IKEv1 的预共享模式使用从预共享密钥派生的秘密盐值.</p>
3.2. 关于 info</h4>
尽管 “info” 值在 HKDF 的定义中是可选的, 但它在应用程序中通常非常重要. 其主要目标是将派生密钥材料与应用程序和上下文特定的信息绑定. 例如, “info” 可能包含协议号、算法标识符、用户身份等. 特别是, 它可以防止为不同上下文派生相同的密钥材料 (当在这些不同上下文中使用相同的 IKM 时) . 如果需要, 它还可以容纳密钥扩展部分的额外输入 (例如, 应用程序可能希望将密钥材料与其长度 L 绑定, 从而使 L 成为 info 字段的一部分) . “info” 有一个技术要求: 它应该独立于 IKM.</p>
3.3. 跳过还是不跳过(提取)</h4>
在某些应用程序中, IKM 可能已经作为密码学强度高的密钥存在 (例如, TLS RSA 密码套件中的预主密钥将是一个伪随机字符串, 除了前两个八位字节) . 在这种情况下, 可以跳过提取部分, 直接使用 IKM 作为扩展步骤中的密钥. 另一方面, 为了与一般情况兼容, 应用程序仍可能使用提取部分. 特别是, 如果 IKM 是随机的 (或伪随机的) , 但比 HMAC 密钥长, 则提取步骤可以用于输出一个合适的 HMAC 密钥 (在 HMAC 的情况下, 通过提取器进行这种缩短并非严格必要, 因为 HMAC 也被定义为可以处理长密钥) . 然而, 请注意, 如果 IKM 是 Diffie-Hellman 值, 如同 TLS 与 Diffie-Hellman 的情况, 则不应跳过提取部分. 这样做将导致使用 Diffie-Hellman 值 g^{xy} 本身 (它不是一个均匀随机或伪随机字符串) 作为 HMAC 的密钥 PRK. 相反, HKDF 应该将提取步骤应用于 g^{xy} (最好带有一个盐值) , 并使用生成的 PRK 作为 HMAC 在扩展部分中的密钥.</p>
在所需的密钥位数 L 不超过 HashLen 的情况下, 可以直接将 PRK 截断获得最终的 OKM. 然而, 不推荐这样做, 特别是因为它会省略在派生过程中使用的 “info” (也不建议将 “info” 作为输入添加到提取步骤中) .</p>
3.4. 独立性的作用</h4>
KDF 的分析假设 IKM 来自某个源, 该源被建模为特定长度比特流的概率分布 (例如, 由熵池产生的流, 从随机选择的 Diffie-Hellman 指数派生的值等) ; IKM 的每个实例都是该分布中的一个样本. 密钥派生函数的一个主要目标是确保, 当将 KDF 应用于从 (相同) 源分布中抽取的任意两个值 IKM 和 IKM’ 时, 生成的密钥 OKM 和 OKM’ 在本质上是相互独立的 (在统计或计算意义上) . 为了实现这一目标, KDF 的输入必须从适当的输入分布中选择, 并且输入也必须相互独立选择 (从技术上讲, 即使以 KDF 的其他输入为条件, 每个样本也必须具有足够的熵) .</p>
独立性也是提供给 KDF 的盐值的一个重要方面. 虽然没有必要对盐值保密, 并且同一个盐值可以与多个 IKM 值一起使用, 但假定盐值独立于输入密钥材料. 特别是, 应用程序需要确保盐值不是由攻击者选择或操纵的. 例如, 考虑 (如 IKE 中) 盐值是从密钥交换协议中各方提供的随机数派生的情况. 在协议使用此类盐值派生密钥之前, 它需要确保这些随机数被认证为来自合法方, 而不是由攻击者选择的 (在 IKE 中, 例如, 这种认证是经过认证的 Diffie-Hellman 交换的一个组成部分).</p>
4. HKDF 的应用</h3>
HKDF 旨在用于各种 KDF 应用. 这些应用包括从弱随机性来源获得伪随机性; 在密钥协商协议中从共享的 Diffie-Hellman 值导出加密密钥; 从混合公钥加密方案导出对称密钥; 用于密钥封装机制的密钥导出; 以及更多. 所有这些应用都可以受益于 HKDF 的简洁性和多功能性, 以及其分析基础.</p>
另一方面, 预计某些应用由于特定的操作要求将无法 “按原样” 使用 HKDF, 或者可以使用但无法充分发挥该方案的全部优势. 一个重要的例子是从低熵源 (例如用户密码) 导出加密密钥. HKDF 中的提取步骤可以集中现有熵, 但不能放大熵. 对于基于密码的 KDF, 主要目标是使用两个要素来减缓字典攻击: 一个盐值, 以及有意减慢密钥导出计算. HKDF 自然支持使用盐; 然而, 减速机制并非本规范的一部分. 对基于密码的 KDF 感兴趣的应用应考虑例如 PKCS5 是否比 HKDF 更能满足其需求.</p>
5. 安全注意事项</h3>
尽管 HKDF 组成简单, 但在其设计和分析中已考虑了许多安全因素. 对所有这些方面的阐述超出了本文档的范围.</p>
相关论文已投入大量精力, 对 HKDF 作为一种多用途 KDF 进行了密码学分析, 该分析在利用加密哈希函数的方式上非常谨慎. 鉴于我们对当前哈希函数强度的信心有限, 这一点尤为重要. 然而, 这项分析并不意味着任何方案的绝对安全性, 并且它在很大程度上取决于底层哈希函数的强度和建模选择. 尽管如此, 它有力地表明了 HKDF 设计的正确结构及其相对于其他常见 KDF 方案的优势.</p>
(余下内容略去不译)</p>
安全随机数</h2>
密码学中, 随机性 (熵) 起着非常重要的作用. 在许多算法中, 我们需要随机的 (不可预测的) 数字. 如果这些数字不是不可预测的, 算法就会受到损害.</p>
在计算机科学中, 随机数通常来自伪随机数生成器 (pseudo-random numbers generators, PRNG), 由一些初始随机性初始化, 这些初始随机性一般来自极难预测的用户输入等, 可从操作系统读取, 如 Linux 的 /dev/random</code>;
在密码学中, 使用安全 PRNG, 称为 CSPRNG, 它通常将熵与 PRNG 和其他技术相结合, 使生成的随机性在密码学意义上不可预测.</p>
应当注意, 获取安全随机数的开销通常是比较大的, 而许多语言提供的随机数生成函数并非 CSPRNG (例如 Python 的 random</code> 库), 而是基于时间戳等可预测的种子获得的伪随机数, 不能用于密码学场景.</p>

小结</h2>
本文介绍了 MAC、HMAC、KDF 和 HKDF 的基本概念及其应用. 除却这四个术语外, 以下再摘抄若干术语、表达式供读者快速回顾:</p>

HMAC = H(key || H(key || msg))</code>;</li>
AEAD</code></strong></li>
PRK = HKDF-Extract(salt, IKM)</code></strong>;</li>
OKM = HKDF-Expand(PRK, info, L)</code></strong>;</li>
</ul>
在阅读完本文后, 我们应该对上述表达式及相关术语不再陌生.</p>


从零开始了解 TLS 1.3 系列笔记（三）—— 实用密码学之「哈希函数」
2025-09-14T00:00:00+00:00
前言</h2>
在本章中, 我们将介绍哈希函数的基本概念, 以及常见的安全哈希算法. 哈希函数在 TLS 协议中被广泛使用, 例如在数字签名算法、消息认证码 (MAC) 和密钥派生函数 (KDF) 中都有应用.</p>
哈希函数与加密哈希函数</h2>
在计算机编程中, 哈希函数将输入不可逆地映射到一个整数. 通常不同的输入映射到不同的输出; 在密码学中, 哈希函数将任意大小的输入数据转换为因算法而异的固定大小的结果, 该结果称为哈希值. 计算机密码学中使用的哈希函数称为 “加密哈希函数”.</p>
对于哈希函数, 我们期待不同输入映射到不同输出, 但由于输入空间无限而输出空间有限, 不可避免地会发生冲突 (也称哈希碰撞); 而对于一个合格的加密哈希函数, 我们要求这个冲突的发生概率非常非常低, 以至于在实际应用中可以忽略不计.</p>
一个理想的加密哈希函数应当具有如下特性:</p>

确定性</strong>, 即对同样的输入, 应该总是产生同样的输出;</li>
快速</strong>, 计算速度要足够快;</li>
难以分析</strong>, 即对输入的任何微小改动, 都应该使输出完全发生变化;</li>
不可逆</strong>, 即从其哈希值逆向演算出输入值应该是不可行的, 这意味着没有比暴力破解更好的破解方法;</li>
抗碰撞</strong>, 即几乎不可能找到具有相同哈希值的两条不同消息.</li>
</ul>
现代加密哈希函数, 如 SHA-2 和 SHA-3, 都至少在当前已知的攻击方法下满足上述特性.</p>
加密哈希函数的应用</h2>
加密哈希函数有很多应用, 其中最常见的包括:</p>

数据完整性校验</li>
</ol>
这是加密哈希函数最常见的应用, 此时的哈希值作为 “校验和” (checksum). 例如, 当从互联网下载文件, 下载完毕后计算文件字节流的 SHA256 校验和跟官方公布的一致, 那就说明文件没有损坏.</p>
但需要指出: 哈希函数自身不能保证文件的真实性</strong>, 目前来讲, 从网上下载的文件的真实性通常是 TLS 协议要保证的, 它确保你看到的网站所公布的「SHA256 校验和」是未被篡改的.</p>

密码存储</strong></li>
</ol>
加密哈希函数还被用于密码的安全存储, 以避免因直接存储明文密码、而某日数据库泄露导致密码泄露的问题.</p>
应当使用专门设计的安全哈希算法, 如 Scrypt, 计算用户密码的哈希值再持久化保存. 这种算法往往被设计为 CPU 密集和/或内存密集的, 以及难以并行化的, 提高单次计算的耗时, 以增加暴力破解的成本.</p>

唯一 ID</strong></li>
</ol>
将任意长的文件内容哈希化生成一个定长的唯一的 ID, 用以索引等.</p>

伪随机数生成</strong></li>
</ol>
哈希函数也可以用来生成伪随机数, 例如, 可以将一个随机种子值(从随机事件中收集熵, 如随机的鼠标移动或键盘输入)并附加一个值然后哈希化, 得到一个伪随机数. 可将结果附加一个值再哈希化, 得到另一个伪随机数. Linux 内核的 /dev/urandom</code> 就是基于此原理实现的.</p>

工作量证明 (PoW, Proof of Work) 算法</strong></li>
</ol>
略.</p>
安全哈希算法</h2>
以下简要介绍几种常见的安全哈希算法.</p>
SHA-2</h3>
依据哈希位数, 可分为 SHA-256, SHA-384 和 SHA-512 等若干变体. SHA-2 基于 “Merkle-Damgård 构造” , 目前被认为高度安全.</p>
示例:</p>
SHA-256('hello') = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
</span>SHA-384('hello') = 59e1748777448c69de6b800d7a33bbfb9ff1b463e44354c3553bcdb9c666fa90125a3c79f90397bdf5f6a13de828684f
</span>SHA-512('hello') = 9b71d224bd62f3785d96d46ad3ea3d73319bfbc2890caadae2dff72519673ca72323c3d99ba5c11d7c7acc6e14b8c5da0c4663475c2e5c3adef46f73bcdec043
</span></code></pre>
SHA-3</h3>
比 SHA-2 更安全, 不容易遭受长度扩展攻击</a>; 在 TLS 1.3 中并未使用.</p>
BLAKE2 / BLAKE3</h3>
BLAKE2 / BLAKE3 安全性与 SHA-3 相当, 但针对现代硬件进行高度优化, 哈希速度比 SHA-3 快得多; 在 TLS 1.3 中并未使用.</p>
其他</h3>
如中国的商密系列 SM3 / SM4 等.</p>
不安全的哈希函数</h2>
应当避免使用以下被认为不安全或安全性有争议的的哈希算法: MD2、MD4、MD5、SHA-0、SHA-1、Panama、HAVAL (有争议的安全性, HAVAL-128 发现冲突)、Tiger (有争议, 发现弱点)、SipHash (它不是加密哈希函数).</p>
本章小结</h2>

哈希函数将任意大小的输入数据不可逆地映射为固定大小的结果, 该结果称为哈希值.</li>
加密哈希函数要求映射冲突的发生概率非常低, 以至于在实际应用中可以忽略不计, 保证无法伪造数据和原始数据具备一致的哈希值.</li>
加密哈希函数只能保证数据完整性, 不能保证数据真实性.</li>
现代哈希函数包括 SHA-2, SHA-3, BLAKE2 / BLAKE3 等; 应当避免使用 MD5, SHA-1 等被认为不安全的哈希函数.</li>
</ol>
部分参考文献</h2>

Practical Cryptography for Developers Book</a></li>
</ul>


从零开始了解 TLS 1.3 系列笔记（二）—— 实用密码学之「引言」
2025-09-13T00:00:00+00:00
前言</h2>
TLS 协议是一种密码学实践, 其目标如其名曰 “传输层安全”, 在假设完全不可信的信道上提供安全的通信. 这要求 TLS 协议必须满足以下安全目标:</p>

确保数据不会被中间人获取;</li>
确保数据不被中间人篡改;</li>
确定对端的真实身份, 确保通信双方的身份可信.</li>
</ul>
通俗地说, 我们需要维持消息的机密性</strong> (confidentiality), 以及消息的真实性</strong> (authenticity)、完整性</strong> (integrity) 和不可否认性</strong> (non-repudiation). 为此, TLS 协议使用了大量的密码学算法原语、组件, 如哈希函数, 对称加密算法, 非对称加密算法, 数字签名算法等. 在系统地理解 TLS 协议之前, 我们需要先了解这些密码学基础概念.</p>
什么是密码学</h2>
密码学 (Cryptography) 是提供信息安全和保护</strong>的科学. 它在我们的数字世界中无处不在, 当你打开网站时、发送电子邮件时、连接到 WiFi 网络时, 使用账号密码登录 APP 时、使用二步认证验证码认证身份时, 都有涉及到密码学相关技术.
因此, 开发人员应该对密码学有基本的了解, 以避免写出不安全的代码. 至少也得知道如何使用密码算法和密码库, 了解哈希、对称密码算法、非对称密码算法与加密方案这些概念, 知晓数字签名及其背后的密码系统和算法.</p>
以下密码学基础概念(术语)将在本文以及后续文章中频繁出现, 需要熟悉.</p>

熵 (entropy) 与安全随机数生成器.</li>
哈希函数 (Hash Function, 也称散列函数), 如 MD5, SHA-1, SHA-2 (主要包括 SHA-256, SHA-384, SHA-512 三个变体) 等.</li>
哈希消息认证码 (Hash-based Message Authentication Code, HMAC</strong>), 如 HMAC-SHA-256.</li>
密钥派生函数 (Key Derivation Function, KDF</strong>), 如 Scrypt.</li>
密钥交换</strong>算法 (Key Exchange Algorithm), 如 Diffie-Hellman (DH) 和 ECDH (椭圆曲线 Diffie-Hellman).</li>
对称密钥加密</strong>方案 (Symmetric key encryption schemes), 如 AES-128-GCM.</li>
非对称密钥加密</strong>方案 (Asymmetric key encryption schemes), 如 RSA 和 ECC (elliptic curves-based cryptography, 椭圆曲线密码学).</li>
数字签名算法</strong> (Digital Signature Algorithm, DSA).</li>
后量子</strong> (Post-Quantum) 安全.</li>
</ul>
如果你有过一些开发经验, 可能会很熟悉其中部分名词. 如果不熟也没任何关系, 都会在本系列文章内介绍, 请坐和放宽.</p>
密码学的用途</h2>
熵与安全随机数</h3>
熵 (entropy, 指不可预测的随机性) 是密码学的重要部分, 大量算法的安全性都仰赖于具备足够熵的随机数.</p>
计算机无法产生真正的随机数, 只能从外部获得 “真” 随机性:</p>

Linux 系统下的 /dev/urandom</code> 的随机性来源于硬件中断、按键输入、鼠标移动、磁盘 IO 等不可预测的系统事件;</li>
Cloudflare 使用一面熔岩墙</a> 获得真随机性…</li>
</ol>
区别于真随机性, 通过特定算法从一定的随机性种子 (seed) 生成的随机性我们称之为伪随机性, 伪随机性显然由于随机性种子的来源有高低优劣之分. 密码学操作在需求随机性时, 往往要求使用安全伪随机数生成器 (Cryptographically secure pseudo-random number generator, CSPRNG), 基于具备足够熵的随机性种子生成高质量的伪随机数: 通过 CSPRNG 生成的随机数即便攻击者在统计学意义上能收集大量过往产生的随机数进行分析, 或者计算上通过特定手段探知得 CSPRNG 内部状态, 均无法推测出未来的随机数. 而大部分编程语言内置的伪随机数生成器出于性能因素, 在设计上是基于时间戳等可预测性强的随机数种子的, 不具备密码学安全性.</p>
哈希函数与 HMAC</h3>
哈希函数, 如 MD5、SHA-1、SHA-2, SHA-3 和 BLAKE2 等, 将任意长消息不可逆地</strong>转换固定长度的哈希值, 称消息摘要 (digest). 哈希函数被设计为几乎不可能找到具有相同哈希值的两条不同消息, 违背这一点的哈希函数被认为是不安全的, 如 MD5 和 SHA-1.</p>
基于哈希函数的特性, 可以将特定哈希函数用于验证消息完整性, 称 HMAC.</p>
KDF</h3>
文本密码绝大部分情况下不具备足够的熵, 不能直接作加密密钥. KDF</strong> (Key Derivation Function, 密钥派生函数) 负责从文本密码安全地派生出具备足够熵的密钥, 且往往还通过注入随机参数 (盐, salt) 和使用大量迭代和计算资源使暴力计算所有可能的密钥变得不可行. 常用的 KDF 包括 PBKDF2、Scrypt 和 Argon2 等.</p>
密钥交换</h3>
密钥交换算法、方案允许通信双方经由完全不可信的信道安全地协商共享密钥. TLS 中使用到的密钥交换算法包括传统 Diffie-Hellman (DH</strong>) 和基于椭圆曲线的 ECDH</strong> (Elliptic Curve DH), 以及后量子安全的密钥交换算法 (如 ML-KEM</strong>).</p>
加解密</h3>
密码学自诞生之日起最大用途, 就是进行数据的安全存储和安全传输. 按密钥数量, 可将加密算法分为两类:</p>


对称 (Symmetric) 加密: 加密和解密使用相同的密钥</strong>.</p>
如 AES 和 ChaCha20.</p>
</li>

非对称 (Asymmetric) 加密: 加密和解密使用成对的不同的密钥</strong>.</p>
非对称加密用到的两个密钥在数学上是关联的, 我们称其为 “密钥对</strong>”; 其中一把密钥公开, 另一把密钥保密, 我们分别称其为 “公钥</strong>” 和 “私钥</strong>”; 公钥可以由私钥计算得到, 但反过来则几乎不可能实现.</p>
非对称加密体系也称公钥密码学体系.</p>
</li>
</ul>
一般而言, 对称加密比非对称加密更快, 但非对称加密更安全</strong>. TLS 等现代加密协议通常会结合使用对称和非对称加密, 以平衡最佳的安全性和性能.</p>
单纯使用加密算法是不够的, 这是因为有的加密算法只能按块进行加密, 而且很多加密算法并不能保证密文的真实性、完整性. 因此, 现实中我们通常会使用一套加密方案</strong>进行数据的加解密. 加密方案由一系列加密算法、消息认证算法或数字签名算法、块密码模式等多种密码学原语组合得到, 以同时保证数据的安全性、真实性、完整性;加密方案的名称就是使用到的各种密码算法名称的组合, 如 AES-128-GCM、ChaCha20-Poly1305 等. 后面我们再详细了解.</p>
数字签名和消息认证</h3>
密码学当中, 数字签名算法 (Digital Signature Algorithm, DSA) 算法和消息认证 (Message Authentication) 算法提供了对消息真实性、完整性和不可否认性的保证.</p>
DSA 首先是个公钥密码学体系, 大多数数字签名算法使用非对称加密原语: 使用私钥加密特定信息, 此即签名</strong>; 由相应的公钥解密, 此即验签</strong> (保证双方持有合法的密钥对).</p>
MAC 跟数字签名的功能实际上是一致的, 区别在于其使用哈希算法 (HMAC), 或者对称加密原语.</p>
现代加密协议通常会结合使用数字签名和消息认证.</p>
混淆与扩散</h2>
在密码学当中, 香农提出的「混淆」 (confusion) 与「扩散」 (diffusion) 是设计安全密码学算法的两个原则.</p>
「混淆」使密文和对称加密中密钥的映射关系变得尽可能的复杂, 使之难以分析. 如果使用了混淆, 那么输出密文中的每个比特位都应该依赖于密钥和输入数据的多个部分, 确保两者无法建立直接映射.  混淆常用的方法是「替换」与「排列」.</p>
「扩散」将明文的统计结构扩散到大量密文中, 隐藏明文与密文之间的统计学关系. 使单个明文或密钥位的影响尽可能扩大到更多的密文中去, 确保改变输入中的任意一位都应该导致输出中大约一半的位发生变化, 反过来改变输出密文的任一位, 明文中大约一半的位也必须发生变化. 扩散常用的方法是「置换」.</p>
这两个原则被包含在大多数哈希函数、MAC 算法、随机数生成器、对称和非对称密码算法中.</p>
值得指出, “XOR 加密” 的说法本质上是错误的. XOR 操作本身并不提供混淆或扩散.</p>
关于库的使用</h2>
程序员常自嘲为 Ctrl-C / Ctrl-V 工程师, 但在密码学领域反而推荐那么干, 以获得经大量实践验证的当下最优的安全性. 当然, 盲目地从互联网复制粘贴代码也可能会导致安全问题; 曾经安全的代码、算法或者最佳实践, 随着时间的推移也可能变得不再安全.</p>
本章小结</h2>
密码学是一个庞大而复杂的领域, 在后续的文章中, 我们将继续深入探讨 TLS 1.3 协议这一密码学最佳实践. 虽然本章很短, 但不管怎么样, 通过本章内容先建立一个全局观念是极好的.</p>
部分参考文献</h2>

Practical Cryptography for Developers Book</a></li>
Cloudflare: 熔岩灯如何为 Internet 加密助力？</a></li>
</ul>


从零开始了解 TLS 1.3 系列笔记（一）—— 导语
2025-09-12T00:00:00+00:00
导语</h2>
笔者一直认为, 个人是难以面面俱到地从零设计一个安全协议的: 密码学算法固然重要, 但错误的密码学实践与不安全的算法具有同等危害; 总有人试图自创加密协议, 但结果往往是造方形轮子乃至破轮子, 不如直接使用成熟的协议来得安全可靠. Transport Layer Security (TLS, 传输层安全</em>) 协议可谓现代互联网安全的基石, 经历数十年的发展, 在实践中缝缝补补、推陈出新, 如今来到了 1.3 版本. 出于实际需求, 笔者最近半年的空余时间都在阅读 draft-ietf-tls-rfc8446bis</a> (即 RFC8446</a>), 并结合 rustls</a> 源码研究 TLS 1.3 实现. 苦于互联网关于 TLS 1.3 的中文内容相当零散, 遂开个新坑, 从零开始介绍(学习</del>) TLS 1.3 协议的实现细节, 一方面方便笔者自己随时查阅, 另一方面也方便后来者参考学习, 减轻阅读晦涩的英文资料的烦恼.</p>
本系列内容</h2>
本系列按照以下大纲进行撰写:</p>

密码学应用基础.</li>
RFC 8446 规范详解.</li>
TLS 协议拓展, 包括但不限于:

ECH, 见 draft-ietf-tls-esni</a>.</li>
</ul>
</li>
实战: 从零开始, 实现一个简易但 Production Ready 的 TLS 1.3 加密库 (in Rust).</li>
</ul>
由于涉及的内容繁杂且笔者精力有限只能抽空闲时间学习、总结, 预计这个系列在一年内完成. 欢迎各位读者参考学习、批评指正. 感兴趣的读者可以点击 Tag 订阅 RSS.</p>
参考文献</h2>
笔者在编写此系列文章的过程中学习参考了大量资料, 在此列出质量较高的部分, 以飨读者:</p>

冰霜之地 (Halfrost)</a> 分享的系列文章</li>
超超哥哥 (taikulawo)</a> 分享的文章</li>
於清樂 (thiscute)</a> 分享的翻译文章

Practical Cryptography for Developers Book</a></li>
</ul>
</li>
…</li>
</ul>


This Week In Rust (#613) 速报
2025-08-23T00:00:00+00:00
最新一期 This Week In Rust (#613) 新鲜出炉: This Week in Rust #613</a>.</p>
Updates from Rust Community</h2>
Official</h3>


Demoting x86_64-apple-darwin to Tier 2 with host tools</a></p>
评: 光阴似箭, M1 已经是五年前的产物, 在苹果的强力推动下, MacOS 生态对 ARM 架构的支持已经相当完善. 笔者表示, 不愧是苹果.</em></p>
仍然在使用搭载 Intel 处理器的 x86_64 架构的苹果电脑的人越来越少, 自然也就难以继续维持 Tier 1 的支持了.</em></p>
</li>

Leadership Council September 2025 Representative Selections</p>
</li>

Electing new Project Directors 2025</p>
</li>
</ul>
Newsletters</h3>

This Month in Rust OSDev: July 2025</li>
The Embedded Rustacean Issue #52</li>
</ul>
Project/Tooling Updates</h2>


Zed for Windows: What’s Taking So Long?!</a></p>
评: 笔者表示, 已经受不了 VSCode 动辄几个 GB 的内存占用了… 期待 Zed 能够早日发布 Windows 版本.</em></p>
</li>

SeaQuery just made writing raw SQL more enjoyable (数据库</em>)</p>
</li>

r3bl-cmdr v0.0.22 (TUI</em>)</p>
</li>

r3bl_tui v0.7.4 (TUI</em>)</p>
</li>

Heapless v0.9.1 - static friendly data structures that don’t require dynamic memory allocation (嵌入式开发</em>)</p>
</li>

Announcing Asterinas 0.16.0</a> (操作系统内核, 仓库创始人是国人来着, 文档有中文, 泪目</em>)</p>
</li>
</ul>
Observations/Thoughts</h2>


Placing Arguments</a></p>
此文介绍了可能在未来引入标准库的 #[placing]</code> 属性的 API 设计. #[placing]</code> 主要是为了解决实现返回类型在调用方的堆栈帧中构造的问题.</em></p>
</li>

Update on our advocacy for memory-safety - Tweede golf</a></p>
TL, DR: please use Rust for memory safety!</em></p>
</li>

Speed wins when fuzzing Rust code with #[derive(Arbitrary)]</a></p>
TL, DR: 请升级 arbitrary</code> 到 1.4.2, 性能大提升!</em></p>
</li>

Rewriting Numaflow’s Data Plane: A Foundation for the Future</a></p>
Numaflow 是一个开源 K8s 原生平台, 将使用 Rust 重构控制平面</em></p>
其实国内也有个中科院软研所主办的 R2CN（RISC-V Rust for Cloud Native）开源实习计划</a>, 旨在推动 RISC-V 生态和 Rust 在云原生领域的应用, 仓库是 rk8s</a>.</em></p>
</li>

Terminal sessions you can bookmark: Building Zellij’s web client</p>
Zellij is a workspace aimed at developers, ops-oriented people and anyone who loves the terminal. Similar programs are sometimes called “Terminal Multiplexers”.</em></p>
</li>

Testing failure modes using error injection</a></p>
使用错误注入测试故障模式</em></p>
</li>

Multiple Breakpoints in Rust: Ownership-Driven Debugger Design</a></p>
对调试器开发感兴趣的可以看看</em></p>
</li>

Lessons learned from rewriting the UltraGraph crate</a></p>
</li>

Scientific Computing in Rust</a></p>
Rust 做科学计算么, 有意思</em></p>
</li>

RKL: A Docker-like Command-line Interface Built in Rust</a></p>
巧了, 刚才才提到 R2CN. 就是, 得把国人用英文写的文章再翻回去么, 有意思</del></em></p>
</li>

kruci: Post-mortem of a UI library</a></p>
TL, DR: 嫌弃 rataui 性能不行, 作者重写了一个</del> 感兴趣的可以尝鲜.</em></p>
</li>

Nine Rules for Generalizing Your Rust Library: Lessons from Extending RangeSetBlaze to Maps (Part 2)</a></p>
好文, 已加入 TWIR 翻译计划 (咕咕咕)</em></p>
</li>

[audio] Intrusive lists for fun and profit</p>
</li>
</ul>
Rust Walkthroughs</h2>


Constructor Best Practices in Rust</a></p>
好文, 已加入 TWIR 翻译计划 (咕咕咕)</em></p>
</li>

Let’s write a macro in Rust - Part 1</a></p>
好文, 已加入 TWIR 翻译计划 (咕咕咕)</em></p>
</li>

Memory analysis in Rust</a></p>
好文! 已加入 TWIR 翻译计划 (咕咕咕)</em></p>
</li>
</ul>
Miscellaneous</h2>


Rust At Microsoft And Chairing The Rust Foundation</p>
</li>

Talking To Zed Industries- Makers Of The 100% Rust, Super-Performant, Collaborative Code Editor</p>
</li>

All the Rust Tutorials</a></p>
收录了 Rust 开发各种 tutorial, 就是网站略为卡顿.</em></p>
</li>

July 2025 Rust Jobs Report</p>
</li>
</ul>
Call for Participation; projects and speakers</h2>
略.</p>
Updates from the Rust Project</h2>
简要列举几个我觉得很实用的:</p>


implement #[derive(From)]</code></a></p>
将于 Rust 1.91.0 推出. 说实在的, 不知道为什么拖了这么久.</p>
</li>

add Default impls for Pin</code>ned Box</code>, Rc</code>, Arc</code></a></p>
将于 Rust 1.91.0 推出. 也是比较常用的了.</p>
</li>

stabilize #![feature(ip_from)]</code></a></p>
将于 Rust 1.91.0 推出. 这个也是咕了很久了, 还好我习惯使用 nightly Rust. 不知道为什么拖了这么久.</p>
</li>
</ul>
Upcoming Events</h2>
略.</p>


使用 Rust 全局变量的注意事项
2025-08-02T00:00:00+00:00
应当区分 static</code> 和 const</code> 关键字的作用, 正如其文档</a>所言:</p>

A static item is a value which is valid for the entire duration of your program (a 'static</code> lifetime).</p>
静态变量是一个在程序的整个生命周期内有效的值 (拥有 'static</code> 的生命周期).</p>
</blockquote>

const</code> items look remarkably similar to static</code> items, which introduces some confusion as to which one should be used at which times. To put it simply, constants are inlined wherever they’re used, making using them identical to simply replacing the name of the const</code> with its value. Static variables, on the other hand, point to a single location in memory, which all accesses share. This means that, unlike with constants, they can’t have destructors, and act as a single value across the entire codebase.</p>
const</code> 与 static</code> 看起来非常相似, 可能在使用上引起困惑. 简单来说, 常量在使用的地方都会被内联, 这使得使用它们就像简单地用其值替换 const</code> 的名称一样. 另一方面, 静态变量指向内存中的一个单一位置, 所有访问都共享该位置. 这意味着, 与常量不同, 它们不能有析构函数, 并且在整个代码库中充当一个单一值.</p>
</blockquote>
参考资料:</p>

reddit</a></li>
</ul>


译: Mimalloc Cigarette: Losing one week of my life catching a memory leak
2025-07-26T00:00:00+00:00

本文翻译自 Mimalloc Cigarette: Losing one week of my life catching a memory leak</a>, 英文原文版权由原作者所有, 中文翻译版权遵照 CC BY-NC-SA 协议开放.</p>
囿于译者自身水平, 译文虽已力求准确, 但仍可能词不达意, 欢迎批评指正.</p>
2025 年 7 月 26 日晨, 于广州.</p>
</blockquote>

    目录</summary>
    
</details>
One of applications at my work has always been RAM-bound - it’s a pricing engine that basically loads tons of hotels, builds some in-memory indices and then allows you to issue queries like find me the cheapest hotel in berlin, pronto.</p>
我工作中的一个应用程序一直受到 RAM 限制: 它是一个定价引擎, 基本上是加载大量酒店数据, 构建一些内存索引, 然后允许你发出查询, 比如快速找到柏林最便宜的酒店.</p>
A pricing engine’s main purpose is to price engines hotels, but in order to do that effectively, there’s a lot of “meta work” involved, like:</p>
定价引擎的主要目的是为酒店定价, 但为了有效地做到这一点, 涉及很多“元工作“, 比如：</p>


Where do we load the data from, how do we do it?</p>
我们从哪里加载数据, 如何加载？</p>
</li>

Do we load the entire dataset or just some parts of it?</p>
我们是加载整个数据集还是只加载其中的一部分？</p>
</li>

Should we precalculate prices in order to speed-up the most popular queries?</p>
我们是否应该预先计算价格以加速最受欢迎的查询？</p>
</li>
</ul>
Such an engine poses an interesting technical challenge, even greater so when one day it starts OOMing on production, even though the entire dataset should fit in the memory multiple times…</p>
这样的引擎带来了有趣的技术挑战, 当有一天它在生产环境中开始出现内存不足时, 挑战变得更大, 尽管整个数据集应该能在内存中放下多次…</p>
Hello, World!</h2>
Simplifying a bit</del> a lot, what we’re dealing with is:</p>
简要</del>大大简化一下, 我们处理的是：</p>
struct</span> </span>State</span> </span>{</span>
</span></span></span>    hotels</span>:</span> Vec</span><</span>Hotel></span></span>,
</span></span></span></span>}</span></span></span>
</span>
</span>struct</span> </span>Hotel</span> </span>{</span>
</span></span></span>    prices</span>:</span> Vec</span><</span>f32</span>></span></span>,
</span></span></span></span>}</span></span></span>
</span>
</span>//</span> ---
</span></span>
</span>impl</span> </span>State</span> </span>{</span>
</span></span></span>    fn</span> </span>new</span></span>(</span></span>)</span></span></span></span> -></span> Self</span></span> </span>{</span>
</span></span></span></span></span>        Self</span> {</span>
</span></span></span></span></span></span>            hotels:</span> load_hotels</span>(</span></span>)</span></span>.</span>collect</span>(</span></span>)</span></span>,</span>
</span></span></span></span></span></span>        </span>}</span></span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span>
</span></span></span>    fn</span> </span>refresh</span></span>(</span>&</span>mut</span> self</span></span>)</span></span></span></span> </span>{</span>
</span></span></span></span></span>        for</span> (</span>id,</span> hotel</span>)</span></span> in</span> load_hotels</span>(</span></span>)</span></span>.</span>enumerate</span>(</span></span>)</span></span> {</span>
</span></span></span></span></span></span>            self</span>.</span>hotels[</span>id]</span></span> =</span> hotel;</span>
</span></span></span></span></span></span>        </span>}</span></span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span>
</span>fn</span> </span>load_hotels</span></span>(</span></span>)</span></span></span></span> -></span> impl Iterator</span><</span>Item = Hotel></span></span></span> </span>{</span>
</span></span></span>    (</span>0</span>..</span>1_000</span></span>)</span></span>.</span>map</span>(</span>|</span></span></span>_|</span></span> </span>Hotel {</span>
</span></span></span></span></span></span>        prices:</span> (</span>0</span>..</span>1_000_000</span></span>)</span></span>.</span>map</span>(</span>|</span></span></span>n</span>|</span></span> </span>n as</span> f32</span></span></span>)</span></span>.</span>collect</span>(</span></span>)</span></span>,</span>
</span></span></span></span></span></span>    </span>}</span></span></span></span>)</span></span>
</span></span></span></span>}</span></span></span>
</span>
</span>//</span> ---
</span></span>
</span>fn</span> </span>main</span></span>(</span></span>)</span></span></span></span> </span>{</span>
</span></span></span>    let</span> state =</span> Arc::</span></span>new(</span>RwLock::</span></span>new(</span>State::</span></span>new(</span></span>)</span></span></span>)</span></span></span>)</span></span>;</span>
</span></span></span>
</span></span></span>    //</span> Spawn a separate thread responsible for checking which hotels have
</span></span></span></span>    //</span> changed and need to be refreshed etc.
</span></span></span></span>    thread::</span></span>spawn(</span>{</span>
</span></span></span></span></span>        let</span> state =</span> Arc::</span></span>clone(</span>&</span>state</span>)</span></span>;</span>
</span></span></span></span></span>
</span></span></span></span></span>        move</span> ||</span> loop</span> {</span>
</span></span></span></span></span></span>            thread::</span></span>sleep(</span>Duration::</span></span>from_secs(</span>5</span></span>)</span></span></span>)</span></span>;</span>
</span></span></span></span></span></span>            state.</span>write</span>(</span></span>)</span></span>.</span>unwrap</span>(</span></span>)</span></span>.</span>refresh</span>(</span></span>)</span></span>;</span>
</span></span></span></span></span></span>        </span>}</span></span>
</span></span></span></span></span>    </span>}</span></span></span>)</span></span>;</span>
</span></span></span>
</span></span></span>    //</span> Now in reality we start a Rocket server here, but for practical
</span></span></span></span>    //</span> purposes stalling the main thread will be sufficient.
</span></span></span></span>    loop</span> {</span>
</span></span></span></span>        thread::</span></span>sleep(</span>Duration::</span></span>from_secs(</span>1</span></span>)</span></span></span>)</span></span>;</span>
</span></span></span></span>    </span>}</span></span>
</span></span></span></span>}</span></span></span>
</span></code></pre>
Of course IRL there’s ArcSwap</code> instead of RwLock</code>, every hotel contains much more information (like taxes, discounts or supplements) etc., but we’ve got a reasonably good approximation here.</p>
当然在现实生活中有 ArcSwap</code> 而不是 RwLock</code>, 每个酒店包含更多信息（如税费、折扣或附加费）等, 但我们在这里有一个相当好的近似.</p>
Now, what if I told you that this code has totally different memory characteristics depending on which allocator you use?</p>
现在, 如果我告诉你这段代码根据你使用的分配器有完全不同的内存特性, 你会怎么想？</p>
Practical Reasons | 原因分析</h2>
Memory allocator is the piece of software invoked whenever your program needs to get hands on extra memory, like when you’re calling Box::new()</code>. And memory allocation is quite a complex topic, with different solutions offering different trade-offs.</p>
内存分配器是当你的程序需要获得额外内存时调用的软件, 比如当你调用 Box::new()</code> 时. 内存分配是一个相当复杂的话题, 不同的解决方案提供不同的权衡.</p>
Say, when implementing a firmware you might pick an allocator that works slower, because its implementation is just simpler and doesn’t occupy much space in the final binary.</p>
比如说, 在实现固件时, 你可能会选择一个工作较慢的分配器, 因为它的实现更简单, 在最终二进制文件中不占用太多空间.</p>
(some would argue that embeddeed programs shouldn’t allocate, yadda yadda, but you get the idea – replace firmware with wasm and you end up with the same problem.)</p>
（有些人会争论说嵌入式程序不应该分配内存, 等等等等, 但你懂我意思: 把固件替换为 WASM, 你最终会遇到同样的问题. ）</p>
mimalloc</code> is an allocator that fights tooth and nail for performance - and while most applications don’t have to worry about allocation performance, in our case internal benchmarks have proven it gives us extra 10% for free; when your response times have to be within milliseconds, this matters.</p>
mimalloc</code> 是一个为性能而生的分配器: 虽然大多数应用程序不必担心分配性能, 但在我们的情况下, 内部基准测试证明它无需额外配置即给我们带来额外的 10% 性能提升；当你的响应时间必须在毫秒内时, 这很重要.</p>
But there’s a catch.</p>
但有一个陷阱.</p>
Désenchantée | 失望</h2>
That program from before, on my x86_64 Linux machine it allocates around 4 GB of memory and it remains on this level through the refreshing.</p>
之前的那个程序, 在我的 x86_64 Linux 机器上分配大约 4 GB 内存, 并在刷新过程中保持在这个水平.</p>
This makes sense, right? We’re using lazy iterators, replacing stuff in place one-by-one, there’s no reason we’d need more RAM.</p>
这是有道理的, 对吧？我们使用惰性迭代器, 逐个地就地替换东西, 没有理由需要更多 RAM.</p>
But if you use mimalloc</code>:</p>
但如果你使用 mimalloc</code>：</p>
use</span> mimalloc::</span></span>MiMalloc;</span>
</span>
</span>#</span>[</span>global_allocator</span>]</span></span>
</span>static</span> GLOBAL</span>:</span> MiMalloc =</span> MiMalloc;</span>
</span></code></pre>
… the program will first allocate 4 GB and then allocate extra 4 GB during the refreshing, oh noes!</p>
… 程序将首先分配 4 GB, 然后在刷新期间分配额外的 4 GB, 哦 f***!</p>
Getting to this point already took three days of my life - believe me or not, when faced with 200k lines of Arc-ridden Rust code that seems to generate a memory leak, one’s first thought is not “let’s try with different allocator”, but rather “probably something’s holding onto an Arc for too long”.</p>
确认这一点已经花费了我三天的生命: 信不信由你, 当面对 20 万行充满 Arc 的 Rust 代码似乎产生内存泄漏时, 人们的第一个想法不是 “让我们尝试不同的分配器”, 而是 “可能有什么东西持有 Arc 太久了”.</p>
And so I’ve valgrind-ed. I’ve perf-ed. I’ve analyzed assembly. I’ve headbanged and I’ve cried.</p>
我用了 valgrind</code>. 我用了 perf</code>. 我分析了汇编. 我撞头, 我哭.</p>
No more.</p>
不再这样了.</p>
From now on I’m always assuming it’s someone else’s fault - it’s the allocator, it’s the compiler, it’s that crate Mike pulled last night. WHY DO YOU HATE ME MIKE, WHY ARE YOU PULLING RANDOM CRATES TO MY PURE ~~~tv noise~~~</p>
从现在开始, 我将假设这是别人的错: 是分配器的错, 是编译器的错, 是 Mike 昨晚拉取的那个 crate 的错. (碎碎念)</p>
Remède | 解决方案</h2>
Allocators have different characteristics for a reason - they do some things differently between each other. What do you think mimalloc</code> does that could account for this behavior?</p>
分配器有不同的特性是有原因的: 它们彼此之间做一些不同的事情. 你认为 mimalloc</code> 做了什么可能导致这种行为？</p>
Let me give you two hints, two pieces of code that solve the problem, but feel cursed:</p>
让我给你两个提示, 两段解决问题但感觉被诅咒的代码：</p>
//</span> Approach 1:
</span></span>fn</span> </span>main</span></span>(</span></span>)</span></span></span></span> </span>{</span>
</span></span></span>    let</span> state =</span> thread::</span></span>spawn(</span>|</span></span></span>|</span></span> </span>{</span>
</span></span></span></span></span></span>        Arc::</span></span>new(</span>RwLock::</span></span>new(</span>State::</span></span>new(</span></span>)</span></span></span>)</span></span></span>)</span></span>
</span></span></span></span></span></span>    </span>}</span></span></span></span>)</span></span>.</span>join</span>(</span></span>)</span></span>.</span>unwrap</span>(</span></span>)</span></span>;</span>
</span></span></span>
</span></span></span>    /*</span> ... */</span></span>
</span></span></span></span>}</span></span></span>
</span>
</span>//</span> Approach 2:
</span></span>fn</span> </span>main</span></span>(</span></span>)</span></span></span></span> </span>{</span>
</span></span></span>    /*</span> ... */</span></span>
</span></span></span>
</span></span></span>    loop</span> {</span>
</span></span></span></span>        Box</span>::</span></span>new(</span>1234</span></span>)</span></span>;</span>
</span></span></span></span>    </span>}</span></span>
</span></span></span></span>}</span></span></span>
</span></code></pre>
Any ideas? Last chance to win a plushie polar bear!</p>
有什么想法吗？赢得毛绒北极熊的最后机会!</p>
Alright then, the issue is that mimalloc assumes that every thread allocates every now and then.</p>
好吧, 问题是 mimalloc</code> 假设每个线程时不时地分配内存.</p>
Every now and then during malloc()</code>, mimalloc</code> performs some internal bookkeeping, so when a thread goes to sleep (say, because it delegates handling HTTP requests into a separate thread pool…), this bookkeeping doesn’t happen (for that particular thread).</p>
在 malloc()</code> 期间, mimalloc</code> 时不时地执行一些内部整理, 所以当一个线程进入睡眠状态时（比如, 它将处理 HTTP 请求委托给一个单独的线程池…）, 这种整理不会发生（对于那个特定的线程）.</p>
The most nasty edge case that can happen here, and the one that we’ve stumbled upon, is when your thread allocates a lot of data, then launches other threads to work on that data, and then goes to sleep. As other threads work on memory and override stuff, Rust destructors are launched properly, but the underlying memory blocks simply get marked as “to be released”.</p>
这里可能发生的最讨厌的边缘情况, 也是我们遇到的情况, 是当你的线程分配大量数据, 然后启动其他线程来处理这些数据, 然后进入睡眠状态. 当其他线程处理内存并覆盖东西时, Rust 析构函数被正确启动, 但底层内存块只是被标记为 “待释放”.</p>
Under normal conditions, these blocks get processed a moment later, during a call to malloc()</code> on the thread that created them - but if that thread is asleep, those blocks never become available again (unless the thread dies, of course).</p>
在正常条件下, 这些块会在稍后处理, 在创建它们的线程调用 malloc()</code> 期间. 但如果那个线程在睡眠, 这些块永远不会再次可用（当然, 除非线程终止）.</p>
To be sure, the problem is not that the memory is not returned to the kernel - that’s alright. It’s that unless this bookkeeping happens, mimalloc can’t even use the memory for itself - all this free estate just lays there, dormant:</p>
可以肯定的是, 问题不是内存没有返回给内核, 那没关系. 问题是除非这种整理发生, 否则 mimalloc</code> 甚至不能为自己使用内存: 所有这些空闲空间就躺在那里, 休眠：</p>

https://github.com/microsoft/mimalloc/issues/537</a></li>
https://github.com/microsoft/mimalloc/issues/214</a></li>
</ul>
Anyway, the solution we went with was to keep all refreshing on the same thread - when program starts, we spawn a dedicated refreshing-thread and use channels to let it know to do its thing.</p>
无论如何, 我们采用的解决方案是将所有刷新保持在同一个线程上: 当程序启动时, 我们生成一个专用的刷新线程, 并使用通道让它知道要做什么.</p>
So yeah, that was fun; and health-wise probably more like seven cigarettes.</p>
所以是的, 那很有趣；从健康角度来说, 可能更像七支香烟.</p>


推荐阅读: https://www.cnblogs.com/linkwk7/p/11221730.html</a></p>
</blockquote>


随笔一则
2025-04-26T00:00:00+00:00
use</span> std::</span></span>{</span>borrow::</span></span>Cow,</span> hash::</span></span>Hash</span>}</span></span>;</span>
</span>
</span>struct</span> </span>SniMap</span></span>(</span>HashMap<</span>PeerKey<</span>'static</span>></span></span>, Peer></span></span></span>)</span></span>;</span>
</span>
</span>impl</span> </span>SniMap</span> </span>{</span>
</span></span></span>    ///</span> Get peer by SNI.
</span></span></span></span>    pub</span>(</span>crate</span></span>)</span></span> fn</span> </span>get</span></span><</span>'s</span>, 'sni</span>:</span> 's</span>></span></span>(</span>&</span>'s</span> self</span>, sni</span>:</span> &</span>'sni</span> str</span></span>)</span></span></span></span> -></span> Option</span><</span>&</span>'s</span> Peer></span></span></span> </span>{</span>
</span></span></span></span></span>        self</span>.</span>0.</span>get</span>(</span>&</span>PeerKey::</span></span>Exact(</span>Cow::</span></span>Borrowed(</span>sni</span>)</span></span></span>)</span></span></span>)</span></span>.</span>or_else</span>(</span>|</span></span></span>|</span></span> </span>{</span>
</span></span></span></span></span></span></span></span>            self</span>.</span>0.</span>get</span>(</span>&</span>PeerKey::</span></span>Subdomain(</span>Cow::</span></span>Borrowed(</span>
</span></span></span></span></span></span></span></span></span></span></span>                sni.</span>split_once</span>(</span>'</span>.'</span></span></span>)</span></span>.</span>map</span>(</span>|</span></span></span>(</span></span>_,</span> prior</span></span>)</span></span>|</span></span> </span>prior</span></span>)</span></span>.</span>unwrap_or</span>(</span>sni</span>)</span></span>,</span>
</span></span></span></span></span></span></span></span></span></span></span>            </span>)</span></span></span>)</span></span></span>)</span></span>
</span></span></span></span></span></span></span></span>        </span>}</span></span></span></span>)</span></span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span>
</span>#</span>[</span>derive</span>(</span></span></span>Debug,</span> PartialEq,</span> Eq</span></span>)</span></span></span>]</span></span>
</span>enum</span> PeerKey</span><'k> {</span>
</span></span></span>    ///</span> Match exactly the SNI. This is the default mode.
</span></span></span></span>    ///</span>
</span></span></span></span>    ///</span> Will be serialized or deserialized as `example.com`.
</span></span></span></span>    Exact(</span>Cow<</span>'k</span>, str</span>></span></span></span>)</span></span>,</span>
</span></span></span>
</span></span></span>    ///</span> Subdomain match
</span></span></span></span>    ///</span>
</span></span></span></span>    ///</span> Should be serialized or deserialized as `domain:example.com`.
</span></span></span></span>    ///</span>
</span></span></span></span>    ///</span> ## Notice
</span></span></span></span>    ///</span>
</span></span></span></span>    ///</span> Matches direct subdomains only; does not match nested subdomains
</span></span></span></span>    ///</span> (second-level or deeper).
</span></span></span></span>    ///</span>
</span></span></span></span>    ///</span> Take `domain:example.com` as an example, it will match `*.example.com`
</span></span></span></span>    ///</span> but not `*.*.example.com`, etc.
</span></span></span></span>    Subdomain(</span>Cow<</span>'k</span>, str</span>></span></span></span>)</span></span>,</span>
</span></span></span></span>}</span></span></span>
</span>
</span>impl</span> </span>Hash for</span></span> PeerKey</span><</span>'_</span>></span></span> </span>{</span>
</span></span></span>    fn</span> </span>hash</span></span><</span>H:</span> std::</span></span>hash::</span></span>Hasher></span></span>(</span>&</span>self</span>, state</span>:</span> &</span>mut</span> H</span>)</span></span></span></span> </span>{</span>
</span></span></span></span></span>        match</span> self</span> {</span>
</span></span></span></span></span></span>            PeerKey::</span></span>Exact(</span>s</span>)</span></span> =></span> s.</span>hash</span>(</span>state</span>)</span></span>,</span>
</span></span></span></span></span></span>            PeerKey::</span></span>Subdomain(</span>s</span>)</span></span> =></span> {</span>
</span></span></span></span></span></span></span>                state.</span>write</span>(</span>b</span>"</span>domain:"</span></span></span>)</span></span>;</span>
</span></span></span></span></span></span></span>
</span></span></span></span></span></span></span>                s.</span>hash</span>(</span>state</span>)</span></span>
</span></span></span></span></span></span></span>            </span>}</span></span>
</span></span></span></span></span></span>        </span>}</span></span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span>
</span>struct</span> </span>Peer</span> </span>{</span>
</span></span></span>    //</span> ...
</span></span></span></span></span>}</span></span></span>
</span></code></pre>
非常平平无奇的代码. 于是有新的需求: 想缓存 get 的结果 (把按 domain:example.com</code> 匹配到的 sub.example.com</code> 当 full:sub.example.com</code> 写入表内), 达到下次读哈希表一次就能把 Peer 读出来.</p>
有这么几个方案:</p>

改用三方库 dashmap</code> 提供的 DashMap, 类似 RwLock 但 API 层面</em> 是 Lock-free 的.</li>
套一层 Mutex / RwLock.</li>
RefCell</del> 毙掉, 我们需要 Send + Sync, 应该用其线程安全版本: RwLock</em></li>
</ul>
但事实上都是不可行的, 为什么? 欢迎 Rust 初学者自行查阅资料 (问 AI 也行)~</p>
答案 (实际上编译器已经提示了):</p>


对于具有内部可变性的 Cell 类似物, 子类型型变要求是不变 (invariant) 的1</a></sup>. 本例中 DashMap 内部用了 lock_api 库的 RwLock, 这玩意内部用了 UnsafeCell, 故相应字段涉及的泛型类型 K 要求是不变的.</p>
</li>

不能返回本地变量 (拿到的 &Peer 只能活得和上锁后拿到的 Guard 一样久). 起码在当前的 API 设计下不能这么干. 当然, 写出来 get_and_map</code> 一类的奇怪 API 也不是不行.</p>
</li>
</ul>
评价: 写 Rust 的福报</del></p>



参见 https://twir.han.rs/595/rust-type-system-deep-dive#lifetime-variance-and-static–%E7%94%9F%E5%91%BD%E5%91%A8%E6%9C%9F%E5%9E%8B%E5%8F%98%E5%92%8C-static</a> ↩</a></p>
</li>
</ol>
</footer>

i.han.rs

Instructions on building RFC documents locally

Prerequisites</h2>

了解和使用 Rootless Podman

了解和使用 GPG

生成主密钥</h3> 执行 gpg --full-gen-key --expert</code> 进行交互式生成.</p>

配置有效期</h4> 出于安全考虑, 不建议配置密钥永不过期. 此处我们设置为 4 年.</p>

配置 UID</h4> 用户 ID 用于将密钥和真人关联, 同一个主密钥下可以有多个 UID 适应多个身份.</p>

配置密码保护</h4> 输入密码, 按 Tab 移动到下一项, 再次输入密码, 按 Tab 移动到 <OK></code> 确认.</p>

小结</h3> 到这里, 我们已经完成了 GPG 密钥生成的全部操作, 没有特殊情况, 可以直接移步应用章节了.</p>

结语</h2> (唉, 年纪大了, 先总结到这里, 假装有个结语吧; 后面看情况增删补改.)</p>

TLS 加密 ClientHello (Encrypted Client Hello, ECH)

混合公钥加密 (hybrid public key encryption, HPKE) 方案

从零开始了解 TLS 1.3 系列笔记 (六) —— 实用密码学之「对称加密、AEAD 与非对称密码学」

RSA 密钥生成</h4> 略, 相关应用参见加密库的文档.</p>

RSA 加解密</h4> RSA 一次只能加密/解密一个(大)整数, 一般采用 OAEP 对消息编码为一个个整数再逐个加解密.</p>

RSA 签名与验证</h4> 参见后文介绍数字签名算法.</p>

补充内容: 证书以及公私钥的(文本)编码</h2> 由于历史原因, 实践上对证书以及公私钥的存储格式可谓五花八门, 这里参考了 RFC 7468 以及 https://thiscute.world/posts/about-tls-cert/#pki</a>, 试图做一个实用意义上比较全面的总结.</p>

3.2. 推荐的 Nonce 构造方法</h4> (略)</p>

5.2. AES-256-GCM</h4> 除 K_LEN 为 32 Bytes 外, 其他均与 AES-128-GCM 相同.</p>

5.4. AES-256-CCM</h4> 除 K_LEN 为 32 Bytes 外, 其他均与 AES-128-CCM 相同.</p>

6. IANA Considerations</h3> (略)</p>

从零开始了解 TLS 1.3 系列笔记 (五) —— 实用密码学之「密钥交换, Diffie–Hellman 与后量子加密」

从混合颜色解释</h3> </p> 这是来自维基百科的一幅经典图片, 利用混合颜色来解释 DH 的工作原理:</p>

后量子密码学 (Post-Quantum Cryptography, PQC) 应用: 混合密钥交换 (Hybrid Key Exchange)</h2> 相信读者一定提到过 X25519MLKEM768, X25519Kyber768Draft00 这样的名字, 这是 TLS 1.3 中的混合密钥交换方案, 本节简要介绍.</p> </blockquote>

KEM (Key Encapsulation Mechanism, 密钥封装机制)</h3> 如其名, 密钥封装机制核心就是对密文的封装 (encapsulate) 与解封装 (decapsulate), 示意图如下:</p> </div> 主要流程为:</p>

TLS 1.3 中的混合密钥交换</h3> (也许是)出于兼容性考虑, 目前 TLS 1.3 中的后量子密钥交换方案均以混合密钥交换的形式出现.</p>

从零开始了解 TLS 1.3 系列笔记 (四) —— 实用密码学之「HMAC、HKDF 与安全随机数」

认证加密 (Authenticated Encryption, AE)</h3> 使用 MAC 码的另一种场景是认证加密.</p> 加密方:</p>

基于 MAC 的伪随机生成函数 (PRF, Pseudo-Random Function)</h3> MAC 码的另一个应用是作 PRF. 我们可以从某个盐和一个随机数(种子)开始.我们可以计算 next_seed</code> 如下:</p>

KDF</h3> KDF (Key Derivation Function, 密钥派生函数) 是一种将可变长度密码转换为固定长度密钥的函数:</p>

3. HKDF 的使用注意事项</h3> 本节讨论 HKDF 的一些使用注意事项.</p>

从零开始了解 TLS 1.3 系列笔记（三）—— 实用密码学之「哈希函数」

前言</h2> 在本章中, 我们将介绍哈希函数的基本概念, 以及常见的安全哈希算法. 哈希函数在 TLS 协议中被广泛使用, 例如在数字签名算法、消息认证码 (MAC) 和密钥派生函数 (KDF) 中都有应用.</p>

生成主密钥</h3>
执行 `gpg --full-gen-key --expert</code> 进行交互式生成.</p>`

小结</h3>
到这里, 我们已经完成了 GPG 密钥生成的全部操作, 没有特殊情况, 可以直接移步应用章节了.</p>

结语</h2>
(唉, 年纪大了, 先总结到这里, 假装有个结语吧; 后面看情况增删补改.)</p>

RSA 密钥生成</h4>
略, 相关应用参见加密库的文档.</p>

RSA 加解密</h4>
RSA 一次只能加密/解密一个(大)整数, 一般采用 OAEP 对消息编码为一个个整数再逐个加解密.</p>

RSA 签名与验证</h4>
参见后文介绍数字签名算法.</p>

补充内容: 证书以及公私钥的(文本)编码</h2>
由于历史原因, 实践上对证书以及公私钥的存储格式可谓五花八门, 这里参考了 RFC 7468 以及 https://thiscute.world/posts/about-tls-cert/#pki</a>, 试图做一个实用意义上比较全面的总结.</p>

3.2. 推荐的 Nonce 构造方法</h4>
(略)</p>

5.2. AES-256-GCM</h4>
除 K_LEN 为 32 Bytes 外, 其他均与 AES-128-GCM 相同.</p>

5.4. AES-256-CCM</h4>
除 K_LEN 为 32 Bytes 外, 其他均与 AES-128-CCM 相同.</p>

6. IANA Considerations</h3>
(略)</p>

3. HKDF 的使用注意事项</h3>
本节讨论 HKDF 的一些使用注意事项.</p>

前言</h2>
在本章中, 我们将介绍哈希函数的基本概念, 以及常见的安全哈希算法. 哈希函数在 TLS 协议中被广泛使用, 例如在数字签名算法、消息认证码 (MAC) 和密钥派生函数 (KDF) 中都有应用.</p>