SIP006 - Getting rid of key derivation once and for all

[Mygod]

Instead of letting possibly dumb server masters choose password, we are going to choose secure password for them.

A truly high-entropy, secure key can be generated using GnuPG:

$ gpg --armor --gen-random 2 <count>

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.

[riobard]

+1

Finally on the correct path to security :)

[Mygod]

True but as I've said having less security hurts the main goal of Shadowsocks.

[Mygod]

Pros:

• Better security;
• Better performance.

Cons:

• Takes a little extra time to set up.

[Mygod]

@wongsyrone Unfortunately having session key introduces handshake which hurts the main goal of Shadowsocks. Also it's super un-friendly to low end boxes.

[riobard]

I agree the KDF is not a very urgent issue for us. That being said, getting rid of it will

1. simplify the code base
2. avoid any arguments on which one to use (and future issue for replacement)
3. allow more compatibility between implementations in different languages
4. be more friendly to low end boxes

Looks like all wins to me.

[Mygod]

I agree it's not very urgent but it's good to put it out there anyway.

[riobard]

We seem to have four solutions:

1. Stick to original KDF in shadowsocks
2. Switch to Argon2i
3. Switch to Blake2b
4. Switch to random keys

Please indicate your current preference and reason below.

[riobard]

Questions for Blake2b: since it's generic hashing, what's the plan to get arbitrary key sizes for different AEAD?

[madeye]

Luckily we have arbitrary size implementation in libsodium: https://download.libsodium.org/doc/hashing/generic_hashing.html

[riobard]

@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).

[riobard]

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.

[madeye]

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.

[riobard]

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?

[madeye]

@riobard Yes, it should be the biggest problem. I didn't realize that at first.

So, my choices are

1. Original KDF for original stream cipher.
2. Argon2i for AEAD.
3. Random key for both stream cipher and AEAD as an option for our users.

[madeye]

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.

[Mygod]

Wait. Why is shortening an issue? I think shortening should be absolutely fine.

[riobard]

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)

1. Random keys
2. Argon2i
3. PBKDF2
4. Original KDF

[Mygod]

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.

[riobard]

@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.

[Mygod]

@riobard I see. In that case, why not SHAKE128/SHAKE256?

[riobard]

@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.

[riobard]

Also, shake128/256 are generic hashing…

[madeye]

@Mygod It would be very hard for me to drop key derivation here... I need a easy way to share server info with others.

[Mygod]

@madeye Random key can be embedded into JSON/ss uri after encoding to base64. I don't think it will be inconvenient.

[riobard]

@madeye Probably easier to stick to original KDF for stream ciphers, and random keys for AEAD? Is that possible?

[madeye]

@riobard The effort of user education is hard to imagine.

@Mygod What do you think of @riobard's proposal?

[Mygod]

That's exactly what I currently have in mind right now.

[madeye]

Hmm, I'm OK with random keys in that way.

[Mygod]

And yes, as @wongsyrone has pointed out, user education would definitely be a pain in the ass.

[madeye]

Add SIP006 via https://github.com/shadowsocks/shadowsocks-libev/tree/sip006. Any suggestion?

[Mygod]

1. Use url-safe base64, i.e. [0-9a-zA-Z-_].
2. Persist the generated key?

[madeye]

Persist the generated key?

It'd be tricky where to store the key.

[Mygod]

@madeye Good point. Ask user to change their key and exit?

[madeye]

@Mygod Yes, I think so.

[madeye]

@Mygod Any spec or implementation for URL safe BASE64.

[Mygod]

@madeye

1. Spec: RFC4648 Section 5.
2. Implementation: https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/util/Base64.java#565

[Mygod]

It should be as simple as changing the alphabet.

[riobard]

@madeye @Mygod so what is the conclusion now? Stick with old password hash for stream ciphers and require key for AEAD?

[madeye]

Right, I've updated specs and shadowsocks-libev to follow this SIP.

[librehat]

I'd vote against this proposal as it is enforcing some user behaviour. Users should be allowed to screw up if they may. Even p12 can be encrypted with empty passphrase 🔓

[Mygod]

@librehat The difference is that in p12, user usually needs to enter passphrase manually.

[riobard]

Ok, I took a middle ground in https://github.com/riobard/go-shadowsocks2

It takes both -key and -password arguments. If -key is empty, derive a key from -password using the original MD5-based KDF.

Users are encouraged to generate random keys. But if they have to use passwords, it's same as before.

Note that -key applies to old stream ciphers as well.

[testcaoy7]

If the server and the client has the same time, can a time-based session key be derived?

[madeye]

Actually, I personally prefer the approach from @riobard.

What do you think? @Mygod

[Mygod]

In that case we might as well use only password to keep things simple. I actually don't have a strong preference anyway.

[madeye]

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 --key will only work in command line or config file.

[testcaoy7]

What utility shall be used to generate the key ? GPG ?

[riobard]

My go port has a -keygen option to generate one.

[librehat]

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.

[Mygod]

HKDF seems like a better solution here. Close this?

[madeye]

@Mygod LGTM.

[riobard]

Now that we have --key option and SIP007 introduced per-session subkey, I believe the goal of SIP006 is achieved. Closing for now.