[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Proposal xxx: Safe cookie authentication
On 2012-02-07, Nick Mathewson <nickm@xxxxxxxxxxxx> wrote:
> On Sun, Feb 5, 2012 at 7:46 AM, Robert Ransom <rransom.8774@xxxxxxxxx>
> wrote:
>> 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
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'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
attack.)
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
and users.
Robert Ransom
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev