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
Question: Why does the protocol need to use the cookie for the signature? #565
Comments
I believe this prevents attacks where the attacker is able to steal or otherwise get the Proof Spec but not compromise the private key. For example, let's say we have 2 contacts Alice and Carol. Under the current scheme every proof spec that Alice sends to Carol is unique, because of the cookies - you cannot use a past proof spec in a future connection. The cookies keep the proof session specific, and requires (and therefore proves) access to the private key during authentication. If we remove the cookies, the proof spec for when Alice connects to Carol is always identical. If someone is e.g. able to intercept traffic between ricochet and Tor then they can steal this proof spec, giving them the ability to authenticate themselves to Carol pretending to be Alice in the future. |
That's what I was thinking as well, just wanted to make sure: |
I kind of agree. Assuming the server always generates a unique random cookie per session I cannot see an attack in which proof or protocol security is compromised by just having server cookies. If a bug allowed server cookie reuse, meaning Alice's proof is always the same, this would break the proof of private key access for Alice...but would be a bug in the server. Having both a client and server cookie means that both parties have to have broken cookie generation to violate the private key access proof. I'm not sure how strong this argument is though. The client cookie adds a nice symmetry to the protocol, and prevents any one party having control over the HMAC key (but there should be no way an evil server can abuse this to trick the client into building a proof that would work to authenticate to another server?) I might have missed something and I'd like to see if @special has any insights on this. |
But a malicious client can just reuse whatever cookie it wants anyway. I don't think there's any real argument for removing the client cookie, but I don't see how it adds any security. |
Currently in the protocol documentation, I see that the proof signature is calculated as such:
Why is it necessary to exchange cookies? when using hidden service, the connection in Tor performs a Diffie Halman for every connection, so a replay attack would not be possible anyways? as the keys for the DH will be different for any new connection. why would it not be enough to do something like this?
The text was updated successfully, but these errors were encountered: