密码学 · XB 现场笔记

TLS ECDHE 的前向保密边界

Wed, 27 Oct 2027 00:00:00 +0000

前向保密限制的是长期认证密钥日后泄露造成的影响。对于经过正确认证的临时 Diffie-Hellman 交换，攻击者仅取得长期认证私钥，不能据此恢复先前的会话机密。前提是临时机密没有一起被获取；它不会让已经被攻破的端点、导出的密钥日志或保存下来的明文突然变得安全。

两类密钥承担不同职责

ECDHE 中，双方分别生成临时私钥并交换公开份额。每一方把本地私钥与对方公开份额组合，得到相同的共享机密。旁观者虽然能看到公开份额，但在算法的安全假设成立时，缺少重现计算所需的私有值。新鲜的交换材料并不是双方在网络上公开商量出的一段秘密口令。

TLS 也不会把原始 ECDH 输出直接当成应用加密密钥。密钥调度还会派生不同的握手与应用流量机密，绑定握手上下文，并区分方向和用途。临时交换只提供其中一项关键材料，不能用“双方算出相同字节”替代整个传输协议，也不能略过后续派生和认证步骤。

证书按照信任规则把身份绑定到公钥，实际签署握手材料的是对应的私钥，不是证书这个数据对象自己在签名。TLS 1.3 的证书认证路径通过 CertificateVerify 认证握手记录。如果没有身份认证，主动中间人可以替换公开份额，分别和两端建立自己的共享机密；仅仅看到加密正常，并不能排除这种攻击。

RSA 或 Ed25519 认证密钥可以与临时交换并存，签名算法和密钥交换组是不同选择。TLS 1.3 还定义了仅使用 PSK 的恢复模式，后者不具备 DHE 带来的这项前向保密；PSK 配合 DHE 则会加入新的交换材料。可选 early data 的保证更弱，因此不能单凭 TLS 版本或证书算法标签，就推断所有阶段的流量都有相同保护。

坏掉的样子

长期重复使用同一个交换私钥，会削弱原本希望建立的泄露边界。随机数不足、临时私有值暴露、崩溃转储或 TLS 密钥日志，都可能泄露前向保密假设中不能被攻击者取得的材料。日后泄露流量机密，与日后泄露证书签名私钥，不是同一个威胁场景，不能混用结论。

会话进行时攻破端点，可能直接取得明文。长期认证私钥失窃后，能够拦截未来连接的攻击者也可能冒充服务器。前向保密保护的是特定的历史录制流量场景，并不会撤销泄露凭据，也不会修复仍在持续的入侵；这些问题仍需要独立的凭据轮换与事件处置。

机密销毁更是实现层面的问题，不能仅靠一句“用完就丢弃”来保证。把 Go 变量设为 nil，不证明内存、交换空间或诊断材料中的所有副本都已消失。应避免把机密写进日志，并把凭据失窃的处置与历史流量是否仍受保护的判断分开，不能用概念上的前向保密替代真实的数据暴露调查。

快速验证

保存为 ecdhe_probe.go，使用 Go 1.23 或更新版本运行 go run ecdhe_probe.go。程序在内存中调用标准库的 X25519 与 Ed25519。签名公钥在这个实验里代表已经可信的身份；被签署的消息明确不是 TLS 握手记录。这是一项密码原语层面的实验，不是另一套 TLS 实现，也不能作为上线加密通道的配方。

package main

import (
 "bytes"
 "crypto/ecdh"
 "crypto/ed25519"
 "crypto/rand"
 "fmt"
 "runtime"
)

