Comments (36)
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.
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.
Related Issues (20)
- Feature request: Chain Shadowsocks HOT 1
- [Security] Do not engineer vulnerabilities into implementations without public discussions HOT 7
- [One Idea] IP Geolocation Based Filtering HOT 20
- Ahmadtafreshi HOT 1
- Ahmad
- [Peer Review Request]Restls: A Perfect Impersonation of TLS Handshake HOT 5
- 能支持udp over tcp吗 HOT 1
- 日志文件 HOT 1
- OpenWrt client is not working for me
- 能否申请将Java的实现版本也纳入到官方社区中 HOT 1
- Correct wiki entry for "Setup fail2ban" - a jail config error detected HOT 2
- 社区有没有针对SIP023 relay server 的开发计划 HOT 2
- Cannot make the fail2ban setup guide work with systemd journal
- Non-UI Error. Can't start application
- ss://[email protected]:8388#SIP008%0A%0A HOT 1
- 兼容改版shadowsocks
- feature request: sip003 mux / multiplexing spec HOT 1
- Shadowsocks stopped working
- Add 2022 edition shadowsocks methods support for clients
- QR code with username
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from shadowsocks-org.