-
Notifications
You must be signed in to change notification settings - Fork 526
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SIP006 - Getting rid of key derivation once and for all #35
Comments
+1 Finally on the correct path to security :) |
True but as I've said having less security hurts the main goal of Shadowsocks. |
Pros:
Cons:
|
@wongsyrone Unfortunately having session key introduces handshake which hurts the main goal of Shadowsocks. Also it's super un-friendly to low end boxes. |
I agree the KDF is not a very urgent issue for us. That being said, getting rid of it will
Looks like all wins to me. |
I agree it's not very urgent but it's good to put it out there anyway. |
We seem to have four solutions:
Please indicate your current preference and reason below. |
Questions for Blake2b: since it's generic hashing, what's the plan to get arbitrary key sizes for different AEAD? |
Luckily we have arbitrary size implementation in libsodium: https://download.libsodium.org/doc/hashing/generic_hashing.html |
@madeye Sorry I wasn't being clear at my question. The goal is to get arbitrary output sizes from generic hashing because we want to support AEADs with different key size requirement. Generic hashing produces fixed size output by default, and we must either shorten or lengthen it to get desired output length. Password hashing has a built-in mechanism to produce arbitrary output sizes, thus more suitable for KDF (what a surprise). |
So the question is, what's the proposed solution to shorten/lengthen output from generic hashing without hurting entropy? It's a difficult task from cryptoanalysis point of view. That's why I think dedicated password hashing algo is better than generic hashing here—experts have done the hard job for us. |
Blake2b is able to generate at most 64 bytes hash. I think that's why @wongsyrone thinks it's suitable for current AEADs. If we add something like AES-1024-GCM in the future, then the key size here would be a problem. |
Shortening is also an issue. Are we just taking the first 16 bytes of the 64 bytes output for 128-bit keys? What's the effect on entropy loss? |
@riobard Yes, it should be the biggest problem. I didn't realize that at first. So, my choices are
|
For random keys, I think @Mygod can just define a new URL schema. I just need to add a new option to CLI and JSON config. |
Wait. Why is shortening an issue? I think shortening should be absolutely fine. |
The original KDF is similar in spirit to PBKDF2, and PBKDF2 is also an industry standard used by many (for example MacOS Keychain and 1password). So I'd add PBKDF2 as a possible candidate if we stick to password hashing. base16/32/64 encode for random keys looks pretty good to me. My preference would be (in the listed order)
|
Actually if we are going to use random keys, we should deprecate key derivation as one of its points is to prevent server masters using weak passwords. Otherwise I prefer to having key derivation instead of having both of them to simplify codebase. |
@Mygod It's not that simple… For more explanation you could read https://tools.ietf.org/html/rfc5869#section-5 But anyway the point is that generic hashing has no standard way to produce arbitrary output sizes, and if we use generic hashing, we have to come up with our own (likely flawed) construction. Therefore it's better to use dedicated password hashing instead (if we stick to passwords). I'd vote for random keys. |
@riobard I see. In that case, why not SHAKE128/SHAKE256? |
@Mygod The practical concern is to use something more well-proven and wide-spread because implementations in other languages might not have easy access to mature lib to newer or lesser-known algos. |
Also, shake128/256 are generic hashing… |
@Mygod It would be very hard for me to drop key derivation here... I need a easy way to share server info with others. |
@madeye Random key can be embedded into JSON/ss uri after encoding to base64. I don't think it will be inconvenient. |
@madeye Probably easier to stick to original KDF for stream ciphers, and random keys for AEAD? Is that possible? |
That's exactly what I currently have in mind right now. |
Hmm, I'm OK with random keys in that way. |
And yes, as @wongsyrone has pointed out, user education would definitely be a pain in the ass. |
Add SIP006 via https://github.com/shadowsocks/shadowsocks-libev/tree/sip006. Any suggestion? |
|
It'd be tricky where to store the key. |
@madeye Good point. Ask user to change their key and exit? |
@Mygod Yes, I think so. |
@Mygod Any spec or implementation for URL safe BASE64. |
It should be as simple as changing the alphabet. |
Right, I've updated specs and shadowsocks-libev to follow this SIP. |
I'd vote against this proposal as it is enforcing some user behaviour. Users should be allowed to screw up if they may. Even |
@librehat The difference is that in p12, user usually needs to enter passphrase manually. |
Ok, I took a middle ground in https://github.com/riobard/go-shadowsocks2 It takes both Users are encouraged to generate random keys. But if they have to use passwords, it's same as before. Note that |
If the server and the client has the same time, can a time-based session key be derived? |
In that case we might as well use only password to keep things simple. I
actually don't have a strong preference anyway.
|
OK, let's follow @riobard's approach. Directly passing a key to shadowsocks should be useful, especially for some expert users. To keep things simple, we won't accept keys from URL or QR code, the |
What utility shall be used to generate the key ? GPG ? |
My go port has a -keygen option to generate one. |
Directly specifying key for expert users is OK. As long as the old-style key derivation from password is kept. I agree with @madeye to keep URL untouched from this proposal. |
HKDF seems like a better solution here. Close this? |
@Mygod LGTM. |
Now that we have |
Instead of letting
possibly dumbserver masters choose password, we are going to choose secure password for them.A truly high-entropy, secure key can be generated using GnuPG:
where count is the length of the key we wish to use. Server masters shouldn't specify key themselves but can request a key renewal.
This key will be directly used for AEAD proposed in SIP004 (#30). When putting in SS urls or JSON file it should be base64 url-friendly encoded.
The text was updated successfully, but these errors were encountered: