[tor-bugs] #20895 [Core Tor/Tor]: Split node_supports_ed25519_link_authentication into two or three separate functions

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Sep 11 13:44:36 UTC 2017

#20895: Split node_supports_ed25519_link_authentication into two or three separate
 Reporter:  nickm         |          Owner:  nickm
     Type:  task          |         Status:  accepted
 Priority:  Low           |      Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:  refactor      |  Actual Points:
Parent ID:  #15054        |         Points:  2
 Reviewer:                |        Sponsor:

Comment (by nickm):

 > Sometimes, when we use it, we mean, "If we try to connect to this node,
 should we expect that we will authenticate its ed25519 identity?"

 This is what is currently implemented by

 It's what we want for the instances currently in connection_or.c and
 dirserv.c, and one of the two instances in circuitbuild.c.

 The logic here is that we know which link authentication versions we
 support, so we know that if we try to use an ed25519 link authentication
 mechanism, it has to be one of the ones we support.

 > Sometimes, we mean "If we try to make a connection through some random
 node to this node, authenticating with its ed25519 identity, will that

 This seems to be what we want for one of the two instances in
 circuitbuild.c, and the instance in hs_service.c.

 The real question in this case is, "should we tell people to use the
 ed25519 id for node X when it supports some link authentication mechanism
 we don't even recognize, if it doesn't support linkauth=3"?

 I think "yes".  I'll write a patch.

 > And sometimes we mean "I'm thinking of asking _that_ node to extend a
 circuit to _this_ node. Should I tell it about _this_ node's Ed25519
 identity, or would it take it the wrong way?"

 This invokes a concept we don't currently have: the idea that two well-
 behaved supported relays might not be able to talk to one another.  We
 aren't planning to change this soon, and if we do, it will take more
 machinery, so I suggest we ignore it.

Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20895#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

More information about the tor-bugs mailing list