On Sun, 26 Jul 2015 05:32:17 +0500 Roman Mamedov rm@romanrm.net wrote:
On Sat, 25 Jul 2015 19:47:23 +0000 isis isis@torproject.org wrote:
I could take those backdoored^W"pre-warmed" keys and put them to good use!
Hello,
Mkay, I'll get in touch in a few days.
As for other repliers, I would not mind explaining my reasoning in more detail, if you have any specific questions or more articulated objections that a knee-jerk "ban it" or "lolz" reactions.
What was knee-jerk about my response?
The relay identity key is sensitive cryptographic material. Sharing it means the private key is compromised and is an attempt to subvert:
* The bandwidth scanning process. The consensus weight is the relay's capacity relative to other nodes in the network which will change and should be reset if the location of the relay changes.
Yes, in an ideal world the bwauths will scan new relays faster. But that's orthogonal to the need to reset/remeasure on IP address change.
* The flag assignment process. A random person should not get the Guard or Stable flag quickly.
The only thing a compromised relay should be used for is as a middle node and never a HSDir, so the correct behavior on the DirAuth side is to never assign the Valid flag to said relays.
A fun task for someone who likes messing with consensus documents and descriptors would be to write a script to measure IP address churn for relays while the relay identity remains constant (either legitimately eg: being on a dynamic IP, person had to move the rack the relay was on, or through key compromise/derp).
I'm of the opinion that it may be worth adding code to pin relay identities to IP addresses on the DirAuth side so that consensus weight and flag assignment gets totally reset if the ORPort IP changes, but if there's too much churn already it may cause more trouble than it's worth.
Regards,