Replace Yawning/chacha20 PRNG

[renzhexigua]

In the latest commit: Yawning/chacha20@644b09a, the author did some non backward-compatible changes. One of them is:

NewCipher -> New

We should fix this piece here:

utls/u_prng.go

Lines 119 to 120 in 7c97cdb

	p.randomStream, err = chacha20.NewCipher(
	p.randomStreamSeed[:], randomKeyNonce[:])

[Yawning]

So, as a fair warning, the commit in question also changes the license to something that's probably not suitable for this project as well.

That said, in the spirit of "sorry I broke your package":

• Using go modules (since utls requires a new-ish version of the toolchain anyway) will prevent dependency changes from breaking code in the future in this manner (till the dependencies are updated), and would also let you pin the chacha20 import to the previous commit.

• https://godoc.org/github.com/aead/chacha20 is probably a suitable replacement, if people want to stick to ChaCha20, though skimming the code it does panic on counter overflow. Personally I opted to save an import and just use SHAKE.

[sergeyfrolov]

So, uTLS package is broken.

I do not think pinning chacha20 import to a previous commit is a good idea going forward. We'll have to find a replacement.

the commit in question also changes the license to something that's probably not suitable for this project as well

@rod-hynes does this affect you in any way? Do you happen to know any good replacement PRNG packages?

Seems like SHAKE (https://godoc.org/golang.org/x/crypto/sha3) could indeed be a good replacement.

[rod-hynes]

@rod-hynes does this affect you in any way?

We don't have any immediate issues since we vendored an earlier version of this: https://github.com/Psiphon-Labs/psiphon-tunnel-core/tree/master/vendor/github.com/Yawning/chacha20.

SHAKE seems fine and should simplify the code in https://github.com/refraction-networking/utls/blob/master/u_prng.go since there's no stream limit, so no need to rekey. I think SHAKE is somewhat slower than chacha20 (https://bench.cr.yp.to), but that's not relevant here, with few bytes generated.

Changing the cipher means a one-time change in randomized fingerprints generated by persisted seeds. I think we're ok with that. So as long as the API remains the same -- can the same seed size be used? Something like:

p.randomStream := NewShake256()
_, err := p.randomStream.Write(seed[:])

[Yawning]

can the same seed size be used?

Yes. An arbitrary amount of data can be absorbed.