请问有没有搞过国密 quic 的老哥？求助！ 国密 ！ QUIC！

国密是国密 quic 是 quic ，感觉你应该找国密 tls ？

光国密我就挺烦，但我觉得开了国密之后再加 QUIC 应该还好

@ntedshen +1
我也是这么理解的，国密只是用于 TLS 里的加密/哈希算法套装而已，和 QUIC 本身没关系

看到国密，我第一个反应是 xquic 应该支持了吧，不过跑去看了下，好像请求支持国密的 issue 还在。
看起来 babaSSL 已经支持了国密算法，quic 协议栈想支持，应该比较简单才对（ babaSSL 改名叫 tongsuo 了啊，感觉名字有点 gay 里 gay 气的）

我从网上看到的思路是把对应的加密算法，头保护算法，摘要算法，替换成国密的 sm2-sm4 。但不会改，借助 ai 尝试了一周，自认技术菜，改不了。

https://njet.org.cn/cases/http3_ntls_support/
这里有个牛人说修改了 xquic 使其支持国密，但没有提供代码，网上只找到这么一个实现。

我的理解是这样的：
国密算法： 就是哪些 sm2 ，sm3 ，sm4 那些，这些算法实现相对容易(不考虑性能的话)，openssl 在 1.1 就支持了 sm2 ，sm3 ，sm4
国密 TLS： 在原有的 TLS 加密套件基础上，添加使用国密的加密算法，头保护算法，摘要算法的加密套件，这时候就要在大家常用的 openssl 的 TLS 接口内部去兼容国密的加密套件， 北大的 gmssl 就实现了这些。
支持国密 TLS 的 QUIC： 上边提到的 gmssl 只丰富了了 tcp/http1/http2 上用 tls 接口， 而 quic 调用 TLS 接口的时候用法略有不同，当前 openssl3.5 已经支持 quic 的接口，但是只支持
● TLS_AES_128_GCM_SHA256
● TLS_AES_256_GCM_SHA384
● TLS_CHACHA20_POLY1305_SHA256
这三种加密套件。

阿里巴巴的铜锁项目成员提交了 RFC8998 ，提出了 TLS_SM4_GCM_SM3 ，TLS_SM4_CCM_SM3 这两个加密套件。并且 tongsuo 支持这两个加密套件，但遗憾的是同样是他们护的 xquic 却不支持（不知道这么久了为什么还不支持，担心是不是有坑，现在的设计还不完善等）

幸运的是 njet 项目宣称支持了国密的 QUIC ，但它只能做服务端，我还需要一个客户端。 现在能做的就是尝试借助 deepwiki.com 和 sonnet4 修改 xquic 了。

我非常希望有个人能告诉我，现在 quic 上使用国密算法设计尚且有问题，不用瞎搞了。

@cuihua #6 之前做过，不过没有做 quic ，我们只说 tls ，因为国密的 TLS 过程，需要两对密钥参与，所以其握手过程和普通的 TLS 不同（协议不一样），所以需要专门的 openssl 层进行适配，不单纯是加密套件至此了就可以了，这也是国密的难搞的点。再说传输层，其实 tls 层是在传输层之上，应用层之下的，一旦协商完成后，底层是用什么承载(TCP 、UDP)的反而不重要了，我之前搞的时候，因为是 java 应用，使用的是 alibaba 搞的一套 tls 协议做的。但是同样没有用到 quic ，不知道你为何一定要使用 quic

@cuihua #6
> QUIC 则将 TLS 1.3 (或更高版本) 直接集成到协议内部。这意味着：
> 强制加密：QUIC 连接默认都是加密的。没有“明文”的 QUIC 。这提高了互联网的整体安全性。
整合握手：QUIC 将传输层握手和 TLS 握手合并为一个过程。这显著减少了建立安全连接所需的往返时间。
独立于底层协议： 传统的 TLS 依赖于 TCP 的可靠传输。在 QUIC 中，TLS 握手消息被封装在 QUIC 自己的帧中，QUIC 自身负责这些帧的可靠传输和排序，而不是依赖于 UDP 。

看 AI 解释，TLS 层是在 quic 之上的，也就是先有 quic(解决信道和传输问题)，再由 tls 层进行帧数据加密的，如此这样的话，那其 TLS 层就完全和 quic 解耦了，理论上是完全可行的。

@ZGeek #8 不懂想问一下，有点奇怪为什么“看 AI 解释，TLS 层是在 quic 之上的”，但前面的两个“>”似乎并不支持？。明明 quic 是内置 tls 进行密钥交换和数据加密的，并没有单独的 tls 层的呀

@ranaanna #9 所谓的内置，也是分层了的，quic 协议使用底层的 udp ，模拟之前的链路层，使用自身的协议，模拟了 tcp ，再使用 tls ，构建了帧数据加密（帧元信息本身是无法加密的），所以，看似没有分层，其实还是分层了的，只是说这 2 件事（模拟了 tcp+构建加密通道）在一个 quic 中完成罢了

国密的密钥交换协议和 TLS 可以认为是完全不兼容的，不单纯只是套件层的扩展那么简单，在 hello 阶段就能发现不一致，不但简单的对 TLS 的扩展，你可以认为是另一个 TLS ，是从密码算法到协议的全方位抄袭+改造，搞得有些不伦不类

@swananan 关注你 github 啦，日记也拜读，可以交流下哈

@ZGeek 如果 tongsuo 支持了国密，那 quic 引入 tongsuo ，从而支持 国密，应该不麻烦吧。毕竟 quic 只通过 Crypto frame 为 tongsuo 提供可靠字节流来完成国密协商

额，好像回复错了人，想回复给 op 的

最新进展：
我使用 njet 作为服务端，修改了 xquic 的代码，使用它的 demo 可以连接 njet 服务器，通过 wireshark 抓包可以看到使用 TLS_SM4_GCM_SM3 套件进行通信。

存在的问题：
1. 只有数据加密的时候使用了国密，握手阶段还是国际算法。 不过感觉也不难，只是现在还没搞明白什么叫密钥派生。
2. 最好把 njet 中对国密的支持移植到 nginx 最新 stable 上， 感觉也不难。

难题：
领导让我证明我确实是用国密算法加密的。
我尝试用 wireshark 解密，但 wireshark 应该是不支持国密的。

@cuihua wireshark 是支持国密解密的，可以参考 https://openanolis.github.io/whitebook-shangmi/wireshark.html