Project X Channel
18.3K subscribers
24 photos
1 file
609 links
Download Telegram
Forwarded from O⁠_⁠o $_$
Project X Channel
我准备等mihomo支持xhttp之后就换xhttp
比x-flutter还更没有盼头🤣
Forwarded from Sorcerer
Project X Channel
那你有得等了,Xray 配置订阅都出了估计都等不到 mihomo
我xray tun、switch、vision seed、什么时候能等到呢
4
Forwarded from Project X Channel
Project X Channel
我xray tun、switch、vision seed、什么时候能等到呢
下个月出完 VLESS 加密就出 Vision Seed,然后是 TUN 和配置订阅
🔥38🎉102
Forwarded from Project X Channel
总之一切都在按照 v25.3.6 写的计划稳步推进,做好自己该做的事就行
24
聊到 QUIC,把 REALITY 那一套搬到 QUIC 上不存在技术难度,问题一是 QUIC 允许连接迁移,会暴露这不只是端口转发,问题二是服务端 quic-go 不太符合 Nginx QUIC 等其它软件的特征,感觉时机尚未成熟
👀38👍1541😁1
Forwarded from GitHub
💬 New comment on Xray-core#4952 chore: remove vmess from core.
by @RPRX

@gfw-killer 我更新了 VLESS 加密的设计方案,像 QUIC 一样跨二元组复用 sharedKey,兼顾 0-RTT 与前向安全,测试代码已跑通

本周末将正式推出 VLESS 加密,主要特性如下:
- 抗量子的认证与加密,0-RTT
- 前向安全,重放防护
- 更优的性能,且可选 XTLS

全面基于 [ML-KEM-768](https://github.com/XTLS/Xray-core/pull/4992#issuecomment-3156162191)、HKDF(SHA256)、AES-256-GCM/ChaCha20-Poly1305

Reply to this message to post a comment on GitHub.
👍7210🔥95
这下 PQ PFS 0-RTT 的 VLESS 加密也可选全随机数外观了,基本只 XOR 占比万分之六的 data header,没啥性能成本,唉,全随机数

https://github.com/XTLS/Xray-core/pull/4952#issuecomment-3183275526
🔥30😁11👍62👀1
Forwarded from 🇺🇦 QuotLy
This media is not supported in your browser
VIEW IN TELEGRAM
👍27😁16🎉1
Forwarded from Project X Channel
代码运行效率肯定是首要的,除非硬盘不够,没必要一边装着几十个 G 的学习资料另一边对着代理软件抠这 4M
😁59👍111
Forwarded from GitHub
🔨 1 new commit to Xray-core:vless:

84835be: Support VLESS Encryption (native/random) + XTLS Vision + Any Transport like XHTTP (UDS or not) + TLS/REALITY

https://github.com/XTLS/Xray-core/pull/4952#issuecomment-3200720109 by RPRX
👍32🔥53😁1
刚刚 IPv4/TCP/443 正常网站也全挂应该是 GFW 配置错误,现已恢复

这提醒了大家必须要有一个 XHTTP over CDN 备用,有很多 IPv6 可选,也可以 UDP/QUIC,关键时刻防失联

XHTTP 继上次 CF gRPC 时好时坏后,再次证明了自己的价值,赢!
😁589
细思极恐,该不会是因为你们平时偷那些域名导致那些 SNI 都被标记了,然后刚刚 GFW 想上点强度就封了它们所关联最多的 IP 和端口,IPv6 还有些活着是因为封不完,QUIC 是因为偷的少或另一套审查系统
👀37😁143
话说你们这些玩中转的是不是会合租端口,就是说共用一个入口端口

不然 SS 系列很喜欢搞那些 relay 是为了啥,调研一下
👀18🔥2😁2
Forwarded from GitHub
💬 New comment on Xray-core#4952 chore: remove vmess from core.
by @RPRX

https://github.com/XTLS/Xray-core/commit/ad7140641c44239c9dcdc3d7215ea639b1f0841c 第二版来了,~~也是最终版,感觉又写一套加密人已经麻了~~,MLKEM768X25519 临时密钥交换,中转无限串联,每一级都是基于 X25519 或 ML-KEM-768 认证(最后一级现在可选 X25519 了,公钥很短,~~毕竟未来的量子计算机无法逆转今天的认证~~)

为了避免上版中看似复杂的 XOR 并简化代码,前向安全的密钥交换和 ticket 被 AEAD 了,拿服务端配置才能解,~~虽然也破解不了~~

除了原生外观要不要允许两端先发 padding 消息还要想一下外,~~应该没啥要改的了~~,有兴趣的可以先编译出来测试,晚点 PR

---

服务端配置:(原生外观 / 只 XOR 公钥 / 全随机数。只允许 1-RTT 模式 / 同时允许 1-RTT 模式与 600 秒复用的 0-RTT 模式)
"decryption": "mlkem768x25519plus.native/xorpub/random.1rtt/600s.(X25519 PrivateKey).(ML-KEM-768 Seed)..." 


客户端配置:(native/xorpub 的 XTLS 可以 Splice。只使用 1-RTT 模式 / 若服务端发的 ticket 中秒数不为零则 0-RTT 复用)
"encryption": "mlkem768x25519plus.native/xorpub/random.1rtt/0rtt.(X25519 Password).(ML-KEM-768 Client)..." 


/ 是只能选一个,后面 base64 至少一个,无限串联,使用 ./xray x25519./xray mlkem768 生成,替换值时需去掉括号

"mlkem768x25519plus" 代表未来可以无感并联其它密钥交换,"xorpub" 只 XOR 公钥的外观为前面全随机数、后面 23 3 3

支持 XHTTP 等有传输层时的 XTLS,代理 TLSv1.3 时不会二次加密,"random" 全随机数外观后面会只 XOR `23 3 3`,成本极低

Reply to this message to post a comment on GitHub.
👍417😁3🎉32