REALITY protocol: Add optional Post-Quantum ML-DSA-65 verification for cert's ExtraExtensions

[RPRX]

REALITY 抗量子更新第二弹来袭！本次更新为 REALITY 协议加上了可选的、抗量子的 ML-DSA-65 签名验签机制，向后兼容

未来可能的威胁

虽然此前 REALITY 已支持 X25519MLKEM768，保护现在的通讯数据抵抗未来的量子计算机威胁，但若攻击者拿到了 REALITY 的客户端配置，即 X25519 public key (password)，虽然现在不威胁数据安全，甚至无法用来验证某个连接是否是 REALITY，但可以等到未来用量子计算机反推出对应的私钥，进而对未来的 REALITY 连接进行 MITM。（对 TLS 的证书机制来说也是如此，RSA、ECDSA 都不抗量子，可在未来被 MITM，甚至无需拿到客户端配置，毕竟就没有；但即使攻击者拿到了 REALITY/TLS 服务端私钥，以前的通讯数据仍然安全，这就是前向安全；但对于 SS、VMess 等协议，拿到客户端配置的话现在即可解密以前、以后的所有流量）

未雨绸缪的应对

为了避免攻击者拿到 REALITY 客户端配置再等到未来的量子计算机破解 X25519 后对未来的 REALITY 连接进行 MITM，REALITY 协议新增抗量子的 ML-DSA-65 签名验签机制：执行 ./xray mldsa65 生成 ML-DSA-65 密钥对，服务端持有 ML-DSA-65 私钥（配置名 mldsa65Seed），处理连接时会对“cert's signature + raw Client Hello + raw Server Hello”的组合进行额外签名并填到 cert's ExtraExtensions；客户端若持有 ML-DSA-65 公钥（配置名 mldsa65Verify），在原有的 REALITY 证书验证阶段会进行额外验证。由于 ML-DSA-65 被设计为抵抗量子计算机，即使攻击者拿到了客户端配置即公钥，也无法在未来反推出私钥进而 MITM。

对兼容性的追求

若 REALITY 服务端已配置 mldsa65Seed，但客户端未配置 mldsa65Verify，只是不会进行“额外验证”环节，仍可正常连接。

VLESS 分享链接标准 #716 已更新 REALITY pqv，若旧客户端未识别此参数，仍可连接上配置了 ML-DSA-65 的服务端。

注意 ML-DSA-65 的签名为 3309 字节，所以目前需选择 RSA 证书的目标网站，而不能选择 ECDSA 证书的目标网站，但这在未来不会是问题，因为未来抗量子签名的证书也会很长，虽然现在 TLS 还没有公开的这种证书，所以 REALITY 又一次走在了时代前沿；还有，我没选 ML-DSA-44 是觉得来都来了不差这八百字节；此外，FIPS 206 的 FN-DSA 签名较短，但还没有出草案。

所以为了实现较为完美的抗量子，你需要寻找 X25519MLKEM768 密钥交换 + 证书链总长度 3500 以上的目标网站（偷自己的话一定要用 fullchain，否则证书链总长度不够），现在很少，但好在 X25519MLKEM768 正在迅速普及，且在量子计算机的威胁下 RSA 会比 ECDSA 多活两年，所以半年后可选网站会多很多，届时新版代理客户端也普及了。

执行 ./xray tls ping www.example.com 可查看目标网站是否已支持 X25519MLKEM768、证书链总长度是否有 3500+。

REALITY 服务端、客户端配置填入 "show": true 即可输出 X25519MLKEM768、ML-DSA-65 相关日志，以确定它们被用到。

最后，为了防止未来的浏览器指纹中只有 X25519MLKEM768 而没有 X25519，本次更新 session id 还对这种情况做了兼容。

NFT

好久没有标价 NFT 了，本次放出了 59 个 0.01 ETH 的 REALITY NFT，以及 0.19、0.2 的 Project X NFT 各一个，希望大家支持：

https://opensea.io/collection/xtls

[RPRX]

https://t.me/projectXtls/953 评论区文摘

太厉害了，只有reality会有拿到key被解密的风险是吗？

你这什么理解能力，不是被解密是被 MITM，且前提是拿到 REALITY 客户端配置+未来的量子计算机。TLS 也是这样，且不用拿到客户端配置，因为就没有。SS、VMess 更是拿到客户端配置的话，现在就能解密以前、以后的所有流量，不用等量子计算机。

不是的，我是说只是reality需要配置吗？像是vless xtls rprx vision 自建web受这个拿到key的影响并且需要配置吗？

你用 TLS 的话，现在还没抗量子证书，等死就好了

没有啊，最新xray core搭配tls1.3不是已经默认支持防量子解密了吗？而且已经有抗量子配置了就不存在等死了

MITM 是量子计算机把你 TLS 证书给破解了，无关 X25519MLKEM768

REALITY 这次的更新就是相当于上抗量子证书，TLS 还没有

