On Mon, Jul 12, 2021 at 03:09:02PM -0400, Nick Mathewson wrote:
On Mon, Jul 12, 2021 at 3:04 PM Ian Goldberg iang@uwaterloo.ca wrote:
On Mon, Jul 12, 2021 at 12:01:47PM -0400, Nick Mathewson wrote:
Both parties know that they used the same verification string; if they did not, they do not learn what the verification string was. (This feature is required for HS handshakes.)
I'm not sure the protocol you specify has this feature as written. For example, if the verification string has low entropy, the server could brute-force the client's verification string (using the MAC to check its guess). This is unlike, say, OTR's SMP or a PAKE, in which each online execution of the protocol allows the server just one guess.
But perhaps you don't actually need the property in as strong a form as you wrote it, since the HS handshake application has high-entropy secrets?
Oh yes, you are right, of course.
Can you suggest a way to phrase this property that encompasses what the protocol actually does provide?
Could I convince you to use a hash (domain-separated but not keyed) of VER instead of ENCAP(VER)? Then you could say that the protocol reveals no more about VER than H_verstr(VER) does. [Note: H_verstr is different from H_verify.]