Reduce chunk length overhead in AEAD about shadowsocks-org HOT 7 CLOSED

吼啊

from shadowsocks-org.

a) 16 bytes overhead means 16 / 1492 (typical chunk size if MSS = 1492) ~= 1% bandwidth loss. I doubt the overhead is even notable in the real world.
b) The approach of OpenSSH doesn't look good to me, especially the two separate ciphers.
c) Since SIP004 is already finalized, I prefer to not changing AEAD ciphers, unless there is any security concern.

I suggest to do more research for any new AEAD cipher that would solve the chunk length issue internally.

from shadowsocks-org.

I have seen similar construction in obfs4, although obfs4 uses a strange (maybe invented by itself) stream cipher.
Maybe we can drop the length tag, ignoring the authenticate error of the length field, and include the length as Associated Data in payload part. However I'm not sure whether the encryption library allows us to do this.

from shadowsocks-org.

And as the protocol is frequently modified I think we must mark the stability on website.

from shadowsocks-org.

Maybe we can drop the length tag, ignoring the authenticate error of the length field, and include the length as Associated Data in payload part. However I'm not sure whether the encryption library allows us to do this.

It won't work. By definition AEAD ciphers will refuse to decrypt if authentication fails so as to avoid providing a decryption oracle to attackers.

from shadowsocks-org.

I think the question is a) whether 16 bytes overhead per chunk is acceptable and if not b) should we adopt similar design like the one used in OpenSSH.

from shadowsocks-org.

I agree. The OpenSSH design leaves the possibility open that adversaries can control the obfuscated length field. Even though it does not pose any security threat because the payload is still AEAD-protected, I wonder if it exposes timing characteristics that might enable attacks similar to @breakwa11's to identify the protocol we use.

from shadowsocks-org.