RPRX
@wevsty 精彩，你再次通过错误认知（误解读）推出了错误结论，即便正上方就是我详细的补充描述。 相信现在你已经了解了 [前向保密](https://zh.wikipedia.org/wiki/%E5%89%8D%E5%90%91%E4%BF%9D%E5%AF%86) 的定义，并发现了自己评论的内容完全存在误解且偏离主题。为了不误导他人，建议删掉。
@wevsty 1. 对我而言，在稳定 FQ 方面，XTLS 远比 SS 更合适且高效，但 SS 可以是一个不强依赖第三方的可信隧道方案，即特定客户端与服务器间的无特征可信隧道。况且，无论用途，安全性始终很重要，若能做到更安全，为何不做？不能不思进取。 2. 即使承载的大部分流量是 TLS，它也并远未普及 ESNI/ECH，相信你知道我在说什么。此外，SS 可被破解意味着可被实锤。 3. 这个说法非黑即白了，终端并不是完全无法被信任，只是现代的云备份会对 SS 静态密码造成致命打击。 4. 建议重新看一遍我描述的方案。另外，即使你非要同端口多用户，也只需要判断第一个包，成本极低。 说一下前向安全： 1. 一般指的是密钥的第一次泄露，比如密钥第一次被手机泄露时，电脑的历史通讯还是不可破解的、安全的。 2. 当然对于我的方案，上述场景压根就不存在，因为不同设备间必须是独立的。 3. 事实上随着你的使用，动态密钥一天内就会被更新 N 次，即使每天快照一次，也远比现在的静态密码强，至少增加了跟踪难度，而不是随便拿到一段此前或此后的流量就可以直接解密。
@wevsty 另外，如果你感兴趣的话，我可以向你详细说明一下，你在 #177 中的一些说法有多么 误解读 与 无知。 而这里这个方案，我在开头已经明确建议了，段位不够的人不要掺和，没想到你还是来了，并且再次展示了自己的智商。
@wevsty Wonderful speech. Actually I didn't mean to target any person, as I will say exactly the same words if someone doesn't have patience to read the [detailed description that...
@dev4u 所以，会带来什么特征？ 初始密钥由 SSH/TLS 可信通道传输，而新的密钥是 AEAD 解密出来的，又有什么问题？
@dev4u （顺便 @wevsty 存在一些误解，我 kindly 说明一下 > 若要实现这个机制，明文 TCP 代理协议结构只需一处小改动：返回的数据前加一个字节代表新密钥长度，0 代表无新密钥 这里指的是服务端 **返回** 数据时的 **明文** 协议结构，是还没有被加密的 > 由于只判断第一个包，所以代价很低 这里指的是服务端 **接收** 请求时，只需尝试解密第一个 packet 即可找出同源后续大量数据的所属用户，实现低成本端口复用
@dev4u 麻烦不要 断章取义，如果你没看明白发生了什么，或者你只看到了标粗的那两行。 > 诚然每个人都会、也可以认为自己才是最好的，但完全没必要强求别人也认同。这种揽炒做事风格，真不应该出现在这。 **我并没有强求谁的认同，任何人完全可以不认同，合理的解释或更好的想法均可，但绝对不是乱踩或基于误解的否定。** 况且当我说出上一个想法 #177 时，我完全没有说其它事情，后来我只是想简单表明我不会犯低级错误。 Besides, 实现我的想法与讨论我的想法是可以 **并行** 的。不要把讨论往 off-topic 的方向带
@dev4u 需要声明，我是希望参与讨论的人有相应的知识或实践过，探讨起来就会轻松很多，避免鸡同鸭讲，这样效率很低 比如只要编写过代理软件，就可以迅速判断出一个想法是否可实践，以及有无工程上的潜在优化方案 也就是说参与讨论的目标群体本来就不是所有人，这个我在一开始就标明了，而且这也是实践中很常见的做法
@fortuna > You are proposing a sequence of keys k_1, k_2, k_3, ..., k_n. > You first exchange k_1, then the client and server derives k_i = hash(k_(i-1)) on a...