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

IAQ: why does the spiped protocol compute dhmac_C and dhmac_S? #151

Closed
eugeneia opened this Issue Dec 7, 2017 · 6 comments

Comments

Projects
None yet
2 participants
@eugeneia
Copy link

eugeneia commented Dec 7, 2017

I am wondering why the spiped protocol computes dhmac_C and dhmac_S, and uses those for the HMAC keys for protecting the public keys, instead of just using the original PSK for the HMAC and computing the HMAC over both nonces and the pubic key? Or even just computing the HMAC over the public key we are being sent and the nonce choosen by us?

I’m not sure if this is an OK place for an infrequenty asked question, apologies in advance if its not.

@cperciva

This comment has been minimized.

Copy link
Member

cperciva commented Dec 7, 2017

If I'm understanding your question correctly: The point is to prevent replay attacks. If the DH parameters are authenticated using only the fixed PSK or using the PSK + the nonce of the sender, then the pair (y, h) won't depend on the other party's nonce.

We could have computed h_C = HMAC-SHA256(K, nonce_C || nonce_S || y_C) instead of computing derived keys and then using those; that would have been cryptologically equivalent.

@eugeneia

This comment has been minimized.

Copy link

eugeneia commented Dec 7, 2017

Do we really need to include the other side’s nonce though? My train of thought: if we had computed just

h_C = HMAC-SHA256(K, nonce_S || y_C)

we can tell that its indeed a valid response to our “request” since it depends on the nonce we (the server) sent. What does including the other parties nonce give us?

Some background: I am picking apart the spiped protocol for inspiration, because its the simplest, most trustworthy, and closest-to-my-usecase specification I could find (any pointers to other prior art for research are welcome). Basically, I am trying to figure out how much I can simplify (in terms of total number of operations and number of algorithms) the spiped protocol without breaking it, using the algorithms offered by a current version of libsodium.

@cperciva

This comment has been minimized.

Copy link
Member

cperciva commented Dec 7, 2017

I'm not absolutely sure if there's any need for nonce_C to be included in the computation of h_C. I'd have to give this very careful thought, however -- if you don't include nonce_C in that (and similarly don't include nonce_S in the computation of h_S) then an spiped server has turned into an oracle which, given a value nonce_C, will supply you with an arbitrarily large number of pairs (y, HMAC(K, nonce_C || y)).

With a bit more thought, this seems like a way to execute a low-bandwidth DoS attack by making an spiped server perform DH key exchanges with itself -- I don't think this is possible with the protocol as designed.

@eugeneia

This comment has been minimized.

Copy link

eugeneia commented Dec 7, 2017

I think the situation you describe is not possible because the server will only respond with the pair (y_S, HMAC(K, nonce_C || y_S)) once it has received and validated the opposite pair
(y_C, HMAC(K, nonce_S || y_C)).

But you are right, I have to give this cautious thought. I did come up with some quite broken stuff before. (-;

@cperciva

This comment has been minimized.

Copy link
Member

cperciva commented Dec 7, 2017

Hmm, you may be right there. Still, hashing in all of the previous inputs to the protocol state costs approximately nothing, and it means that we don't need to worry about edge cases like this, so it's a standard approach used in cryptographic protocol design.

@eugeneia

This comment has been minimized.

Copy link

eugeneia commented Dec 7, 2017

I see, its a design pattern! Thank you for taking the time to explain! 🙇

@eugeneia eugeneia closed this Dec 7, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment