Proposal: Multi-user support in Shadowsocks protocol

Background

Shadowsocks protocol doesn't support multi-user as designed. To support multi-user on a single port, a naive approach on Shadowsocks server is to try to decode the incoming connection with all users' key, until one key succeeds. This way is quite time consuming when user base is large.

Here is a proposal to balance server work load and compatibility of existing protocol.

Proposal

A: Define UserID as uint16, which can be serialized into a two-byte sequence.
B: Define a function fa(user)=>UserID. fa should generate an unique UserID for each user, but collision may be accepted.
C: When SS client generates IV (salt) for a connection, say byte[0...31]:

1. Randomize all bytes as usual.
2. Then reset byte[30...31] to the UserID.
3. Then masks byte[30...31] with fb(IV)=>uint16.

D: When SS server receives an incoming connection. It tries to decode IV with the same fb.

• If UserID is valid, server decodes the entire connection with this user.
• If UserID maps to multiple users, server try decoding the connection with all matching users.
• Optionally if UserID if not found, server can try decoding with a "default" user. This step provides backward compatibility to clients without multi-user support.

Advantage

• Backward compatibility with existing Shadowsocks protocol.
• Constant-time decoding with multi-user support.

Disadvantage

• UserID may be leaked and becomes a fingerprint. To mitigate this issue, fa may take other factors into account, say timestamps, e.g., fa(user, time-in-second)=>UserID. The UserID will dynamically change based on time.

Suggested Functions

• fa: first two bytes of SHA256(user-key).
• fb: Fnv-1a(input[0...len-2]) % max(uint16)

No files, tests, or entry points are mentioned. Treat this as a protocol-design proposal: first review the existing Shadowsocks handshake and multi-user compatibility requirements, then establish whether the proposed UserID and masking scheme has an agreed implementation scope.