等不来了

比x-flutter还更没有盼头🤣

我xray tun、switch、vision seed、什么时候能等到呢

下个月出完 VLESS 加密就出 Vision Seed，然后是 TUN 和配置订阅

聊到 QUIC，把 REALITY 那一套搬到 QUIC 上不存在技术难度，问题一是 QUIC 允许连接迁移，会暴露这不只是端口转发，问题二是服务端 quic-go 不太符合 Nginx QUIC 等其它软件的特征，感觉时机尚未成熟

隧道来喽（通过代理协议来端口转发）

Tunnel: https://github.com/XTLS/Xray-core/pull/4968

这也提醒各位记得在服务端 block "geoip:private"，防止用户通过代理直接穿透到服务端的内网

本次久违地放出了一些 REALITY NFT 和几个 Project X NFT

请支持一个 REALITY NFT：https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/2

如果你有余力，请支持一个 Project X NFT：https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/1

Tunnel 入站新增 portMap 配置项，可以按本地监听端口指定走代理后的目标地址/端口，优先级高于原有的 address/port，已更新 https://github.com/XTLS/Xray-core/pull/4968 正文与配置示例

Tunnel inbound portMap 与 TLS ECH client improvements

Latest: https://github.com/XTLS/Xray-core/releases/tag/v25.8.3

本次久违地放出了一些 REALITY NFT 和几个 Project X NFT

请支持一个 REALITY NFT：https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/2

如果你有余力，请支持一个 Project X NFT：https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/1

💬 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.

这下 PQ PFS 0-RTT 的 VLESS 加密也可选全随机数外观了，基本只 XOR 占比万分之六的 data header，没啥性能成本，唉，全随机数

https://github.com/XTLS/Xray-core/pull/4952#issuecomment-3183275526

代码运行效率肯定是首要的，除非硬盘不够，没必要一边装着几十个 G 的学习资料另一边对着代理软件抠这 4M

🔨 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

刚刚 IPv4/TCP/443 正常网站也全挂应该是 GFW 配置错误，现已恢复

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

XHTTP 继上次 CF gRPC 时好时坏后，再次证明了自己的价值，赢！

💬 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.