VMess 0-RTT Secure Encryption without relying on System Time

[APT-ZERO]

Hi, Is it possible to make VMess work without relying on System Time?

This is important for Iranian users becuase :

1. in 2022 Iran government canceled daylight saving time because of religious reasons! and all VMess configs was not able to work and still they will not work in summer if user's android device is old and have no new software updates, or if their windows device have no latest updates. https://techcommunity.microsoft.com/t5/daylight-saving-time-time-zone/iran-2023-time-zone-update-now-available/ba-p/3805707
2. All TLS configs are speed limited, everyone is using VLESS with no TLS. China's GFW may do same too

This is my Idea :

1. In the client side, hash the UUID [SHA256 or SHA256(MD5), dev must decide to do same in server] and make a curve25519 key pair from it
2. Server can have a curve25519 Keypair in the VMESS's Inbound section And must hardcode the server's curve25519 public key in client's Config for 0-RTT Or client must get an temporary from server in initial connection for more security! (not 0-RTT anymore)
3. Make a shared secret by client's public key and server public key And use the shared secret as AES or ChaCha20 Key to Encrypt the Data

What do you think about it?

[Fangliding]

vmess依靠时间戳进行验证 这是系统内置的 与时区或政府是否实行夏令时没有任何关系 只要确保系统时间准确即可

[APT-ZERO]

It has something to do with daylight saving time, we experienced it! Did Microsoft released an Update to Fix the nothing? No NTP servers time is changed because the gov canceled the DST But the client's OS will enable the DST by default because it's hardcoded in the operation system This will change time by 1 hour, client and system is not in sync anymore

In summer, each client with not-updated operation system must disable Auto Timezone and manually selecting their timezone and disable DST to be able to use VMESS configs But most of proxy creators just create Insecure VLESS HTTP because of this problem

[RPRX]

VMess 依赖时间戳是为了防重放攻击，你提出的设计类似于 REALITY 的 session id 部分，不检查时间戳时它自身不防重放攻击

且它只是比固定密码（客户端密码泄露可以全解密）好一点点，仍缺乏严格意义上的前向安全性（服务端私钥泄露可以全解密），且以原始形式发送 curve25519 public key 可被识别 https://github.com/net4people/bbs/issues/287#issuecomment-1718887813 ，~~虽然全随机数已经是最大的特征了~~

去年在讨论抗量子的密钥交换时我想过用它来设计 VLESS 的加密，~~但没那么急需所以鸽子中~~

如果你实在是不想依赖时间戳，可以看一下 https://github.com/shadowsocks/shadowsocks-org/issues/177 ，~~它通过奇特的方式实现了很多安全特性~~

依赖时间戳、不依赖密钥交换的可以看一下 https://github.com/shadowsocks/shadowsocks-org/issues/178

[Fangliding]

VMess 依赖时间戳是为了防重放攻击，你提出的设计类似于 REALITY 的 session id 部分，不检查时间戳时它自身不防重放攻击

且它只是比固定密码（客户端密码泄露可以全解密）好一点点，仍缺乏严格意义上的前向安全性（服务端私钥泄露可以全解密），且以原始形式发送 curve25519 public key 可被识别 net4people/bbs#287 (comment) ，~虽然全随机数已经是最大的特征了~

去年在讨论抗量子的密钥交换时我想过用它来设计 VLESS 的加密，~但没那么急需所以鸽子中~

如果你实在是不想依赖时间戳，可以看一下 shadowsocks/shadowsocks-org#177 ，~它通过奇特的方式实现了很多安全特性~

依赖时间戳、不依赖密钥交换的可以看一下 shadowsocks/shadowsocks-org#178

需要用时间戳防止重放主要是为了无状态0rtt 如果还加一轮协商又要多一个rtt了 实在需要的话可以学隔壁singbox加一个ntp outbound(为了方便放在vmess config也行)提供时间

[APT-ZERO]

That key exchange idea is great, can hardcode client key in server and server key in client, make a temporary key in client and use to encrypt first data, send encrypted client's public key along with data and server will send an temporary key and do same (Hardcoded public keys in both sides prevents MitM attacks) and can also have 2 random keys for each side and gen new every 1 minute + short time nonce system but to prevent replay of first packets there is no choice except timestamp (0-rtt) or challenge & response (1-rtt) Can also add obfuscate options too Compress data using Gzip / Brotli or make data look like them and use the http header as well, firewall will not decompress each one because most of services and all browsers supports them

[APT-ZERO]

But for vmess time sync problem, NTP setting like Clash.Meta can solve the problem

[yuhan6665]

answered