func must(err error) {
 if err != nil {
 panic(err)
 }
}

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func main() {
 identity, signingKey, err := ed25519.GenerateKey(rand.Reader)
 must(err)
 curve := ecdh.X25519()
 var previous []byte
 for round := 1; round <= 2; round++ {
 client, err := curve.GenerateKey(rand.Reader)
 must(err)
 server, err := curve.GenerateKey(rand.Reader)
 must(err)
 message := []byte("ECDH learning probe; not a TLS transcript\x00")
 message = append(message, client.PublicKey().Bytes()...)
 message = append(message, server.PublicKey().Bytes()...)
 signature := ed25519.Sign(signingKey, message)
 check(ed25519.Verify(identity, message, signature), "trusted signature must verify")
 altered := append([]byte(nil), message...)
 altered[len(altered)-1] ^= 1
 check(!ed25519.Verify(identity, altered, signature), "altered share must fail authentication")

 clientSecret, err := client.ECDH(server.PublicKey())
 must(err)
 serverSecret, err := server.ECDH(client.PublicKey())
 must(err)
 check(bytes.Equal(clientSecret, serverSecret), "peers must agree")
 if previous != nil {
 check(!bytes.Equal(previous, clientSecret), "fresh exchange must produce a different observed secret")
 }
 previous = clientSecret
 fmt.Println("round", round, "agrees; altered share fails signature verification")
 }
 _, err = curve.NewPublicKey(make([]byte, 31))
 check(err != nil, "wrong-length X25519 key must fail parsing")
 zero, err := curve.NewPublicKey(make([]byte, 32))
 must(err)
 client, err := curve.GenerateKey(rand.Reader)
 must(err)
 _, err = client.ECDH(zero)
 check(err != nil, "all-zero shared result must be rejected")
 fmt.Println("two fresh exchanges differ with one signing identity; malformed and low-order inputs rejected")
 fmt.Println(runtime.Version())
}

每一轮中，双方计算出的共享机密必须相同；两轮都生成新的交换密钥，因此本次观察到的两个共享结果必须不同，而认证签名始终使用同一对身份密钥。篡改已签署公开份额消息中的一个字节，会使签名验证失败，说明交换材料与身份认证不能各做各的、互不关联。

反向测试还覆盖了公钥输入边界：三十一字节的 X25519 公钥在解析时就被拒绝；长度正确但全零的输入可以通过长度检查，却会在 ECDH 阶段因全零结果而失败。不能把“公钥对象创建成功”当成共享机密一定可用，后续算法调用的错误仍然需要检查和处理。

已核验的 macOS、Go 1.27.0 运行通过全部断言，只输出结果标签。程序为了对照，刻意保留了前一轮共享机密，所以它没有证明安全擦除，也没有通过穷举证明密码学难度。比较观察到的两组结果，不能扩大成对所有随机输出永不重复的数学承诺。

实验分别观察了密钥协商、一轮一换、签名认证和非法输入处理，但没有执行真实 TLS 握手记录、证书链验证、流量密钥派生、报文加密、会话恢复或生产密钥销毁。实际通信应交给持续维护的 TLS 实现，并核验协商模式；把这些原语拼到一起，还不足以构成安全的传输协议。

来源

RFC 8446：TLS 1.3，CertificateVerify、密钥调度、PSK 模式与前向保密边界，已核验 2026-09-09。
Go crypto/ecdh，X25519 协商与非法公钥行为，已核验 2026-09-09。
Go crypto/ed25519，签名与验证操作，已核验 2026-09-09。

内核把设备噪声转成密钥

Fri, 22 Oct 2027 00:00:00 +0000

Linux 应用通常从内核的密码学安全生成器取得随机字节，不是每输出一位，就必须重新采集一位物理噪声。不过，初始化和状态复用仍然重要。机器繁忙不自动意味着安全，机器安静也不自动意味着故障。判断之前，应确认所用接口、内核版本，以及启动或克隆流程，不能只凭一个计数器就宣布密钥已经不安全。

区分采集与输出

Linux 6.12 的实现把输入混入基于 BLAKE2s 的池，并用 ChaCha20 生成输出。这是该版本的实现细节，不是所有未来版本永远不变的接口契约。硬件来源、中断时序和引导程序输入，按具体平台的信任规则参与。加入字节与把这些字节计入初始化熵估算，是两件不同的事；内核不能假设用户任意提供的一串字节都包含新鲜、不可预测的信息。

在这个实现中，poolsize 与初始化完成后的熵计数都达到二百五十六位，读取不会像消耗燃料一样扣减计数。因此，旧手册里四千零九十六位的描述，不应直接变成所有机器的告警阈值。应记录运行内核并检查对应行为，不能声称所有 Linux 版本的计数都一样，也不能仅因数字较小就判定随机输出薄弱。

选择会等待初始化的接口

默认 getrandom 会等到初始化完成。带 GRND_NONBLOCK 时，尚未初始化会报告 EAGAIN，使应用能够说明状态而不无限等待。初始化以后，默认源的一次请求若不超过二百五十六字节，具有文档规定的完整读取与信号保证；调用方仍应检查错误和返回长度。更大请求要正常处理部分返回和中断，不能把小请求的保证扩大到所有缓冲区。

