REALITY 的文章是个悲剧，当时本来想写文章，都怪刚放出代码每天被开十个 issue 问这问那，真的很烦真的很想骂人，还有傻逼要对线，结果我自己关于 REALITY 的说法全分散在各个 issue 以及频道里了，所以 REALITY 的文章不如去找 AI 总结吧，不过还有很多内容我还没说过
Telegram
Koubi Artúr Szkoufíld in Project X
REALITY 的文章什么时候能公布呢
感觉有文章说明的话能用整合好的方式消除很多疑惑
感觉有文章说明的话能用整合好的方式消除很多疑惑
有人 PR 了 race dialer，yuhan 在研究 datagram，我想改 Nginx QUIC
Telegram
空白(🎀ᗜ`‸´ᗜ🌸) in Project X
所以什么时候能稳定下来（
其实我在想，既然他不写代码了，你能不能去 PR 一个 127.0.0.1 并详细说明为什么不能允许用户通过明文 HTTP 访问面板、不能留下该选项
Telegram
Nikita Korotaev in Project X
I didn't make any changes. If you see any updates after v2.5.0, they were not made by me.
Forwarded from Masoud
Interesting😁If the translation is correct
a few months ago when I was discussing the blocking of Reality by Iran's GFW in a group someone told me to use Reality through a SOCKS5, and it wouldn't get blocked
a few months ago when I was discussing the blocking of Reality by Iran's GFW in a group someone told me to use Reality through a SOCKS5, and it wouldn't get blocked
当我们建议面板删掉明文 HTTP 选项时，这就是一些伊朗人的理由之一
但是你那里 fully random SS 和 plain HTTP 都不封也很难绷啊，毕竟你们那 SS 就是裸奔，密码都被 plain HTTP 面板交给 GFW 了，直接解密
但是你那里 fully random SS 和 plain HTTP 都不封也很难绷啊，毕竟你们那 SS 就是裸奔，密码都被 plain HTTP 面板交给 GFW 了，直接解密
Telegram
M in Project X
U said a few times that iranians told that tls was unstable,this is weird cuase i never had any issues with tls personally,the only thing is some isp have weird sni rules(only some of them) and becuase of that, full random ss or plain http work better(sometimes)…
不会加就是不会加，原产于 Xray 的协议总想着在其它软件上也能用，你们是有什么 NTR 的癖好吗，他们的实现、更新也是没有任何保证的
你要想安稳用 Xray 的协议就直接用 Xray，别整天想着整花里胡哨的
你要想安稳用 Xray 的协议就直接用 Xray，别整天想着整花里胡哨的
Telegram
Frederic Liu in Project X
sb不至于吧，sb更新协议不是蛮快的吗，不过n9i最近忙着搞1.12和1.11的当下版本
安卓上 NG 不够你用吗，iOS 上更是一堆软件是 Xray-core，怎么就少了
Telegram
️ in Project X
xray core 移动端 还是太少
VLESS 的加密是抗量子公私钥，且不会增加 RTT，机制类似于 REALITY 的 session id，并且 GFW 拿到客户端公钥没用，服务端私钥不泄露就不会被解密，正好明文 HTTP 面板不更新了不然这私钥是保不住了
Telegram
Keith Chai in Project X
是啊，ss2022和vmess都是全加密协议，vless出加密我有点不太理解
VMess 和 SS 的加密都是对称加密，无前向安全，GFW 拿到客户端密码就能把以前的所有流量都解密了，我几年前就强调过，让我来设计加密的话肯定是 REALITY 这种带公私钥的，REALITY 有 TLS 的前向安全，不过私钥一定不能泄露啊，所以面板明文 HTTP 传私钥是真的蠢
Telegram
gh0st in Project X
There has been a lot of news and information about vmess encryption leaks, who else thinks that ss and vmess are secure, I sympathize with you. Vless protocol is not perfect, but with all the features that encrypt it can be so to speak, as the person wrote.
Telegram
𝕆𝕓𝕛𝕖𝕔𝕥 𝕊𝕙𝕒𝕕𝕠𝕨 in Project X
现阶段量子加密和前向安全不可兼得也是一个问题...
现在的抗量子指的是密钥交换阶段，后面仍是对称加密，不会增加损耗
Telegram
𝕆𝕓𝕛𝕖𝕔𝕥 𝕊𝕙𝕒𝕕𝕠𝕨 in Project X
REALITY 的确有 (与 TLS 一致的) 前向安全性
但是 VLESS 的加密层如果采用抗量子加密, 性能 (使用非对称加密) 会有很大损耗
但是 VLESS 的加密层如果采用抗量子加密, 性能 (使用非对称加密) 会有很大损耗
你再去看看，Chrome 的 TLS 已经默认包含 X25519Kyber768 了
并且 VLESS 自身的加密和外层是啥没有关系
并且 VLESS 自身的加密和外层是啥没有关系
Telegram
𝕆𝕓𝕛𝕖𝕔𝕥 𝕊𝕙𝕒𝕕𝕠𝕨 in Project X
量子公钥太大了 以至于难以嵌入到 VLESS 目前所依赖的 TLS Handshake 里
我看了下 Go 1.24 有这个，上述 VLESS 加密有望这几天推出
我现在只担心 Chrome 也改成这个后，已经停更的 uTLS 是个问题
我现在只担心 Chrome 也改成这个后，已经停更的 uTLS 是个问题
Telegram
O_o $_$ in Project X
但是golang的X25519MLKEM768似乎没搞完🧐
是单独添一个加密层，目前决定用抗量子的 X25519MLKEM768
1-RTT 的话有前向安全，0-RTT 的话私钥不泄露也是安全的，别明文传
1-RTT 的话有前向安全，0-RTT 的话私钥不泄露也是安全的，别明文传
Telegram
𝕆𝕓𝕛𝕖𝕔𝕥 𝕊𝕙𝕒𝕕𝕠𝕨 in Project X
好 明白了 最开始误解了
我以为是给 VLESS 单独添一个加密层
我以为是给 VLESS 单独添一个加密层
我觉得倒是可以设计成会话恢复，至于防重放很简单，我本来在 SS 那边说的是给明文结构加个时间戳，但这个被 SS2022 用了我就不想用了，我觉得我可以发明一个滑动窗口防重放、无需对时
还有 VLESS 加密只考虑加密安全，不考虑对付 GFW，这不是它的用途
还有 VLESS 加密只考虑加密安全，不考虑对付 GFW，这不是它的用途
Telegram
𝕆𝕓𝕛𝕖𝕔𝕥 𝕊𝕙𝕒𝕕𝕠𝕨 in Project X
私钥不泄漏确实是安全的
但是如果采用了 TLS13 的会话恢复 如何应对重放?
但是如果采用了 TLS13 的会话恢复 如何应对重放?
比如说只记录 100 个连接头以防重放，一开始是第 1-100 条连接，后面慢慢滑到第 201-300 条连接，小于 201 的就直接扔了，无需对时
Telegram
𝕆𝕓𝕛𝕖𝕔𝕥 𝕊𝕙𝕒𝕕𝕠𝕨 in Project X
滑动窗口 无需对时🤔怎么说?
时间戳那不是要对时嘛，我这滑动窗口无需对时，这就申请专利
Telegram
风扇滑翔翼 in Project X
一个一直在递增的东西 给它取个名字吧 就叫时间戳怎么样
都 2025 年了还想着用非 TLS 加密过墙呢？VLESS 加密不是给 GFW 看的
Telegram
𝕆𝕓𝕛𝕖𝕔𝕥 𝕊𝕙𝕒𝕕𝕠𝕨 in Project X
我的意思不是避免重放带来的影响
而是如何向重放方应答 以免暴露
而是如何向重放方应答 以免暴露