How knowing temp public key from real public key is actually prevented?

[nazar-pc]

Initially asked on IRC, but didn't get any answers.

To find the peers we have announced ourselves to, our friends will find the peers closest to our real public key and ask them if they know us.

This seems to contradict "prevent peers that are not friends from finding out the temporary DHT public key from a known long term public key". Can someone clarify this? Does implementation rely on client to be non-malicious and not disclosing this association?

[GrayHatter]

To find the peers we have announced ourselves to, our friends will find the peers closest to our real public key and ask them if they know us.

You don't announce your self to other peers. You announce yourself (via the onion) to the DHT peer closest to your toxid.

[GrayHatter]

Having read your other issue, I better understand the question here. If I'm not mistaken when querying the DHT for the address of a friend. You're give an onion path to that DHT node. Then when you, want to connect to me, you give MY close node YOUR public key, which MY close node will forward to me. If you're really in my friends list. I can start a connection attempt to you.

I believe this is how it's works but It's been a long time since I've worked in that section of code, and I never verified that this is correct.

[nazar-pc]

Then when you, want to connect to me, you give MY close node YOUR public key, which MY close node will forward to me.

Which means friend's close node knows friend's long term public key and IP_Port, right?

If this is the case, what if malicious client will not only forward requests, but also disclose this information directly to anyone who is asking for long term public key (through some protocol extension or otherwise, doesn't really matter if it still implements the rest of the spec)?

[nurupo]

@irungentoo can you comment on the opening comment?

[zugz]

• Sunday, 2017-07-23 at 00:39 +0000 - Nazar Mokrynskyi notifications@github.com:

Then when you, want to connect to me, you give MY close node YOUR public key, which MY close node will forward to me.

Which means friend's close node knows friend's long term public key and IP_Port, right?

Onion routing is used to prevent this. All communication with these nodes is done over the onion, bouncing the request via multiple (3) peers. Assuming the first peer in the route is not colluding with the destination peer, and assuming no network-level attacks, the destination peer should not be able to determine the IP_Port of the sender. But they will be able to get a message back, by using the same onion route in reverse.

It might be nice to have an overview section in the spec, explaining general concepts like this without getting into implementation details.

[nazar-pc]

I might not understand it enough and ask a stupid question, but does this mean target node can send multiple responses to the request (namely forward queries in response to an announcement) while those temporary symmetric keys are not expired? (I thought it is not possible because of packet id that is used only once in each direction)

[zugz]

• Sunday, 2017-07-23 at 07:16 +0000 - Nazar Mokrynskyi notifications@github.com:

does this mean target node can send multiple responses to the request (namely forward queries in response to an announcement) while those temporary symmetric keys are not expired?

If I understand correctly your question, this is dealt with by the no_replay field in the DHT public key packet.

[nazar-pc]

I'm talking about another aspect. If 2 of my friends ask the same node to forward request to me, will the node be able to forward both of the requests or just the first one?

[zugz]

• Sunday, 2017-07-23 at 08:04 +0000 - Nazar Mokrynskyi notifications@github.com:

I'm talking about another aspect. If 2 of my friends ask the same node to forward request to me, will the node be able to forward both of the requests or just the first one?

Both. (I'm assuming here that we're talking about data-to-route onion packets.)

[nazar-pc]

Thanks for your answers!

[nurupo]

I'm glad that there is a couple of eyes that read the spec and ask such questions. Specification review is a good thing. Don't think there are that many people who have read the spec and understood it.