Post #1015

💬New comment onXray-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.