[tor-relays] Giving away some "pre-warmed" relay keys for adoption

Kurt Besig kbesig at socal.rr.com
Sun Jul 26 03:44:56 UTC 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/25/2015 7:13 PM, Roman Mamedov wrote:
> On Sun, 26 Jul 2015 01:35:10 +0000 Yawning Angel
> <yawning at schwanenlied.me> wrote:
> 
>> 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.
> 
> Yeah perhaps I should have mentioned that people should request one
> if they are absolutely certain that their server is capable of
> handling at least 50+50 Mbit of bandwidth.
> 
>> * The flag assignment process.  A random person should not get
>> the Guard or Stable flag quickly.
> 
> ...and that they expect it to have a certain degree of stability.
> :)
> 
> Sure this is a shortcut of sorts, and it's one that you should take
> if you believe you can "vouch" for things like stability and b/w
> capacity you can provide, and want to "skip the formalities" a bit
> so to say, and start contributing to the maximum extent possible
> immediately; surely nobody likes paying for idle servers.
> 
> Either way you won't do much damage even if any of this ends up
> being false, as the consensus weight and the stable status will
> drop more rapidly than they are gathered if your node can't
> maintain them.
> 
>> Yes, in an ideal world the bwauths will scan new relays faster.
> 
> Meanwhile in reality the outcome is often [1].
> 
>> 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 do this extensively on my relays, as one VPS or dedicated server
> expires, gets terminated or canceled for various reasons, a
> different one takes its place, inheriting the same identity. If I
> had to always wait for new relays to spin up from scratch in each
> case, a lot of the time I probably wouldn't even bother.
> 
> Running 20 relays in a declared family at the moment, together
> comprising about 1.8% of aggregate Tor bandwidth, however due to
> financial reasons I will have to shut down most of these over the
> coming weeks and months; so I see little difference if the next
> machine inheriting a particular identity this time will be managed
> and paid for by someone else and not by me. Just throwing these 
> away seemed like a waste.
> 
> [1]
> https://lists.torproject.org/pipermail/tor-relays/2015-June/007203.htm
l
>
> 
> 
> 
> _______________________________________________ tor-relays mailing
> list tor-relays at lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
Have a great life....bye.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJVtFe4AAoJEJQqkaGlFNDPtU8H/3UIFfTTE9ME/IESQ/rQnpDR
VW3CBGW+00r9IyK/dGy0B07R27ksr+6WwAhfJnHvzrRJxkmViNUNyW7RD6ah32jI
PuWyUPfR0eVYLNUBRVs2VJQQcoPP/GJkKTEto7y3OBwBqKgo9Ubt43YC8DH4X0Vb
+qybBb0/jkQGc7rgre8EYbWXW8qkSVUVOKhVF1lNJW1XrcaWnFnJgT9/af4ATarS
87rUr2Jf6wnx2R4y6ksK3si/Rc/TolXILIDbYywwSxoZfLjarJQDDPTREGX7z4rM
Nk6NpJM7x34hPUdNkW9b0dGdrH2he+3MffsJDRHl0CZm7LMFcKDTjxs7UZtBt9Y=
=4ibD
-----END PGP SIGNATURE-----

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



More information about the tor-relays mailing list