[tor-dev] Temporary hidden services
Leif Ryge
leif at synthesize.us
Fri Oct 19 15:05:12 UTC 2018
On Wed, Oct 17, 2018 at 07:27:32PM +0100, Michael Rogers wrote:
[...]
> If we decided not to use the key blinding trick, and just allowed both
> parties to know the private key, do you see any attacks?
[...]
If I'm understanding your proposal correctly, I believe it would leave
you vulnerable to a Key Compromise Impersonation (KCI) attack.
Imagine the scenario where Alice and Bob exchange the information to
establish their temporary rendezvous onion which they both know the
private key to, and they agree that Bob will be the client and Alice
will be the server.
But, before Bob connects to it, the adversary somehow obtains a copy of
everything Bob knows (but they don't have the ability to modify data or
software on his computer - they just got a copy of his secrets somehow).
Obviously the adversary could then impersonate Bob to Alice, because
they know everything that Bob knows. But, perhaps less obviously, in the
case that Bob is supposed to connect to Alice's temporary onion which
Bob (and now the adversary) know the key to, the adversary can also
now impersonate Alice to Bob (by overwriting Alice's descriptors and
taking over her temporary onion service).
In this scenario, if Bob hadn't known the private key for Alice's
temporary onion that he is connecting to, impersonating Alice to Bob
would not have been possible.
And of course, if the adversary can successfully impersonate both
parties to eachother at this phase, they can provide their own long-term
keys to each of them, and establish a long-term bidirectional mitm -
which, I think, would otherwise not be possible even in the event that
one party's long-term key was compromised.
Bob losing control of the key material before using it (without his
computer being otherwise compromised) admittedly seems like an unlikely
scenario, but you asked for "any attacks", so, I think KCI is one (if
I'm understanding your proposal correctly).
~leif
More information about the tor-dev
mailing list