[tor-dev] Temporary hidden services

Michael Rogers michael at briarproject.org
Mon Oct 22 14:26:08 UTC 2018

On 19/10/2018 16:05, Leif Ryge wrote:
> 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).

Hi Leif,

Thanks for pointing this out - I'd heard about this kind of attack but
I'd forgotten to consider it.

We're planning to do a key exchange at the application layer after
making the hidden service connection, so I don't think the adversary's
ability to impersonate Alice's hidden service to Bob would necessarily
lead to application-layer impersonation on its own. But if you hadn't
raised this we might have designed the application-layer key exchange in
a way that was vulnerable to KCI as well, so thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x11044FD19FC527CC.asc
Type: application/pgp-keys
Size: 16659 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20181022/7dfac8ac/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20181022/7dfac8ac/attachment.sig>

More information about the tor-dev mailing list