[JkLondon]

Config.PrivateKey is now *ecdh.PrivateKey, parsed once by the caller. This avoids deriving the same static public key on every authentication attempt.

Auth DH: 58.08 → 29.13 µs, 7 → 3 allocs/op (Go 1.27.0, darwin/arm64, Apple M3 Max; 10 runs). Microbenchmark only.

Checked locally: race detector, amd64 correctness and FIPS enforcement.

[RPRX]

Rebase，@yuhan6665 你看看

[RPRX]

需要再次 rebase，且我不确定这么搞是不是并发安全的，如果是的话就直接改接口吧别加锁了，test 文件删掉

顺便试试能不能 linkname #37 (comment) ，都放这个 PR 里吧

[yuhan6665]

需要再次 rebase，且我不确定这么搞是不是并发安全的，如果是的话就直接改接口吧别加锁了，test 文件删掉

顺便试试能不能 linkname #37 (comment) ，都放这个 PR 里吧

跟原版比似乎少了一个copy 不知道会不会有问题？
https://cs.opensource.google/go/x/crypto/+/master:curve25519/curve25519.go;l=91

[RPRX]

依稀记得不太并发安全，不然一开始就会这样写了，查一下吧，再让 AI 看看深层代码确认下，AI 最适合干这种事

[Fangliding]

个人感觉无所谓 在非瓶颈的路径上加缓存快点是快点但是终归是反模式 也就让握手快了 0.029 ms

[JkLondon]

Thanks for the discussion) Sadly, I don't know Chinese but as I understand from the translation :

1. According to the Go 1.27 X25519 implementation ECDH only reads and allocates a separate result for each call, so it's concurrently safe, I've done several tests, including race ones, all was ok.
2. talking about perf point @Fangliding mentioned: I'm maintaining pretty large xray server when I pprof it I saw that X25519 accounted for 8.00% of process CPU, the repeated derivation alone accounted for 1.99%. So, from my side it would not be THAT significant increase of CPU perf but anyway worth trying.
3. As @RPRX asked, I have deleted tests, and changed Config.PrivateKey to *ecdh.PrivateKey.

[RPRX]

talking about perf point @Fangliding mentioned: I'm maintaining pretty large xray server when I pprof it I saw that X25519 accounted for 8.00% of process CPU, the repeated derivation alone accounted for 1.99%. So, from my side it would not be THAT significant increase of CPU perf but anyway worth trying.

如果你是只统计这一个点的 X25519 的话这下降比例或许合理，然而就算所有点的 X25519 加起来，占到进程的 8% 这真的对吗

[RPRX]

According to the Go 1.27 X25519 implementation ECDH only reads and allocates a separate result for each call, so it's concurrently safe, I've done several tests, including race ones, all was ok.

看了下代码是并发安全的，我顺便把下面那个 hkdf 也改成 crypto/hkdf 吧，不过那个依赖还有其它文件在用，以及 uTLS

[RPRX]

依稀记得不太并发安全，不然一开始就会这样写了

应该纯粹是因为 23 年初 Golang 还没内置这个 crypto/ecdh 库，之前看到过一个并发不安全的可能是 hash sum #37 (comment)

[RPRX]

更令人无语的是 VLESS Encryption 本来就是这么写的，我自己都忘了，话说它的注释比 REALITY 多得多，不然代码不敢乱动了

VLESS Encryption 还有导剪版的文章，而 REALITY 只有一个写了一半的在本地，看了下还在，主要是一些开发时的心得和想法

[yuhan6665]

完美主义害人不浅

[RPRX]

主要是这种 key 不 key 的东西不好整出 bug 所以得多想些，不然又被某些类人生物拿来大做文章了