主要观点：过去几个月行业在量子后密码学方面有不少动作，NIST 标准化了 ML-KEM，浏览器和云提供商开始在 TLS 1.3 中采用混合密钥交换，作者解释了 TLS 1.3 混合密钥交换握手的实际情况，包括密钥生成、发送和使用等过程，同时指出混合密钥交换增加了ClientHello和ServerHello中的字节数，可能导致数据包碎片化，还提到了一些相关的浏览器支持和可能的解决方案。

关键信息：

• NIST 标准化 ML-KEM，浏览器和云提供商开始在 TLS 1.3 中使用混合密钥交换（主要是 X25519 与 Kyber768 或 ML-KEM768）。
• 客户端生成 KEM 和 X25519 密钥对，发送包含相关信息的ClientHello，服务器提取并生成自己的密钥，计算共享秘密等。
• 混合密钥交换增加了ClientHello和ServerHello的字节数，若添加更多 PQC 组可能会进一步增加。
• 一些浏览器已开始支持 ML-KEM，如 Chrome 131 计划于 2024 年 11 月 11 日稳定，Firefox 132 已支持。

重要细节：

• ClientHello中包含"X25519Kyber768Draft00"或"X25519MLKEM768"及"X25519"等信息，以及两个密钥共享。
• 服务器提取客户端密钥并计算共享秘密，使用 KEM 封装函数计算第二部分共享秘密和密文。
• 客户端获取服务器密钥并计算共享秘密，最终双方拥有相同共享秘密用于 TLS 1.3 密钥调度。
• 增加的字节数中，X25519 公钥 32 字节，ML-KEM-768/Kyber768 公钥 1184 字节。
• 可能的解决方案是使用新的[HTTPS/SVCB]DNS 记录来信号支持的密钥共享，但仍处于早期阶段。