[Feature Request] 加入調用OpenSSL engine（比如RDRAND）功能。

[okudayukiko]

• [X] I certify that I have read the contributing guidelines and I acknowledge if I don't follow the format below or I don't check this box, my issue will be closed immediately without any notice.

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Is this problem relevant to what trojan should care about? Trojan is a protocol implementation, not a full-fledged proxy client. Features such as custom routing will not be accepted.

Describe the solution you'd like A clear and concise description of what you want to happen. 加入調用OpenSSL engine（openssl engine）功能，比如rdrand、tpm2tss。比如"ssl":{}的"engine": "rdrand"。Windows版則靜態連結編譯rdrand引擎。RDRAND對VPN速度影響較大，OpenSSH的ssh和sshd就預設調用RDRAND，因此在PC上OpenSSH server+OpenSSH client+Firefox+SOCKS5 Proxy比Trojan快。Trojan usage加入-e選項，列出可用的OpenSSL engine。 亂數 對 TLS伺服器 和 TLS客戶端 的性能都有明顯影響，因為要用PRNG來生成 工作階段密鑰（Session key），現在的電腦CPU是內置RDRAND指令集了，Android不清楚，以我的手機為例是/dev/hw_random。 Stunnel engine=rdrand https://www.stunnel.org/static/stunnel.html Nginx ssl_engine rdrand; https://nginx.org/en/docs/ngx_core_module.html#ssl_engine OpenVPN engine rdrand https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/ Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context Add any other context or screenshots about the feature request here.

[okudayukiko]

或者用Stunnel 在伺服器端重新打包Trojan流量： 此法對Trojan有效，對Ocserv無效。 vim /etc/trojan/config.json "local_port": 442 cat /etc/stunnel/ecdsa.crt > /etc/stunnel/stunnel.pem cat /etc/stunnel/ecdsa.key >> /etc/stunnel/stunnel.pem vim /etc/stunnel/stunnel.conf engine = rdrand [trojan-442] client = yes accept = 127.0.0.1:440 connect = yourhostname.com:442 verifyChain = yes CApath = /etc/ssl/certs checkhost = yourhostname.com [trojan] accept = 443 connect = 127.0.0.1:440 cert = /etc/stunnel/stunnel.pem

[okudayukiko]

個人估計，是防火牆可以對OpenSSL、Go、GnuTLS、/dev/urandom的偽隨機數生成器（PRNG）進行深度包檢測（DPI）。畢竟OpenSSL、Go、GnuTLS、/dev/urandom的PRNG是開源的，RDRAND是不開源的。

[k4yt3x]

支持 hardware RNG 我认为是一个 valid request，但是防火墙可以通过 DPI 识别 PRNG 的特征听起来很不现实。

以 /dev/urandom 举例，即使该 RNG 是 PRNG，其 entropy source 是基于电脑本地硬件的（键盘输入、CPU 中断间隔、网络 I/O、硬盘 I/O），产生的结果对于不可观测该系统的第三方来说也可视为随机。在该用例上，urandom 产生的结果和 TRNG 产生的结果按随机性来说不应该有太大差距。已然，基于 urandom 生成的 client random 和 server random 也可被视为足够随机。所以无论开源与否，我并不认为上述 PRNG 会产生可被 DPI 识别的特征。

当然，类似于 RDRAND 和 TPM RNG 这种 FIPS-compliant TRNG 会在熵上更有优势，不过系统的 PRNG 除非没有任何可靠 entropy source，否则都不应该有您描述的问题的。

[okudayukiko]

支持 hardware RNG 我认为是一个 valid request，但是防火墙可以通过 DPI 识别 PRNG 的特征听起来很不现实。

以 /dev/urandom 举例，即使该 RNG 是 PRNG，其 entropy source 是基于电脑本地硬件的（键盘输入、CPU 中断间隔、网络 I/O、硬盘 I/O），产生的结果对于不可观测该系统的第三方来说也可视为随机。在该用例上，urandom 产生的结果和 TRNG 产生的结果按随机性来说不应该有太大差距。已然，基于 urandom 生成的 client random 和 server random 也可被视为足够随机。所以无论开源与否，我并不认为上述 PRNG 会产生可被 DPI 识别的特征。

当然，类似于 RDRAND 和 TPM RNG 这种 FIPS-compliant TRNG 会在熵上更有优势，不过系统的 PRNG 除非没有任何可靠 entropy source，否则都不应该有您描述的问题的。

OpenSSL PRNG、Go PRNG和GnuTLS PRNG呢？

[k4yt3x]

OpenSSL PRNG 在 UNIX 上会从 /dev/urandom 读，而在 Windows 上则会用 CryptGenRandom 生成。剩下的我建议您先自行查资料，而不是先提问题消耗开发者的时间。 参考：https://wiki.openssl.org/index.php/Random_Numbers

[testcaoy7]

支持RDRAND是应该的，不过目前我用haveged来给/dev/urandom补entropy