[tor-dev] Proposal 332: Ntor protocol with extra data, version 3.

[Ian Goldberg]

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 at 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.]