切换深浅色
第 17 章 后量子密码学
17.1 量子威胁改变的是计算假设,不是所有加密同时失效
前两章多次说“从公开材料难以恢复秘密”。这里的难以依赖攻击者可使用的计算方法。对经典计算机而言,足够参数下的整数分解与椭圆曲线离散对数被认为难以求解;足够强、能够运行相应算法的量子计算机则会改变这些假设。
Shor算法针对整数分解和离散对数提供高效量子求解路径。因此受影响的不仅是某种“RSA加密”,也包括RSA签名、经典Diffie-Hellman和ECDH,以及依赖相关难题的ECDSA、Ed25519等签名。不能因为X25519比较现代、密钥较短或计算快,就推断它不在威胁范围内。这里的前提是足以处理密码规模问题的量子能力,不是任意现有量子设备一经开机就能破解互联网。
对AES、ChaCha20和密码散列,影响的形式不同。Grover式搜索在理想查询模型中可以给穷举带来平方级加速,但完整攻击还需考虑量子电路、错误纠正、串行深度与并行成本。不能把所有密钥位数机械除以二,再当作实际运行时间,更不能说Shor直接解开了AES内部变换。NIST按不同算法与攻击模型评估安全类别,而不是用一个“量子破解倍数”覆盖全部密码系统。NIST PQC FAQ。
加密记录仍然可能通过公钥环节间接受影响。攻击者保存今天的ClientHello、ServerHello和TLS密文,将来若能从公开X25519交换值恢复某个临时私有值,就能重算Z及记录密钥。它不必直接攻击AES。即使两端当年清除了临时秘密,公开交换材料仍保存在攻击者的记录中,新的求解能力可以改变这些材料的意义。
这就是先收集、后解密的风险。数据若在多年以后仍然敏感,密码迁移需要考虑它的保密寿命,而非只问今天能否解开。这个论证不需要给出“某年一定出现足够强量子计算机”的预测;确定的设计问题是:只要该能力在保密期内出现,今天录下的哪些公开材料会足以恢复内容。NIST后量子密码学介绍。
前向保密与此并不矛盾。经典ECDHE的PFS针对后来泄露长期认证密钥等威胁,在其计算假设仍成立时保护历史会话;它不承诺能够抵抗离散对数假设本身被攻破。PFS回答秘密在时间上如何隔离,后量子设计回答采用哪些对经典和已知量子攻击都被认为困难的问题。二者可以同时具备,也可以只具备其一。
后量子密码学通常缩写PQC,是在普通计算机上运行的新算法,不需要每个客户端配量子硬件,也不是量子密钥分发QKD的另一种叫法。它依靠格、编码、散列等不同数学结构设计公钥工具,继续与普通网络和对称加密结合。新工具仍需要随机性、身份认证、正确实现和密钥生命周期管理,不会自动解决端点失陷或流量分析。
本章重点采用NIST的FIPS203 ML-KEM,并核对2026年已经发布的TLS混合交换规范RFC9954、RFC10024。它们是不同层次:FIPS203定义KEM算法,TLS规范定义怎样把算法结果和经典交换组合进握手。不能把“已支持ML-KEM”直接解释成完整握手和证书认证都已实现后量子安全。
17.2 KEM不是传送任意正文,而是建立一份共同秘密
密钥封装机制称为KEM,包含生成密钥、封装和解封装三个接口。它让一方用公开材料产生一份秘密和一个可发送的封装值,另一方用相应私有材料从封装值恢复同一秘密。随后再用KDF与AEAD保护真正的业务内容。FIPS 203 §3.1。
| 步骤 | 输入 | 输出 | 哪些材料可以发送 |
|---|---|---|---|
| KeyGen | 规定的安全随机性 | 封装公钥ek、解封装私钥dk | ek可以公开,dk必须保密 |
| Encaps | ek及本次随机性 | 共享秘密K、封装密文c | 发送c,不发送K |
| Decaps | dk与收到的c | 共享秘密K′,或按方案规定处理失败 | 本地使用K′,不把它回传 |
这里的c常称KEM ciphertext,但它不是任意网页正文的密文。Encaps接口通常不接受“请加密这段HTTP”作为消息参数,而是根据算法和随机性产生共享K。若要传送网页内容,应把K交给规定的派生过程,再用得到的对称key保护正文。把1088字节KEM密文写成“每个应用数据块都增加1088字节”,通常是把握手建立与记录保护混淆。
设C生成(ek,dk)并把ek送给S;S调用Encaps得到K和c,发送c;C调用Decaps得到K′。正常有效交换应使K=K′,旁观者只得到ek和c。双方角色未必与“服务器长期持有公钥私钥”的直觉一致:TLS混合握手可以由客户端持有临时解封装私钥,服务器产生封装响应。本章后面将精确列出这种方向。
KEM与ECDH的公开材料形状也不同。ECDH通常是双方各发一个公开交换值;KEM是一方先发公钥,另一方发封装密文,并在本地得到秘密。两者都可以成为共享秘密来源,但字段长度、输入检查、私有材料保存以及生命周期要分别规定,不能把c误当成“服务器KEM公钥”。
公钥公开还意味着任何获得ek的人都可以运行Encaps,产生自己的K和c。所以一次正确解封装并不认证服务器的服务名或代理使用资格。攻击者若替换了客户端得到的静态ek,也可能把后续秘密引向自己。完整协议需要可信公钥归属、认证握手历史和必要的密钥确认,与第15章讨论的职责一致。
失败处理则需要看具体方案,不能从通用接口表推断所有KEM都返回同一种错误。ML-KEM采用隐式拒绝:在通过尺寸和私钥等入口检查后,对某些不一致封装值也输出一份由秘密材料决定的替代K′,而不把“重新加密是否一致”的秘密标志返回给调用者。对端随后通常会因密钥确认或记录认证不一致而无法完成协议。长度不合要求等公开格式错误仍可在入口拒绝,这与隐式拒绝不是矛盾。
这种安排用于限制攻击者从解封装响应中得到有用信息;它不等于“任何密文都合法”,也不表示应用可以把所有输出K′当成已认证会话。正确的输入检查、计算时间、错误表现及后续确认仍是整体设计的一部分。下一节将从ML-KEM的数学结构、实际字段和重算比较说明它怎样实现这些步骤。
17.3 ML-KEM-768:带噪声的方程怎样成为封装机制
ML-KEM基于CRYSTALS-Kyber发展,但FIPS203最终算法不能与任意旧Kyber版本直接视为字节兼容。参数名768也不是768位AES密钥或768字节密文。它标识一套确定参数;ML-KEM-768对应NIST安全类别3,共享秘密仍为32字节。FIPS 203 §3、§8。
先看难题的直觉。如果公开矩阵A、秘密向量s与结果t严格满足t=A s,许多情形可以用普通线性代数求解。加入按规定抽取的小误差e,变成t=A s+e mod q以后,公开关系中不再是一组完全精确的方程。攻击者不能把误差当作已知值直接消去。ML-KEM依赖与这种带噪声学习问题及模块格有关的计算困难性;不是因为实现算错,也不是任意加入一点噪声就自动安全。
具体运算的对象是多项式。系数模q=3329,次数不足256,乘法还按X²⁵⁶+1约减,形成环R_q;向量有k个这样的多项式,矩阵有k×k个。ML-KEM-768取k=3。所谓模块,体现在这类环上向量与矩阵的结构;它允许紧凑表示和高效运算,但安全分析也必须使用相应结构,不能从一般实数矩阵的直觉直接推出强度。
生成密钥时,从私有随机种子扩展出公开矩阵种子ρ及用于抽取秘密与误差的材料。A可以由ρ确定性重建,所以公钥不必存整张3×3矩阵。s和e则按规定的小系数分布抽取,形成t=A s+e。实现主要在数论变换NTT域中完成乘法;NTT是有限域上的计算加速表示,作用类似把昂贵卷积变成更方便的运算,不是另一种加密层,也不使用浮点近似来代替规范结果。
ML-KEM内部的K-PKE加密子过程可以用以下关系理解,实际算法包含NTT、编码、压缩和精确抽样:新选小向量y及误差e₁、e₂,形成u=Aᵀy+e₁,v=tᵀy+e₂+μ,其中μ把32字节消息的256个位映射到多项式系数。解密者计算v−sᵀu,主项抵消,留下μ及受控噪声,再按规定恢复位值。
这里没有声称噪声总为0。正确性依赖参数与分布使解码出错概率足够低,同时不把公开方程变成容易求解的精确关系。压缩又引入受控舍入误差,也计入设计。K-PKE只是构建KEM的内部组件,不能去掉外层转换后直接当作完整抗主动攻击的公钥加密协议部署。
公钥的尺寸可以从表示推导。一个多项式有256个系数,每个按12位打包,占256×12/8=384字节;3个t的NTT域多项式占1152字节,再接32字节公开矩阵种子ρ,共1184字节。12位容器可表示到4095,超过3328的非规范系数不能因为装得下就都作为合法公钥接受,入口要按标准检查。
| 对象 | ML-KEM-768展开格式 | 字节数 |
|---|---|---|
| 封装公钥ek | 3个12位编码的t多项式,加ρ | 1152+32=1184 |
| 内部PKE解密材料 | 3个12位编码的秘密NTT多项式 | 1152 |
| 展开解封装私钥dk | 内部解密材料、ek、H(ek)、拒绝秘密z | 1152+1184+32+32=2400 |
| 封装密文c | 压缩u的3个多项式,接压缩v | 960+128=1088 |
| 共享秘密K | 封装转换得到的秘密字节串 | 32 |
密文中u每系数压到10位,3×256×10/8=960字节;v每系数压到4位,256×4/8=128字节。它们是位打包,不是在前面给每个多项式放一个HTTP式长度字段。ByteEncode规定系数低位到高位的打包次序,不能把一个12位系数直接当成两字节网络大端整数,从而把公钥长度错误扩大。
FIPS203还允许以生成种子保存私有材料。生成时d与z各32字节,合计64字节,能重新展开相应私钥,因此同样是敏感秘密。这与“展开私钥长2400字节”不冲突:一个描述标准展开格式,另一个描述可恢复它的紧凑存储。NIST在2026年更新的FAQ明确了种子格式的适用安排;某个库的导出格式仍须按该库定义解释。
Encaps并不直接把任意应用K塞进公钥加密。它生成32字节随机m,计算G(m后接H(ek)),得到32字节K及32字节加密随机材料r,然后以K-PKE使用ek、m、r生成c。这里H是SHA3-256,G是SHA3-512并拆成两半。公钥摘要把封装与正确公钥关联;r由m和公钥摘要确定,使解封装可以重算候选密文。
解封装先用私有PKE材料从c恢复候选m′,再由m′和保存的公钥摘要算出K′、r′,用公钥重新加密得到c′。若c′与c一致,返回K′;否则返回J(z后接c),其中J是输出32字节的SHAKE256。比较结果是秘密中间状态,不能作为另一个返回标志泄漏。这个重算与替代输出就是隐式拒绝,而不是简单“解密乱码也当共享key”。FIPS203 §6—7。
封装前检查ek的长度与系数编码,解封装前检查密文长度、私钥格式及公钥摘要一致性,仍是必要入口步骤。对正确尺寸但不一致的密文,隐式拒绝需要避免泄漏分支;对错误尺寸则无需先运行整套多项式运算才发现越界。后续会话还要验证对端确实得到同一秘密,且身份符合预期。
其他参数组改变k、噪声或压缩参数,不能只换一个名字、继续使用768的长度:
| 参数组 | 公钥ek | 展开私钥dk | 密文c | 共享K | NIST类别 |
|---|---|---|---|---|---|
| ML-KEM-512 | 800 | 1632 | 768 | 32 | 1 |
| ML-KEM-768 | 1184 | 2400 | 1088 | 32 | 3 |
| ML-KEM-1024 | 1568 | 3168 | 1568 | 32 | 5 |
这些类别是参照特定攻击资源与基准原语的分类,不等于可以把768直接写成“768位安全”。网络开销主要在公钥与封装交换阶段;记录仍使用派生后的对称机制,CPU与内存实际成本则依赖具体实现和平台,不能仅由上表得出吞吐量。
17.4 TLS混合交换怎样组合两种秘密
后量子算法引入新的计算假设,人们也希望保留长期分析过的经典方案。混合交换同时运行两个组件,再用规定的组合与派生形成最终材料,目标是在至少一个组件仍安全时保留相应的共享秘密保证。它不是把两种AES轮流套在正文上,也不是在两份结果之间任选一份。
RFC9954定义TLS混合交换框架,RFC10024则在2026年8月明确了三个具体组。以下采用其中X25519MLKEM768,正式NamedGroup为4588,即11ec。客户端准备临时X25519密钥对以及独立生成的ML-KEM-768密钥对,服务器接收后进行X25519交换与ML-KEM封装。
| 方向 | key_exchange内的先后顺序 | 字节数 |
|---|---|---|
| 客户端→服务器 | ML-KEM-768封装公钥ek,接客户端X25519公开值 | 1184+32=1216 |
| 服务器→客户端 | ML-KEM封装密文c,接服务器X25519公开值 | 1088+32=1120 |
| 本地共同结果 | ML-KEM共享K,接X25519共享Z | 32+32=64 |
顺序必须按组定义,不能根据名字先出现X25519,就把其32字节放在最前。RFC10024特意说明这个组的历史顺序例外。另两个NIST曲线混合组采用经典部分在前的顺序,不能建立一个“所有混合组字段都同序”的解析器。
客户端key_share扩展如果只含这一个条目,开头为:
text
00 33 04 c6 | 04 c4 | 11 ec 04 c0 | 1216字节key_exchange扩展内容长1222,内部条目列表长1220,条目值长1216,整扩展1226字节。服务器对应扩展没有条目列表总长,开头为00 33 04 64 11 ec 04 60,再接1120字节,整扩展1128字节。这些是固定长度推导的布局,不是编造的完整握手抓包。
服务器先检查ek符合ML-KEM格式,调用Encaps得到K和c,同时用自己的X25519临时私有值与客户端公开值形成Z。客户端收到响应后,用自己的ML-KEM解封装私钥恢复K,并用X25519临时私有值与服务器公开值形成同一Z。两端串联K后接Z,将64字节结果作为TLS主干相应Extract的非对称输入,PSK、握手摘要和其他标签仍按TLS密钥树处理。
不能跳过任一组件的输入检查。公钥编码错误、封装密文长度错误、X25519全零共同结果等都有规定的中止路径。ML-KEM内部隐式拒绝可能返回替代秘密,而不是公开失败标志;后续TLS证明不一致仍会阻止完成认证。静默丢掉有问题组件、只使用剩下一个秘密继续,会改变双方协商的组及安全意义。
“一项仍安全就保留保证”有适用前提:组件满足相应安全要求、不同算法的秘密材料正确独立生成、组合具有规定的稳健性、编码无歧义,并且TLS认证覆盖协商。它不是任意两个函数输出相加、异或或串联就自然成立的结论。标准框架对公钥或密文可被选择、不同组件安全模型及派生的假设进行专门分析,不能以名称“混合”替代这些条件。
同一个ClientHello同时提议纯X25519与混合组时,RFC9954允许在这次ClientHello的多个条目中复用同一算法组件的公开值,减少重复计算;不同算法仍须独立生成。这不等于允许跨连接长期复用key_share,后者受到现行TLS要求禁止。字段重复出现、秘密生命周期与算法独立性是三件不同的事。
混合组可以保持原本握手的逻辑往返数,却明显增加首轮字节。与单独X25519相比,两个方向key_exchange合计额外增加1184+1088=2272字节,还可能影响分片、发送批次与丢包后的恢复。更多运输包不自动等于多了一次协议握手往返,反过来“仍是1-RTT”也不保证相同实际延迟或CPU成本。
最终记录仍可使用AES-GCM或ChaCha20-Poly1305;混合的是密钥建立来源,不要求逐条业务记录都重新运行KEM。证书签名也没有因选择11ec自动改成后量子签名。若面对未来主动攻击者,还须单独分析服务器身份算法;若重点是抵抗今天录下、未来只解密的攻击,则混合交换改善的是历史内容的秘密来源。
旧实验组X25519Kyber768Draft00等使用预标准Kyber,不能同11ec的FIPS203 ML-KEM互换。RFC10024已把相应旧组标为废弃。实际软件是否支持正式组、采用哪份编码,必须看固定版本与握手结果,不能只从界面上的“Kyber”或“PQ”字样推断。
17.5 后量子交换不自动带来前向保密
设P长期保存ML-KEM解封装私钥dk,并把ek可信地分发给客户端。每次C用ek生成全新的K和c,随即用K派生记录材料;P收到c后解封装。只要ML-KEM相应计算假设成立,这可以抵抗仅凭ek、c求K的经典及已知量子攻击。然而,日后直接窃取dk的人可以对录下的每个c运行正常Decaps。它并没有破解格难题,只是在执行合法解封装。
所以每次Encaps都使用新随机性,不等于每次解封装私钥也是临时的。新K可以区分会话,却仍然全部依赖同一个长期dk。这与第15章静态ECDH的生命周期问题相似,不能因为算法名称换成后量子就把依赖抹掉。
如果每次握手重新生成KEM密钥对,通过独立可信机制认证本次ek和c,并在完成必要派生后清除dk、封装随机材料、K及旧会话密钥,那么日后只泄露长期认证密钥,不应足以恢复先前的共享材料。这个设计才同时处理“计算假设面向量子攻击”和“过去秘密不依赖后来泄露的长期认证密钥”两个维度。实际保证仍取决于清除、实现和完整握手。
| 共享材料建立方式 | 只观察公开交换的未来量子威胁 | 后来取得长期交换/解封装私钥 |
|---|---|---|
| 静态经典ECDH | 离散对数假设受威胁 | 能恢复其依赖范围内的旧结果 |
| 新鲜经典ECDHE | 仍受量子求解公开值威胁 | 只取得独立认证密钥时,经典PFS保护历史 |
| 静态ML-KEM | 依赖ML-KEM后量子安全假设 | 可正常解封装录下的旧c,无需破解算法 |
| 经过认证的临时ML-KEM | 依赖ML-KEM后量子安全假设 | 只取得独立认证密钥时,需看临时秘密已清除等条件 |
表中没有给所有攻击统一打分。第三列关心直接获得哪一种秘密;第二列关心公开数据面对新求解能力。若攻击者取得的是保存全部会话秘密的日志,两列中的设计目标都无法让日志内容自动失效。
混合结构也需要逐组件看生命周期。一个方案使用临时X25519与静态ML-KEM:后来只泄露ML-KEM私钥,经典组件在原计算假设下或许仍保护历史;但若同一攻击者将来又有量子求解X25519能力,就可能同时得到两份旧秘密。宣称“有一个临时组件所以全部后量子PFS”,会把两个分量各自成立的不同条件混在一起。
TLS标准化混合组采用临时交换与完整认证,按其定义追踪两个组件;某个代理的自定义混合交换则必须另查源码。相同ML-KEM参数组不说明静态公钥如何分发、是否再交换临时公钥、何时进入早期数据,以及最终记录依赖哪些分量。后文将对VLESS Encryption画出这些实际分支,不把本节概念场景冒充其实现事实。
混合交换标准的范围也明确分开密钥建立与后量子身份认证。RFC9954 §1.3—1.4讨论的是临时密钥交换组合;只有把整个认证与生命周期放回同一威胁模型,才能说明某条真实连接在何种意义上具备后量子保护及前向保密。
17.6 混合会话的泄露时间线与身份边界
设一条TLS连接在今天使用新鲜X25519MLKEM768交换,并以经典RSA或Ed25519证书认证服务器。端点正确清除临时秘密,攻击者只保存握手和应用密文。几年以后再获得量子求解经典离散对数的能力,它可能恢复X25519分量Z,但仍没有因此得到ML-KEM分量K。在标准组合的假设下,缺少K就不能照正常密钥树算出旧记录材料。
把场景改为:端点今天把这次ML-KEM解封装私钥或可展开它的种子写入长期日志;攻击者先取得日志,未来再解决X25519。此时两项来源都可能恢复,混合的保证条件已经同时失效。日志不必记录最终AES key,也可能经由更上游的材料影响历史内容。安全检查应追踪全部秘密来源,而不只搜索文件中有没有名为key的字段。
再把攻击位置改为未来的主动路径攻击者。若它能伪造客户端仍认可的经典服务器签名,就可以生成自己的新临时交换材料,为其签名,并让客户端与它建立一个新鲜、甚至正确使用ML-KEM的会话。KEM仍可能正常工作,但共同秘密属于客户端与冒充者。仅更新交换组不能替代后量子身份认证。
这与历史被动解密是不同目标。未来能伪造一份经典签名,不等于可以改变过去已经完成的那场在线握手、把自己当年的公开值插入已记录的字节。历史通道保密首先取决于当年的共享材料是否可恢复;未来在线认证则要看未来握手的身份依据是否仍可靠。对需要长期验证的签名文件、时间戳等对象还需另行分析,不能把在线握手的结论挪给所有存档证明。
| 攻击场景 | 混合交换提供的相关帮助 | 还需要分析的条件 |
|---|---|---|
| 今天记录,未来只求解经典交换 | ML-KEM分量仍可能保护旧共同结果 | ML-KEM假设、组合、实现及秘密清除 |
| 今天取得某一组件秘密 | 另一独立安全分量可能继续提供保证 | 另一分量生命周期及未来求解能力 |
| 未来主动伪造服务器身份 | 新鲜KEM本身不能阻止冒充者参与 | 后量子身份方案或其他仍可信认证依据 |
| 直接取得端点当前记录密钥 | 不能靠握手算法隐藏已泄漏材料 | 端点控制范围、密钥更新与恢复信任 |
会话恢复又形成下一段时间关系。一次后量子混合握手得到的恢复PSK,可以把保密基础传递到后续连接;但某次0-RTT记录只依赖PSK和公开ClientHello,不包含该次新服务器交换结果。后来泄露这份PSK,仍可能恢复相应早期记录。不能因为PSK源头是混合交换,就把它每次派生出的早期数据一概描述成新的后量子PFS。
正常恢复阶段若又采用新的混合组,它会在PSK以外加入新材料,后续应用记录的依赖图再次改变。究竟哪批字节依赖哪一份PSK、哪一次KEM、哪个方向traffic secret,应画到具体阶段;一个连接级别的PQ开关无法充分表达这些差别。
对称记录、派生散列和身份算法也都有各自参数。选择ML-KEM-768不表示记录AEAD密钥自动变成768位,也不能把两个组件的安全位数相加。工程中的最终安全目标由整套组合、参数和攻击模型约束;“使用了一个强算法”只是其中一项证据。
RFC9954的范围与安全分析明确把混合临时交换与身份认证问题区分。接下来使用公开向量核对ML-KEM实际材料,再把这套分析方法带入VLESS及其加密组合。
17.7 公开向量中的公钥、封装与拒绝输出
ML-KEM公钥和密文很长,逐行抄完并不能自动增加理解。本节选择NIST官方ACVP-Server公开样例,固定提交975de31eb83d87039ec88934fdc47d8c312b892d,给出案例编号、必要短输入、完整共享秘密和长对象的定位信息。完整字节由固定来源提供,没有把缺省字节当成零补齐。
密钥生成样例中,ML-KEM-768组tgId=2的首例tcId=26使用以下公开测试种子,各32字节:
text
d = e582b7d75e6c80b05ae392a1fc9f7153b12390fd99930368cc67a768baebc8a0
z = 1cdacb8740c0b87c4a379575f187b367cbfa3b300bf591b109f79816e9cbe8f0由此形成的ek长1184字节,其前32字节为28c793778741b80b02b4339f2aa4347255b099f17264e1b8cc0a2c7c2a1a79f7。对完整ek计算SHA-256得到:
text
4158f6afb5e516c99f1da07da8c651348422b17c1f4e9a08ad73fb1f91249b3e这里SHA-256仅是本书用来核对长对象的摘要,不是说ML-KEM内部H改成SHA-256,也不是网络上新增一个公钥摘要字段。本书已从上述64字节种子通过独立实现重建公钥,逐字节与NIST预期ek一致。
再看封装与解封装样例。其中封装组tgId=2的tcId=26是另一组密钥,不能因为编号也为26,就把它同上一文件的种子配成一场交换。该例的ek摘要和封装材料如下:
| 材料 | 长度 | 值或定位 |
|---|---|---|
| 完整ek的SHA-256 | 32 | 14e61ead72434882f25ab99eebf87d5d4a7f2721aaf4cc316b3abcdcbf1acc83 |
| 封装内部随机输入m | 32 | 4e77596168711e913965d8175ac3bd76aab08b7f9385a02ae883cf6c6e17dd81 |
| 封装密文c | 1088 | 完整值见固定源文件;前缀见下 |
| 共享秘密K | 32 | 79d74f6c6c2d916bec47bd828fd9b67295a37f54927fab1263c0d122f1c6f1ed |
c的前32字节为:
text
03 85 e8 04 4d 17 e2 b9 6b 3f 50 ed 28 c2 50 22
16 32 2a c3 3f 69 d2 ce 34 f0 a1 1e 9b 3d e3 39完整1088字节c的SHA-256为6aa5618fa7e32446603b9b828f0367fde929305f422d29fbbd5e36e98c94f07c。前缀只是前缀,不代表一个可独立解封装的短密文。样例文件同时提供对应测试dk;本书使用它对完整c解封装,得到与上表完全一致的K,还核对G(m后接SHA3-256(ek))的前32字节也等于此K。这里没有声称已独立重算该例的全部封装密文。
隐式拒绝也能从真实案例观察。同文件ML-KEM-768解封装组tgId=5的tcId=88,原因标记为modified ciphertext,预期输出仍是32字节:
text
2cfb695710a6c4377f46c20c13480aef7ac56030d47a0ab5af07ddd6062c28f4本书核对该例Decaps输出,并直接以dk最后32字节z及完整c计算SHAKE256的32字节结果J(z后接c),二者相同。这是拒绝分支的替代秘密,不是攻击者成功选择了合法会话K。若上层把“接口返回32字节”当成认证成功,就会误读这个设计。
编写核对使用Node.js v24.19.0随附OpenSSL 3.5.7的ML-KEM实现;核对了上述种子公钥、封装例解封装与该组10个有效或修改密文的预期输出。它提供了指定案例的实现行为证据,不等同于NIST认证,也不证明所有输入、时间侧信道和部署路径都正确。教材不附实验程序或操作任务,公开输入仅用于说明材料之间的真实关系,不能作为生产密钥使用。
17.8 把后量子目标落实到具体数据路径
面对一项“后量子代理”声明,可以先把算法标识放回握手、记录与端点图。客户端提议过一个混合组,与服务器实际选择该组不同;实际选择该组,与整条访问路径每一段都采用同等保护又不同。协议能力、协商结果和完整架构必须分别有依据。
设C先与CDN边缘D建立后量子混合TLS,再由D与代理P建立另一条连接。第一段的秘密来源可以改善C—D的历史内容保护,但D作为TLS端点仍能得到该段应用字节,第二段采用什么交换也需单独判断。如果应用字节内部另有只由C与P解开的安全层,D才可能继续面对内层密文。外层使用了ML-KEM,不会改变它原本的解密端点。
再设C与P的直接通道采用后量子交换,但P向网站W发出明文HTTP。这仍可能保护C—P,却不能让P—W明文获得密码学保密。浏览器—W的HTTPS若存在,则又是一条独立会话。后量子和经典分析都必须逐层指出“谁得到明文”,不能只给客户端到网站的整张图盖一个统一标记。
协商回退也属于条件。为了兼容旧服务器,客户端可能同时允许混合组和纯经典组;认证正确可以帮助检测攻击者篡改握手,却不会自动禁止双方按策略共同选择纯经典组。如果某项安全要求必须使用后量子混合交换,接受策略就不能在选择经典组后仍声称满足该要求。回退是协议与政策的共同结果,不是所有回退都等同于一次成功降级攻击。
算法版本同样要落到字段。旧Kyber实验码点、最终ML-KEM参数、TLS正式组、某个自定义封装布局,不因内部都出现相同字样就互操作。实现还可能采用紧凑种子存储私钥,但在线发送展开公钥;把存储64字节误当成握手公钥64字节,会连开销与解析都算错。
还应追踪不同阶段实际投入的秘密。一次早期请求可能只依赖静态KEM公钥或缓存PSK;一轮响应以后才加入临时交换材料;批量记录则又使用方向独立的对称key。最终的安全声明应覆盖到具体字节区间,而不是仅根据连接最终达到的状态,把所有此前发出的字节追认为同等PFS。
性能结论也需分开:握手多发多少字节可以由布局计算,多做哪些运算可以由调用路径确认;吞吐、CPU占用和首字节时间则需要指定实现、硬件与网络条件。后量子算法不会使每个网络阶段自动变慢到同一比例,也不能因为记录仍用AES就忽略更大的握手与状态成本。本书仅在有相应证据时报告测量,否则保留为机制推导。
基础工具至此已足够:字节格式负责无歧义解释,运输负责提供流或数据报,认证与派生负责建立有明确身份和用途的秘密,AEAD负责记录保护。接下来的VLESS部分将从实际请求格式开始,把这些工具对应到Xray的调用路径,逐层解释TLS、REALITY、VLESS Encryption、Vision与XHTTP分别处理哪些问题及它们能否组合。