SIP007 - Per-session subkey about shadowsocks-org HOT 36 CLOSED

I'm afraid the Internet doesn't work that way.

The only thing to happen for sure is even worse QoS on all traffic.

from shadowsocks-org.

According to the spec https://shadowsocks.org/en/spec/AEAD-Ciphers.html
the length and the data fields are encrypted separately.
So it seems more like doing AE TWICE rather than AEAD, because we haven't encrypted any associated data.

from shadowsocks-org.

LGTM. +1.

I suggest to follow the naming convention skey-cipher when adding support for this SIP, i.e. skey-chacha20 and skey-chacha20-poly1305.

from shadowsocks-org.

@wongsyrone HKDF has two phases: extract and expand, which allows the input keying material to be weak. My understanding is that crypto_generichash_blake2b_salt_personal has only the expand phase, therefore it's not as good. However you could construct HKDF_blake2b, which would be similar to HKDF_SHA1. SHA1 has the advantage of being more common with mature lib support.

The protocol mostly stays the same. This SIP only changes how the cipher key is generated.

@madeye I'm wondering if we should amend SIP004 to force the new design at least for AEAD ciphers since it's pretty new and AEAD ciphers are more vulnerable to nonce reuse. For stream ciphers, we definitely need the prefix.

from shadowsocks-org.

@riobard I'm fine with it. AEAD is still in pre-release stage, so I think we are safe now.

from shadowsocks-org.

@wongsyrone HKDF is very easy to implement. Here is one based on mbedtls: https://github.com/thomas-fossati/mbedtls/blob/2bf438d7d6906b753fe1ffe615eb2467353a1a78/library/hkdf.c

from shadowsocks-org.

@wongsyrone I think you mean "not that random" salt in broken clients? Yes, it's still a problem.

from shadowsocks-org.

Alright, I guess the right plan is to amend SIP004 with SIP007 and rewrite AEAD ciphers to use the new construction and provide additional stream ciphers.

I'm not familiar with C, but in other higher-level languages like Go and Python, using HKDF is very simple. You can pick your own hash function. SHA1 is just a conservative choice.

from shadowsocks-org.

Updated the proposal to include guidance on the length of random salt.

from shadowsocks-org.

Actually it's an open pull request for mbedtls. Mbed-TLS/mbedtls#542

After reviewing the code, I think the implementation is very solid.

from shadowsocks-org.

It depends. If we don't have better library for HKDF, I'll directly implement it in shadowsocks, like what we are doing for PBKDF currently.

from shadowsocks-org.

I have implemented AEAD ciphers with subkey here https://github.com/riobard/go-shadowsocks2/tree/sip007

from shadowsocks-org.

I applied similar treatment to derive a new subkey for each UDP packet with nonce setting to all zero.

Also, I think it's pointless to retrofit the old stream ciphers with the session key. If people want better security, they should use AEAD ciphers anyway. Less compatibility headache.

from shadowsocks-org.

@riobard OK. Let's only apply this on AEAD.

from shadowsocks-org.

@madeye Could you please test the interoperability once you finish the changes in shadowsocks-libev? I think I've implemented this SIP correctly, but without another reference point, it's not guaranteed. Let me know if there's any problem.

from shadowsocks-org.

Thanks. I'm working on it.

from shadowsocks-org.

Don't remove original stream ciphers, not everyone think they need the extra security.
Some people care performance ( Encryption/Decryption Speed ) more.
Learning a lot from discussions in recent issues, thank you all.

PS:
Really hope someone can pickup the ShadowVPN project.

from shadowsocks-org.

The new AEAD ciphers actually perform very well on modern devices. On my machines, AES-128-GCM gives me about 2x the throughput of AES-128-CTR and AES-128-CFB.

I've actually written my own implementation of ShadowVPN (with some experimental changes) in Go. However, UDP traffic is heavily throttled on many ISPs, making it less viable for widespread adoption. That's why I'm back to Shadowsocks.

from shadowsocks-org.

One TCP connection with one tunnelled TCP connection would be better. And from my currently knowledge, no VPN supports this .

AES-128-GCM is good, but I'm using AES-256-CFB now which is a silly choice made year ago before knowing more. And ChaCha20 with authentication is a little slower from the benchmark in the ss-libev issue #1173.

Current Shadowsocks client on Windows is just a proxy front end, not very convenient in some case. And my router doesn't have TPROXY module for UDP redirection. This is my first motive to see how ShadowVPN works.

And I think UDP with an auto BBR-like congestion control method is great and may help uploading on OSes which don't support BBR. KCP has too many parameters which need some tweak time. UDP may working better in some ISPs. But I don't have the capability to implement this.

from shadowsocks-org.

TCP over TCP is bad for performance.

KCP basically moves the congestion control from kernel to userspace, making it easier for people to experiment. However this empowerment comes with great danger that selfish people would abuse available bandwidth and we all suffer as a result. That's why fairness is a core concern in TCP.

from shadowsocks-org.

@riobard It works now. https://github.com/shadowsocks/shadowsocks-libev/tree/sip007

from shadowsocks-org.

Great!

from shadowsocks-org.

Fairness protocols in subscriber sides just save ISP's efforts to improve router design.
So temporal unfair usage will rebalance in some time.

from shadowsocks-org.

I suggest to follow the naming convention skey-cipher when adding support for this SIP, i.e. skey-chacha20 and skey-chacha20-poly1305.

I wonder what convention.

from shadowsocks-org.

@Mygod Never mind. We don't need to change any cipher name now. All AEAD ciphers are forced to use per-session subkey.

from shadowsocks-org.

Hmm okay. However has the downside of this proposal been discussed? This proposal effectively introduces the risk of skey collisions and leaves a large space of nonce unused for most (if not all) of the time.

from shadowsocks-org.

With random salt at minimal 128-bit, the probability of session key collision is negligible.

And you can always use 192 or 256-bit key (which will in turn use 192/256-bit salt).

from shadowsocks-org.

OK, so the server and client both use the same derived key, and with the same nounce? That is a key-nounce reuse vulnerability. If I don't get it wrong, the reuse is also present in old design, but as we are devising a brand new protocol here, it should fixed. The server and client should have different subkey by having different "info" argument.

from shadowsocks-org.

@netheril96 The two directions of one TCP stream are totally independent. It means their salts and subkeys are also generated from different random bytes.

from shadowsocks-org.

@madeye Is that also the case in the old protocol? Please update the documentation on the spec to clarify this, because I read it several times, and found no evidence of independent IVs in the design.

from shadowsocks-org.

@netheril96

The first packet of a shadowsocks TCP connection sent either from server-side or client-side must contains the randomly generated IV that used for the encryption.

https://shadowsocks.org/en/spec/protocol.html#TCP

from shadowsocks-org.

Finalized in https://shadowsocks.org/en/spec/AEAD-Ciphers.html

from shadowsocks-org.

Yes, because we do not have any associated data (yet).

from shadowsocks-org.

Exactly,
As I see, ss-protocol cut TCP streaming data into several wrapped data block, and then put them into stream. So the associated data is the data block u gonna to wrap I think.

from shadowsocks-org.

Question from 2019: do we need to worry about the fact the key derivation uses SHA1, given that it's known to be broken?

from shadowsocks-org.

Well, it seems I found my answer: https://crypto.stackexchange.com/questions/26510/why-is-hmac-sha1-still-considered-secure

HMAC-SHA1 seems to still be secure, which is what we seem to use.

from shadowsocks-org.