random 设备从 Linux 5.6 起改变了行为：初始化后不再因为所谓熵耗尽而阻塞。在核对的 Linux 6.12 源码中，GRND_RANDOM 也不选择一个独立、会被耗尽的输出池。有些手册仍保留旧行为描述，不应把历史限制与当前内核结论混合。直接读取 urandom 可能发生在初始化之前；早期启动生成密钥，应使用支持初始化等待的接口。

坏掉的样子

早期启动仍可能缺少足够的可信计入输入。容器中缺少设备节点则是另一类接口问题：getrandom 不需要设备路径，普通容器共享宿主内核。操作等待时，应有明确的启动失败或等待策略，而不是改用时间戳、可预测种子或不安全的备用输出。让服务尽快启动，不是降低密钥生成要求的理由。

保存的种子可以帮助下一次启动，但把文件写回 urandom 并不会自动增加熵计数。一个三十二字节文件，或者某种硬件设备的存在，都不能单独保证立即就绪。应使用发行版提供的种子管理机制，了解它何时、依据什么信任条件计入熵。保护种子文件，避免在克隆镜像里分发相同的保存种子，并让引导程序专用的种子处理与操作系统流程一致。

复制磁盘镜像和恢复运行中的虚拟机，是两种不同风险。前者可能复制种子文件或已经生成的主机密钥，后者可能复制正在使用的生成器内存状态。新输入及虚拟机生成标识处理，可以让后续状态分离。未来输出完全相同是需要调查的风险，不是每次克隆必然出现的结果；两台机器使用同一份种子，也不足以证明它们全部生成器状态完全一致。

快速验证

在 Linux 上运行下面的 Python 3 脚本。它读取计数器，并请求一次非阻塞的三十二字节输出；不会打印随机内容，不读取私钥，不更改种子文件，也不需要管理员权限。这样可以观察接口是否就绪，而不把诊断过程变成密钥材料收集或系统配置变更。

from pathlib import Path
import json
import os
import platform

def counters():
 result = {}
 for name in ("entropy_avail", "poolsize"):
 try:
 result[name] = int(Path("/proc/sys/kernel/random", name).read_text())
 except OSError as error:
 result[name] = type(error).__name__
 return result

before = counters()
try:
 sample = os.getrandom(32, os.GRND_NONBLOCK)
except BlockingIOError:
 print(json.dumps({"kernel": platform.release(), "ready": False,
 "counters": before}))
else:
 assert len(sample) == 32
 print(json.dumps({"kernel": platform.release(), "ready": True,
 "bytes_returned": len(sample), "before": before,
 "after": counters()}))

本轮在 Linux 6.18.44、Python 3.12.14 上观察到 ready=true、bytes_returned=32，前后两个计数器都为二百五十六。这只是已初始化主机上的结果，不是早期启动、硬件质量或恢复虚拟机的测试。若源未初始化，程序会报告 ready=false；本轮没有通过修改宿主随机状态去制造该分支，也不能把未执行的分支标记成实测通过。

成功调用说明当前接口在这一时刻提供了要求的字节，不是随机性统计检验，更不是密码学不可预测性的证明；比较两次样本也无法给出这种证明。如果 proc 访问受限，计数器可能显示错误类型，而系统调用仍然成功。应分别解释这些情况，不能把诊断信息不可读直接当作熵故障，也不能把成功返回当作所有启动和克隆风险均已排除。

用直接证据调查身份复用

密钥文件的修改时间不能证明生成时使用了哪个随机源。文件会跨重启保存，复制可以保留时间戳，系统时钟也可能调整；看不到初始化日志同样不能证明初始化失败。应检查镜像准备流程、密钥生成代码、启动策略和重复的公钥指纹。确认身份重复或泄露时再制定轮换措施，不应仅凭时间戳对比就宣布一批密钥已经受损。

来源

Linux 6.12 随机数实现，初始化计数、getrandom、sysctl 与虚拟机分叉重播种，已核验 2026-10-15。
Linux getrandom(2)，初始化等待、小请求与错误；历史 GRND_RANDOM 描述需结合版本，已核验 2026-10-15。
Linux random(4)，写入不计熵及 Linux 5.6 阻塞变化；历史池大小不代表当前内核，已核验 2026-10-15。
systemd 256 随机种子服务，种子生命周期、熵信任策略与镜像准备，已核验 2026-10-15。

密码学 · XB 现场笔记

TLS ECDHE 的前向保密边界

两类密钥承担不同职责

坏掉的样子

快速验证

延伸阅读

来源

内核把设备噪声转成密钥

区分采集与输出

选择会等待初始化的接口

坏掉的样子

快速验证

用直接证据调查身份复用

来源