ricochet-im
Question: Why does the protocol need to use the cookie for the signature?
Currently in the protocol documentation, I see that the proof signature is calculated as such:
// + represents concatenation, and function is HMAC-SHA256(key, message)
HMAC-SHA256(client_cookie + server_cookie,
client_hostname // base32-encoded client address, without .onion
+ recipient_hostname // base32-encoded server address, without .onion
)
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?
// + represents concatenation, and function is HMAC-SHA256(key, message)
HMAC-SHA256(client_hostname,
recipient_hostname // base32-encoded server address, without .onion
)
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: But we only need the server to come up with a cookie right? since if an attacker is listening in, he can himself set the cookie that fits as needed.
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.
Having both a client and server cookie means that both parties have to have broken cookie generation to violate the private key access proof.
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.