明白了，那意思还是要上rwality才能享受了，如果能像上次X25519MLKEM768一样全协议适配就好了，因为真的没有动力去折腾，加上人在墙外只是为了隐私去代理的，隐私又包含防量子解密

那只能上reality才能了

因为 TLS 证书的换代要很长时间才能铺开，要往设备里加根证书，要很久，但 REALITY 是我们自己的协议，随便造

明白了，感谢科普，祝一切顺利

---

自主可控

---

太激进了，考虑这么长远😂

---

@Fangliding

(这个是未来的技术攻击未来的连接 而且前提是客户端公钥泄露 直到有量子计算机真的可以用公钥逆向私钥之前 无法被MITM (如果是后量子密钥交换 现在的数据在未来也是安全的)

---

有没有扛量子第三弹

可能几年后会有，如果到时候 TLS Client Hello 能多塞点东西

👍求解答，之前看有讨论说可以通过两条独立连接实现MITM，这个会做吗？

下个月可能，主要是为了彻底解决 post-handshake records 问题

👍👍👍 牛逼

---

这下真遥遥领先了

[gfw-killer]

Thank you dear RPRX
Could you please inform us about the process of VLESS Encryption
As it's necessary for CDN(TLS or non-TLS) and non-TLS setups

net4people/bbs#448 (comment)

VMess encryption is static password + symmetric encryption, and you can decrypt all previous and future traffic once you have the client password
VLESS encryption is quantum-resistant key exchange + symmetric encryption, and it is forward-secure. I can also make it so that RTT is not sacrificed.

net4people/bbs#448 (comment) (14 Feb 2025) (5 months ago)

VLESS encryption was partially written last year and will be released within this month

net4people/bbs#448 (comment)

I do plan to restrict VLESS without any encryption after VLESS encryption is launched

And what is your opinion about the community ideas for VLESS Encryption

1. A partial encryption; VLESS can have a partial encryption that detects known encrypted traffics (e.g. TLS), and encrypt only the plaintext parts (e.g. TLS ClientHello) and Unknown traffics to prevent double encryption and waste of resources

2. Availability of secure but lightweight encryptions like Ascon for Mobile and IoT devices

[RPRX]

恶意提问，不利于团结的话不要说，禁止合订，历史文件不具有现实意义

[w0l4i]

恶意提问，不利于团结的话不要说，禁止合订，历史文件不具有现实意义

we need lightweight as much as it's possible please

[gfw-killer]

恶意提问，不利于团结的话不要说，禁止合订，历史文件不具有现实意义

Those ideas are reasonable

A partial encryption for known encrypted traffics like TLS, as TLS only leaks the dest IP, Port and SNI to the MITM(GFW or CDN or both)
Or a lightweight to not make pressure on low-end devices and consume less battery
Or both

I didn't say to not support a good encryption like AES and ChaCha20 or full encryption mode
I have no bad intentions

[RPRX]

@gfw-killer 我只是在玩梗，事情要一件件做，Vision Seed 和 ECH 都眉清目秀的，下下个版本的重点是这俩

[Fangliding]

只看最后一级证书的算法是否不准确 reality就返回一个单级证书 但是平时网站返回的是一个完整证书链 三级证书的自己的公私钥和授权签名算法都不一样 输出整个长度这样好一点吧 比如谷歌的虽然全链ECC但是它整个证书链也有五千多(cf的也是全链ECC但是只有两千五btw 不知道长在哪)

[Meo597]

恶意提问，不利于团结的话不要说，禁止合订，历史文件不具有现实意义

REALITY 做不到 0-rtt
这样 HK CN2-GIA 约等于美西了
本来想用 MUX 配合路由规则将就一下，发现会有特征

无意间发现了 xtls-rprx-switch
我是新来的，不利于团结的话我来说：这么好的东西为啥没实现？

[w0l4i]

will switch eta ?

[w0l4i]

it was great 👍

[RPRX]

只看最后一级证书的算法是否不准确 reality就返回一个单级证书 但是平时网站返回的是一个完整证书链 三级证书的自己的公私钥和授权签名算法都不一样 输出整个长度这样好一点吧 比如谷歌的虽然全链ECC但是它整个证书链也有五千多(cf的也是全链ECC但是只有两千五btw 不知道长在哪)

之前就想过直接输出长度，但实现不了，peerCertificates 里就一个证书，而 verifiedChain 里应该还包含 root

反正根据观察 RSA 的证书消息一般都 4000+，刚好够，ECDSA 的不够

[RPRX]

恶意提问，不利于团结的话不要说，禁止合订，历史文件不具有现实意义

REALITY 做不到 0-rtt 这样 HK CN2-GIA 约等于美西了 本来想用 MUX 配合路由规则将就一下，发现会有特征

无意间发现了 xtls-rprx-switch 我是新来的，不利于团结的话我来说：这么好的东西为啥没实现？

目前配合 XHTTP 就行了，Vision Seed 也会支持它

[Fangliding]

只看最后一级证书的算法是否不准确 reality就返回一个单级证书 但是平时网站返回的是一个完整证书链 三级证书的自己的公私钥和授权签名算法都不一样 输出整个长度这样好一点吧 比如谷歌的虽然全链ECC但是它整个证书链也有五千多(cf的也是全链ECC但是只有两千五btw 不知道长在哪)

之前就想过直接输出长度，但实现不了，peerCertificates 里就一个证书，而 verifiedChain 里应该还包含 root

反正根据观察 RSA 的证书消息一般都 4000+，刚好够，ECDSA 的不够

peerCertificates 里不止一个 只是最后一级域名证书的位置不一定 如果放在第一个的话 按 if len(cert.DNSNames) == 0 → continue 这样的话那第一个被遍历到之后就会直接输出导致它只会输出最后一级证书的长度 如果放在最后的话就可以正常遍历到 又或者不continue强制让它遍历完再输出也是完整长度

[RPRX]

peerCertificates 里不止一个

我这里测试都是只有一个 不知道啥原因

[Fangliding]

按之前的说法golang是不会自动补全上级证书的 没fullchain只有一层的话验证都过不了

[RPRX]

按之前的说法golang是不会自动补全上级证书的 没fullchain只有一层的话验证都过不了

反正我测试那个域名用 WireShark 看是长度 4000 左右的证书消息，但 peerCertificates 里只有一个长度 2000 左右的证书，且没有第二个证书，你测试看看

[Fangliding]

哪个域名

[RPRX]

哪个域名

这个不方便说，总之你找些域名测试下吧，如果能直接输出所有证书总长度当然就更好了

[RPRX]

@Fangliding 至少 ./xray tls ping 证书那块不是循环吗，我就没见过输出过第二个证书

[RPRX]

#4933 (comment)

[RPRX]

还有我本来以为 RSA 的证书，整个链加起来基本有 4000+，经反馈得知不是，ML-DSA-44 的话少 800 字节，兼容的网站更多

不过治标不治本，我看那些 ECC 的都是 1200+ 而已，没必要降低安全标准，还是等 FN-DSA 吧

[MoRanYue]

根据网站证书需求：

注意 ML-DSA-65 的签名为 3309 字节，所以目前需选择 RSA 证书的目标网站，而不能选择 ECDSA 证书的目标网站，但这在未来不会是问题，因为未来抗量子签名的证书也会很长，虽然现在 TLS 还没有公开的这种证书，所以 REALITY 又一次走在了时代前沿；还有，我没选 ML-DSA-44 是觉得来都来了不差这八百字节；此外，FIPS 206 的 FN-DSA 签名较短，但还没有出草案。

似乎，github.io的证书符合要求呢：

$ xray tls ping github.io
TLS ping:  github.io
Using IP:  185.199.110.153:443
-------------------
Pinging without SNI
Handshake succeeded
TLS Version:  TLS 1.3
TLS Post-Quantum key exchange:  true (X25519MLKEM768)
Certificate chain's total length:  4645 (certs count: 3)
Cert's signature algorithm:  SHA256-RSA
Cert's publicKey algorithm:  RSA
Cert's allowed domains:  [*.github.io *.github.com *.githubusercontent.com github.com github.io githubusercontent.com www.github.com]
-------------------
Pinging with SNI
Handshake succeeded
TLS Version:  TLS 1.3
TLS Post-Quantum key exchange:  true (X25519MLKEM768)
Certificate chain's total length:  4645 (certs count: 3)
Cert's signature algorithm:  SHA256-RSA
Cert's publicKey algorithm:  RSA
Cert's allowed domains:  [*.github.io *.github.com *.githubusercontent.com github.com github.io githubusercontent.com www.github.com]
-------------------
TLS ping finished

另外，似乎openlm.ai亦满足需求：

$ xray tls ping openlm.ai
TLS ping:  openlm.ai
Using IP:  185.199.110.153:443
-------------------
Pinging without SNI
Handshake succeeded
TLS Version:  TLS 1.3
TLS Post-Quantum key exchange:  true (X25519MLKEM768)
Certificate chain's total length:  4645 (certs count: 3)
Cert's signature algorithm:  SHA256-RSA
Cert's publicKey algorithm:  RSA
Cert's allowed domains:  [*.github.io *.github.com *.githubusercontent.com github.com github.io githubusercontent.com www.github.com]
-------------------
Pinging with SNI
Handshake succeeded
TLS Version:  TLS 1.3
TLS Post-Quantum key exchange:  true (X25519MLKEM768)
Certificate chain's total length:  2573 (certs count: 2)
Cert's signature algorithm:  SHA256-RSA
Cert's publicKey algorithm:  RSA
Cert's allowed domains:  [openlm.ai www.openlm.ai]
-------------------
TLS ping finished

[RPRX]

@MoRanYue github.io 可以，openlm.ai 不行，因为证书链总长度需要 3500+