-
Notifications
You must be signed in to change notification settings - Fork 535
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Another mechanism to achieve Forward Security, without changing the protocol #178
Comments
After further thought, update: It is not necessary to sync time on both sides in most scenarios, which is not an actual limitation. The server just needs to generate different keys for each device, which is very easy to do. So I think this is the best solution at this stage based on current SS protocol. |
It's built on top of the protocol, without introduction of additional long-term channels or bring in potential identifiable features. cc @fortuna |
@Mygod I would like to ask your explanation on the downvote. I expect a technical discussion rather than some cold violence. |
@Mygod I would like to REQUEST your explanation on the downvote. I expect a technical discussion rather than some cold violence. |
How does this provide forward-secrecy? If the attacker gets the key, they can decrypt all the recorded traffic by hashing the key with the timestamp of the traffic. Did I miss something? |
As I have suggested in #177 (comment), you can first implement it as a shadowsocks plugin. |
There is an obvious misunderstanding, I'll explain this mechanism in detail:
Even if the attacker gets the current key, he can not revert hash to get previous keys, that's how this provides Forward Secrecy. |
Thanks for your advice. But seems it's not necessary to thumb down my design at first, which is very impolite that everybody can tell. |
Here's an Academic Explanation In short, this simple mechanism provides:
|
I recommend first reading https://shadowsocks.org/en/wiki/AEAD-Ciphers.html The current protocol uses an encryption key for each connection that I call SessionKey (or subkey in the documentation).
The main key is defined by the user. In this design, even if a single SessionKey is leaked, the other session is still secure. Adding a timestamp I don't think guarantees forward security. Adding a timestamp only stops a portion of replay attacks. I quote from it.
Nearly 25% of the replayed attacks were completed in almost a few seconds.Timestamps don't help us distinguish between these replay attacks. |
A short conclusion for implementors: the |
To my understanding, this plan is used to ensure the forward secrecy on a preshared key (PSK) leakage. Am I correct? @RPRX |
To aviod misunderstanding, new expression: |
I know what is forward secrecy. Thank you for your concern.
A standard should be written with a specific implementation plan and be repeatable in practice.
This is clearly a personal attack, and while I won't ask for an apology, you'd better stop this behavior. Going back to the program, I think a lot of people have developed some different ideas. So in response to the added content I'll restate my view. If the preshared key (PSK) is only changed at regular intervals, then this behavior is not part of the protocol. |
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 I've already given but draw a totally wrong conclusion by just seeing The fact is that here's a pre-discussion before the official standard of my design, and I just post my idea, as you can notice. Thus, if someone can not understand my idea or feels strange, it would be better to throw a question or just watch rather than negate my idea directly by a lot of words (as there's a strong possibility of misunderstanding at first). I agree that more detailed standard is required, but it's not my fault that you ignored the previous detailed description about my idea and joined this pre-discussion with your misunderstanding. Please be patient in future discussions. Going back to the program, it's not surprised if there are different ideas (though I didn't find many). I think my idea will be the best: Feel free to introduce any better ideas. |
楼主应该专心去把你的想法实现出来、并完善,而不该在这里打嘴炮,不是吗? |
需要声明,我是希望参与讨论的人有相应的知识或实践过,探讨起来就会轻松很多,避免鸡同鸭讲,这样效率很低 比如只要编写过代理软件,就可以迅速判断出一个想法是否可实践,以及有无工程上的潜在优化方案 也就是说参与讨论的目标群体本来就不是所有人,这个我在一开始就标明了,而且这也是实践中很常见的做法 |
@RPRX Let me see if I understood correctly. You are proposing a sequence of keys k_1, k_2, k_3, ..., k_n. Forward secrecy says that session keys will not be compromised even if long-term secrets used in the session key exchange are compromised. Your proposal doesn't seem to have that property. If the long-term secret k_i gets compromised, the attacker can derive any k_j, j>=i and decrypt all sessions since k_i. @DuckSoft throwing away the key has no impact on defining forward secrecy, since you could still compromise the key by other means (e.g. a dictionary attack, brute force or some vulnerability on how you generate them) |
@fortuna I see your point. You are correct but in the proposed method @RPRX mentioned a strong hypothesis: The old key should not be retained. If we accept that, there is somewhat no "long-term" secrets. The longest-term secret you can find is the key stored in clients/servers when it is compromised. I am an amateur on this, but my intuition tells that maybe the noun "forward secrecy" is not understood the same among us. I noticed that in the definition, there is also a phrase says long-term secrets "used in the session key exchange", while in the proposed method, the only key exchange from the very beginning is assumed as secure, and there's actually no session key exchange afterwards. I doubt whether we should or can classify this method as forward secure or not. Anyway, thanks @RPRX for sharing with us the interesting idea. |
Correct.
Not correct. First, actually there's no Second, on a trusted device, there's no possibility that k_(i-1) gets compromised before k_i if you do not store k_(i-1) anymore. If k_i gets compromised and you continue using this key, then it's a problem that even TLS has not solved yet (MITM attack).
Not a problem if we choose the proper method/multi-processes.
|
On the other hand, if this ever-changing key is considered the long-term key, then indeed we achieved the goal of forward secrecy: protects past sessions against future compromises of keys or passwords. I agree that we should be clear about what are we doing here. |
Blocked @QuantumGhost 说一下原因,这个人的行为一直是对我的观点按 thumbs down,并对相反的观点按 thumbs up 只能眼不见为净了。 |
我说一下我的分析吧,这个密钥滚动机制可以保证服务器和客户端保证不复用密码,如果在某个时间点之后被入侵,而之前一直保证安全,且可以彻底不可逆的摧毁之前硬盘上保存的密钥的话,那么之前的通信内容可以保证无法被解密。 但是在实际部署的过程中可能遇到的问题包括: 总体来看就是个低配版本的puncturable encryption。虽然设计上没有什么问题,但是有一些假设在实际环境中并不容易实现。 我想出了一个改进的方法,客户端发送给服务器的连接里面带上一个客户端DH参数,服务器在收到这个消息后就随机生成一个DH参数并保存,然后 新密钥 = hash(旧密钥+DH结果), 然后把这个服务器DH参数返回给客户端。客户端在收到新密钥后就用新密钥建立连接。服务器端在之后收到新连接的时候,如果是用新密钥的连接就销毁旧密钥,然后保存新密钥,如果是旧密钥就重新发送服务器DH参数。 这样的话,首先如果多个客户端都使用一样的密码只要一个客户端连接剩下的客户端就会失去同步连接不上了,自动防止密码公用。然后就算某个以前版本的密钥泄露了,因为不知道中途的DH参数也没办法推断出来未来的连接的加密密钥。 |
先前我已经提了一个 改协议 来实现前向安全等更高级特性的方案 #177 ,你提到的“改进的方法”与我之前已经提过的 #177 所实现的事情没有本质区别,反而更加复杂。但是当时他们不愿意改协议,所以这里的 #178 是以 不改协议 且同样不引入长期额外信道为前提的,基于此,目前没有发现更好的想法了。所以首先需要记住这些限制,然后说回想法本身:1.每个用户的密码变化规则都不同,且密码被复用的超低概率不会造成问题。2.旧密码未被摧毁的问题确实考虑过且值得关注,一般来说新密码会覆写硬盘上的旧密码,或者至少擦除旧密码,实现上需要参考一些现有的数据安全方案。最后还是重新提一下,这里是种种限制之下的方案,对比时不能忘记这一点。 |
As per #178 (comment), neither #177 and #178 gets you forward secrecy. Fundamentally, to get forward secrecy, you need key exchange, and key exchange seems to require public-key crypto [Impagliazzo-Rudich, STOC'89], and the key exchange protocols in neither of these proposals are secure when one party is compromised later. More importantly, Shadowsocks does not guarantee forward secrecy, and this could be easily mitigated by adding a TLS plugin. |
有趣,我觉得你完全无法理解我设计的这两个机制的精妙之处。 #178 在保持 0-RTT、不引入额外长期信道、不改 Shadowsocks / VMess 类通信协议结构的前提下,实现了当前存储的密钥泄漏并不会导致以前的绝大多数流量被解密,这是现在的静态 PSK 所无法做到的。 此外,对于 SS,这个机制还可以彻底识别长期重放攻击。 #177 在保持 0-RTT、不引入额外长期信道的前提下,通过精心设计的通信协议结构、密钥下发机制,相较于 Shadowsocks 实现了:
另一类方案是引入额外长期 TLS 机制来定期更新密钥,但无法实现 4 和 5(尤其是 4),而且都上 TLS 了为什么不直接用 TLS?TLS plugin 不是不可以,只是现在跑在 TLS 上的协议已经很多了,不缺 SS 这一个(且它没有 UoT),我还设计了性能 MAX 的 XTLS,它还会继续进化。另外 TLS 的缺点是暴露的信息多,所以我在这里就是设计非 TLS 上的协议,并且裸跑更符合 SS 原本/常规的用途。 |
I would like to thank @RPRX for notifying me to know about my incorrect understanding of words. I have removed a post I made previously about this topic. This scheme achieves forward security(to a certain extent) by making sure that future attacker will not be able to decrypt the traffic in previous sessions since the key has already been updated. This mechanic is similar to Rekey(11.3.) in Noise. I would also like to apologize to @RPRX for this. |
sorry that i'm started learning on the protocol or security base.
is |
For the record, I have designed the VLESS and XTLS protocols, and I started the Xray-core project a month or so ago.
So those involved in the discussion should have basic level of knowledge of protocol design, engineering practices, etc.
Here's another idea after #177. It can solve existing problem without changing the protocol,
but have one limitation.Note that none of my designs require the introduction of additional long-term channels or bring in identifiable features, which is the basic guideline.This requires the same time on both sides.And it's not recommended for multiple clients to share key.In addition, if the configuration is immediately imported to the user's client, actually the timestamp can be ignored during the import, thus eliminating the need to synchronize the time.
The text was updated successfully, but these errors were encountered: