[tor-dev] Proposal xxx: Safe cookie authentication

[Nick Mathewson]

On Sun, Feb 5, 2012 at 7:46 AM, Robert Ransom <rransom.8774 at gmail.com> wrote:
> See attached, because GMail would wrap lines if I sent it inline.

Added as proposal 193.

This seems like a general case of "A and B prove to each other that
they both know some secret S without revealing S."  Are there existing
protocols for that with security proofs?  It seems like something
that's probably been done before.

I wonder, have you got the HMAC arguments reversed in some places?
When you do HMAC("string", cookiestring), you seem to be using the
secret thing as the message, and the not-secret thing as the key.

This would be a little easier to read if the function
HMAC(HMAC(x,y),z) were given a name.

Part of me wants to to incorporate both the ClientChallengeString and
ServerChallengeString in both of the authenticator values, just on the
theory that authenticating more fields of the protocol is probably
smarter.

I'd note that this doesn't actually prevent information leakage
entirely.  Instead of making you reveal some secret 32-byte file S,
the attacker now makes you reveal HMAC(HMAC(k,S),c), where k is
constant and the attacker controls c.   That's fine if S has plenty of
entropy, but not so good if (say) S has 20 bytes of predictable data
and 12 bytes of a user-generated password.  Then again, I'm not so
sure a zero-knowledge protocol is really warranted here.

I am leery of adding this to 0.2.3.x (which is in feature-freeze),
much less backporting it, but I'm having a hard time coming up with a
way to do this entirely in the controller, so I guess we could call it
a "security fix" rather than a "feature" if we can't think of another
way to kludge around the problem.

yrs,
-- 
Nick