I recently asked a question on security.stackexchange.com about whether Shadowsocks is MITM-able and the answer was helpful yet I would like to understand symmetric crypto / the crypto used in Shadowsocks to be able to answer the following questions :

1. How long should key lifetime be assuming a 28 character random password (base64 char set)
2. What is the maximum shared key size (assuming AES-256-CFB) and what is the relationship between shared key size and the "strength of security".
3. Shadowsocks supports chacha and salsa ciphers yet they recommend aes-256-cfb as default - why is this when Dan Bernstein's crypto seems to be the direction we are heading.
4. Does symmetric crypto use session keys derived from the secret keys?
5. How much data needs to be transferred before an attacker can have enough ciphertext to affect security or is this not a consideration?
• Is it me or did they just rolled their own crypto, used only stream ciphers and completely neglected MACs at the same time!? WTF! Oh, HMAC-SHA1 authentication is a "new and experimental feature" :/ – SEJPM Sep 4 '16 at 16:59
• My tip: Don't bother with Shadowsocks and look for a better alternative. The security given by it is not very relieable (CFB, WTF!? ; hash-then-encrypt because the HMAC key is not high-entropy ; optional message authentication!!!) – SEJPM Sep 4 '16 at 18:25

First, the expression "password" usually refers to "bad entropy, relatively easy to brute force". And basically the only way to deal with this is to use a decent key derivation function, which is designed especially for passwords. Examples are script, bcrypt or PBKDF2. The main difference to other key derivation functions is that you can tune up the process to actually take a long time - which is wanted in this case.

So, that leads to the first problem: What kind of key derivation do they have? I couldn't find it on their page. So probably, they don't have any.

Considering their "one time authentication", my guess is that they just offer the option to use MAcs. And they use HMAC-SHA1 for this, which is quite on the lower border of acceptable - for legacy systems but not for current development. SHA-1 should not be used today any more, but in HMAC it is not broken so far. But developing a new system should not actually involve such an outdated hash function.
And then: They use $(IV + KEY)$ as the key for the HMAC, which seems not that great either.

That last part actually leads me to believe they don't have session keys but just use that passwords (called $KEY$, I guess) directly, and maybe for both encryption and integrity check.

And then I stumbled over this discussion, which gave a little inside in their development of security features: github

Oh, and it seemds they are using libsodium as cryptographic library. And that one already gives you pretty much everything you would want: KDFs, key exchanges, state-of-the-art encryption and hashes, previously mentioned scrypt, etc. I don't know how good those implementations are, though.

Interestingly, there you can also find the term "onetime authentication" (link), which doesn't really make that much sense. But there you can find this:

Finally, Poly1305 is not a replacement for a hash function.

Building an HMAC out of this sounds weird.

Overall, it doesn't look too good, and probably their security is lacking.

Coming back to yout questions:

1. Passwords should never be used as key directly, which might be what they do. And then it depends if your password actually has full entropy(uniformly chosen of all strings of length 28). In that case it should be fine. If it is words in language, that's entirely personal preferance.
2. AES 256 has a key size of 256 bit. The question is if they use actually the full size. If they use a password in base 64 encoding as key directly, that would be really, really terrible. Strength of security of AES is: Unbroken, don't worry about it. More of a problem could be their mode of operation, because you would actually want an authenticated one.
3. Well, using AES as standard is a really good thing. Supporting other ciphers is quite common. However, I doubt your statement, that we're heading into the direction of Bernstein's Chacha or Salsa ciphers. AES is the de-facto standard for state-of-the-art symmetric encryption.
4. It should, but I have doubts that this is done in Shadowsocks.
5. This isn't a consideration, because the encryption scheme is almost surely not the weakest part of their system. Security depends only on the weakest link of the system, and it is basically never the encryption scheme. One other possibility is wrong usage of an encryption scheme (e.g. hard coded key), maybe have a look here.
6. Well, that depends on how much you already know. For starters, Wikipedia has a really good quality for a lot of cryptographic topics. Then there are online courses for cryptography, books like Applied Cryptography by Bruce Schneier, etc. Most importantly, focus on scientific publications and try to spot and avoid amateur publications. Other than that, it mostly depends on the time and effort you are willing to invest.
• Thanks you for your answer. I generate a 28 character random password from /dev/urandom and then limit the character set to base64. I guess I need to view the security of Shadowsocks as unknown, unless the code could undergo a security / crypto audit. – Hilton D Sep 10 '16 at 0:44
• @HiltonD That password length should be sufficient against brute force, and as long as you keep the uniform distribution that should be fine (around $168$ bit entropy). In your estimation, I wouldn't have chosen such a positive description as "unknown", I think my doubts are not unreasonable. However, asking for an audit would be quite unrealistic, partially because there might be no one willing to pay the bill - with it being a open source project. – tylo Sep 12 '16 at 9:48
• What I meant by unknown is that it has not been studied formally or extensively. If security is about Confidentiality / Integrity and Availability then I would hazard a guess that Shadowsocks only provides Availability (as in it can evade DPI). Also at which point does the password become too big? What if I supply a 48 char password? – Hilton D Sep 13 '16 at 13:36