[tor-dev] Proposal xxx: Safe cookie authentication
rransom.8774 at gmail.com
Tue Feb 7 18:25:03 UTC 2012
On 2012-02-07, Nick Mathewson <nickm at alum.mit.edu> wrote:
> On Sun, Feb 5, 2012 at 7:46 AM, Robert Ransom <rransom.8774 at gmail.com>
>> See attached, because GMail would wrap lines if I sent it inline.
> Added as proposal 193.
Remember to push it.
> 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.
Yes. I believe this is an existing protocol, except for the extra
(inner) HMAC (see next chunk of reply).
> 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.
I am, but that HMAC is meant only as a ‘tweaked message-digest
function’, so that we never ever compute
HMAC(potentially_secret_cookie_string, something_else). (It's
remotely possible that someone could have a 32-byte HMAC-SHA256 key
stored as a binary file; I want to keep the server from abusing such a
> 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
I'll think about this further.
> 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.
The server reveals its string first, thereby proving knowledge of the
secret (unless the client e.g. reuses a challenge, in which case it
deserves to lose) or access to an oracle for the server-to-controller
PoK. (If the server has access to an oracle, it can already
brute-force a low-entropy secret. An honest server's secret is not
low-entropy, so we don't have to worry about a client using this
This is also another reason that I used the weird HMAC-of-HMAC
construction for both proofs -- no one has an excuse for using a
protocol which this authentication protocol could be used to attack.
> 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.
The best that a controller can do without this protocol is to refuse
to use the cookie path Tor specifies in its response to a PROTOCOLINFO
command unless the controller's user has whitelisted that cookie path.
I don't know whether that would be acceptable to controller authors
More information about the tor-dev