Feature Request: Keyed mKCP obfuscation

[nametoolong]

Please describe the new feature you want in detail.

The current implementation of mKCP does VERY BADLY in hiding protocol fingerprint. Its obfuscation is solely based on the first four bytes (authentication tag) of a packet, which can easily be identified. Therefore, I propose the following changes to the mKCP transport.

1. Add a new field key to KcpObject. Its value should be a valid UUID. Therefore, if a KcpObject has a non-empty key property, we can assume it enables keyed obfuscation as described in this issue.

{
  "mtu": 1350,
  "tti": 20,
  "uplinkCapacity": 5,
  "downlinkCapacity": 20,
  "congestion": false,
  "readBufferSize": 1,
  "writeBufferSize": 1,
  "header": {
    "type": "none"
  },
  "key": "27848739-7e62-4138-9fd3-098a63964b6b"
}

2. Use some PRNG to generate key streams for packet obfuscation.

For cryptographic soundness, we should use a KDF combined with a stream cipher to implement obfuscation. This could also fix #2131.

For superior speed, XORing the obfuscation key with the packet authentication tag, and then feed it into a plain LFSR should suffice. It runs at less than 3 cpb on modern CPUs, so it should not pose any extra performance issue.

EDIT: XORing the obfuscation key with the packet authentication tag will not work well with plain LFSRs. An extra hash invocation per packet is necessary to generate the LFSR internal state.

The bottom line is we should rely on both the 4-byte authentication tag and the obfuscation key for key stream generation, so that simply XORing two packets will not reveal a pattern.

3. Add extra padding to small packets.

Currently all ACK segments have a length of an odd number (the documentation is outdated: Len of an ACK segment is actually 1 byte long), and for heartbeat segments it is a fixed 16 bytes. I believe it should work well to append a few bytes of LFSR output to the end of a packet.

[tuzhis]

+1，brilliant
Recently,once I use mkcp in linode, it will be blocked immediately, but use kcptun it work well

[kslr]

I have been planning to merge kcptun, but there are not enough people to do it

[anonymousbone]

@kslr
+10086 强烈期待官方组能尽快实现功能
目前除了kcp能用，其它v2ray的协议都被严重干扰。电信网络环境下任何时段都用非kcp协议都无法正常打开网页。
但是kcp协议现在也被干扰得非常厉害，但凡是通过ipv4地址连接vps用v2ray基本上这个地址存活时间不超过30分钟-1天。具体表现为先封端口，改端口后仍会再次被封端口。连续3次端口被封以后，会出现频繁丢包，大约持续丢包5-10分钟后服务器ip会被彻底墙掉。用大陆任何工具ping服务器都无法ping通，但外国服务器可以ping通。
目前状况只有v6地址可以存活下来，但是v6地址非常慢，仅是比tcp、quic、wss等快一点而已。
希望官方组能尽快改善，非常感谢官方组的付出和努力。

[nametoolong]

Kcptun is a nice and more bullet-proof transport, but mKCP is not completely broken or something beyond repair, nor does kcptun have a useful length padding mechanism, which is trivial to implement in current mKCP. IMO mKCP and kcptun should be implemented as two distinct transports, one for desperate people under desperate censorship, the other for those who seek for smooth connection and low latency.

mKCP obfuscation efforts can be done in a few days and then left to bit-rot (actually the mKCP code did not undergo much maintenance) and it would still work happily for very long, while it takes more resources to maintain a kcptun implementation. I would like to see a quick-and-dirty mKCP obfuscation implemented before the kcptun port. And my apologies here. I understand there are too few people working on this. Thank you for your dedication on this project.

[nametoolong]

@xiaokangwang Are there any plans to fix the issue that ACK segments have an odd length? It is also an obvious passive fingerprint. Some short padding of random length (maybe a PKCS5-style padding before encryption?) should suffice.

[github-actions]

This issue is stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 5 days