[tor-relays] How can we trust the guards?

Aeris aeris+tor at imirhil.fr
Mon Jan 2 17:24:23 UTC 2017


> *any* sounds a little bit too optimistic IMO, but it reduces the risk of
> being deanonymized (always under the assumption of the threat model).

If family name is correctly defined, Tor ensure you will only use one of those 
nodes on your circuits.

If family name not correctly defined, Tor project will try to contact operator 
to define one :
	https://lists.torproject.org/pipermail/tor-relays/2016-December/011112.html
	https://lists.torproject.org/pipermail/tor-relays/2016-December/011402.html
	https://lists.torproject.org/pipermail/tor-relays/2016-December/011416.html
Without action, nodes may be blacklisted if suspicious. And even if not, /16 
restriction will apply, and never 2 nodes on the same /16 will be used.

If attacker nodes have no family name and not in few /16, we are typically in 
a sybil attack and Tor network tools might report the trouble.
	https://gitweb.torproject.org/user/phw/sybilhunter.git/
	https://lists.torproject.org/pipermail/tor-consensus-health/2014-November/
005252.html

Sure, all those protections are not perfect. Adding new relays few at a time 
to stay under the sybil attack detection level, without common pattern (IP, /
16, node name, AS…), during a lot of time to control most of the nodes may 
remain undetected.
But currently, seems not the case at least for guard and exit which are well 
known or documented most of the time or at least for the biggest part of the 
consensus.

More than money, such undetected attack requires global organisation to 
subvert and subponea enough people (network admin, sys admin, companies, 
hardware hosting…) to build it. It's more planetary conspiracy theory than 
anything else.

Regards,
-- 
Aeris
Individual crypto-terrorist group self-radicalized on the digital Internet
https://imirhil.fr/

Protect your privacy, encrypt your communications
GPG : EFB74277 ECE4E222
OTR : 5769616D 2D3DAC72
https://café-vie-privée.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20170102/ecdc397c/attachment-0001.sig>


More information about the tor-relays mailing list