Config parse error when using Extensible Identity Header and 2022-blake3-chacha20-poly1305 algorithm

[bindreams]

Here is an example config which should work with sslocal. It's using a the new encryption algorithm with EIH. According to the README, I should concatenate the server token and user token with :

{
    "local_address": "127.0.0.1",
    "local_port": 1083,

    "servers": [
        {
            "server": "1.2.3.4",
            "server_port": 20000,
            "password": "lIeOeQwb9OXkAi7EWNhm62acn8rs97t0+mVdms7V6fE=:wjxYGa701LiKfdBD46U4yd0+rRU627V6ZB4rM5dzpwE=",
            "method": "2022-blake3-chacha20-poly1305"
        }
    ]
}

Instead of starting, the program panics when parsing the config:

$ bin/sslocal -v -c .\shadowsocks.json
thread 'main' panicked at D:\a\shadowsocks-rust\shadowsocks-rust\crates\shadowsocks\src\config.rs:364:17:
2022-blake3-chacha20-poly1305 password lIeOeQwb9OXkAi7EWNhm62acn8rs97t0+mVdms7V6fE=:wjxYGa701LiKfdBD46U4yd0+rRU627V6ZB4rM5dzpwE= is not base64 encoded, error: Invalid symbol 61, offset 43.
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

However, when switching the algorithm to 2022-blake3-aes-256-gcm, everything gets parsed OK and the program starts.

My sslocal version is 1.18.4.

[zonyitoo]

EIH is only supported by the AES ciphers. https://shadowsocks.org/doc/sip023.html

[bindreams]

Sorry... this just multiplies the number of questions that I have. Why does ssserver accept the "users" array with this cipher selected? Furthermore, when using a third-party local client (I use shadowrocket on iOS), the combination of cipher and EIH actually works, I have an internet connection and everything.

Please don't take this the wrong way, obviously I'm not an expert, but the SIP you linked to does not say that EIH is only supported by the AES ciphers. It says this:

Identity headers are implemented in such a way that's fully backward compatible with current
[Shadowsocks 2022](https://shadowsocks.org/doc/sip022.html) implementations.

And in the "Shadowsocks 2022 implementations" SIP it says the following:

4. Optional Methods
Implementations MAY choose to implement 2022-blake3-chacha20-poly1305,
2022-blake3-chacha12-poly1305 and 2022-blake3-chacha8-poly1305 when support
for CPUs without AES instructions is a priority.

So by my understanding, 2022-blake3-chacha20-poly1305 is a Shadowsocks 2022 implementation and should be compatible with EIH, no? If third-party implementations have successfully enabled it, would you consider this as a feature request?

[zonyitoo]

Well yes, in this project, only AES ciphers are supported:

shadowsocks-rust/crates/shadowsocks/src/config.rs

Lines 390 to 400 in 222adb3

	/// Check if method supports Extended Identity Header
	///
	/// https://github.com/Shadowsocks-NET/shadowsocks-specs/blob/main/2022-2-shadowsocks-2022-extensible-identity-headers.md
	#[cfg(feature = "aead-cipher-2022")]
	#[inline]
	pub fn method_support_eih(method: CipherKind) -> bool {
	matches!(
	method,
	CipherKind::AEAD2022_BLAKE3_AES_128_GCM | CipherKind::AEAD2022_BLAKE3_AES_256_GCM
	)
	}

[zonyitoo]

If third-party implementations have successfully enabled it, would you consider this as a feature request?

The EIH specification only mentioned how to implement it with those AES ciphers, how are those other implementations make the chacha20-* method works with EIH?

https://github.com/Shadowsocks-NET/shadowsocks-specs/blob/main/2022-2-shadowsocks-2022-extensible-identity-headers.md

[zonyitoo]

I cannot find any documents about how to implement EIH with 2022-blake3-chacha20-poly1305. @database64128 did you make any new extension for the EIH standard?

[bindreams]

I tried searching, but the iOS app is closed-source. I only know that however it encoded the data, ssserver from this project successfully decoded it. Maybe you could work backwards from the decode implementation.

[zonyitoo]

shadowsocks-rust/crates/shadowsocks/src/relay/tcprelay/aead_2022.rs

Lines 279 to 281 in 222adb3

	let require_eih =
	self.stream_ty == StreamType::Server && method_support_eih(self.method) && self.user_manager.is_some();
	let eih_len = if require_eih { 16 } else { 0 };

As we just saw, method_support_eih must be false for 2022-blake3-chacha20-poly1305. So in this project, it will completely skip the EIH decode block.

You can enable trace log by -vvv and see if you can find any logs like this:

shadowsocks-rust/crates/shadowsocks/src/relay/tcprelay/aead_2022.rs

Lines 329 to 333 in 222adb3

	trace!(
	"server EIH {:?}, hash: {:?}",
	ByteStr::new(eih),
	ByteStr::new(user_hash)
	);

If ssserver can work for your client, I would make an assumption: your client didn't send EIH for 2022-blake3-chacha20-poly1305. It just "pretented" like it supports EIH.

[bindreams]

You are correct, I'm not seeing these messages with 2022-blake3-chacha20-poly1305 but I am seeing them with 2022-blake3-aes-256-gcm. I also tried deleting all the users in the server config and the third-party app connected anyway.

I guess this is truly a feature request, if it is even possible to implement. If this cannot be implemented, I would suggest instead making stricter config checks on the server side, so that ssserver does not accepts users with unsupported ciphers.

[database64128]

EIH is designed for the AES ciphers. EIH configurations with 2022-blake3-chacha20-poly1305 should be rejected. ssserver should have refused to start, and the iOS app is clearly misbehaving.