- tor-relays - lists.torproject.org

Re: [tor-relays] What's a "useful" relay?
by balbea16 24 Dec '16

24 Dec '16

Hi There I am actually a little bit confused now. I am one of (as Rana knows) those Pi 3 based OR operators with daily changing IP address. My consensus weight is about 5,000, with a max. of 1,400 connections. I would like to recomment, that the TOR org should publish minimum requirements to run a relay. And, if my kind of relays would bring disadvantage to the network, I would shut it off. So far, I think, that small and large relays in combination are good for anonymity. Mike

3 3

2bithacker.net relays: please specify MyFamily in torrc
by nusenu 24 Dec '16

24 Dec '16

Hi Chip Marshall, thanks for adding so many new FreeBSD relays! Please do not forget to set the MyFamily parameter in your torrc configuration to tell clients your relays belong to a single operator. Since you know ansible already you might also use it to do that automatically. If you need help with the MyFamily option let us know. thanks, nusenu https://github.com/nusenu/ansible-relayor ornetradar(a)riseup.net: > 2016-12-23 > ----------------------------------------------------------------------------------------------------------------------- > Up|Ext|JoinTime| IP | AS | CC | ORp | Dirp | OS | Version | Nickname | eFamlen > ----------------------------------------------------------------------------------------------------------------------- > 1 | 0 | 02:32:38 | 82.196.8.232 | None | nl | 9090 | 9030 | FreeBSD | 0.2.8.11 | 2bitnlams02 | 1 > 1 | 0 | 02:32:32 | 46.101.21.201 | Digital Ocean, | gb | 9090 | 9030 | FreeBSD | 0.2.8.11 | 2bitgblon01 | 1 > 1 | 0 | 02:32:38 | 139.59.0.37 | Digital Ocean, | in | 9090 | 9030 | FreeBSD | 0.2.8.11 | 2bitinblr01 | 1 > 1 | 0 | 02:32:35 | 162.243.115.59 | Digital Ocean, | us | 9090 | 9030 | FreeBSD | 0.2.8.11 | 2bitusnyc02 | 1 > 1 | 0 | 02:32:35 | 45.55.50.151 | Digital Ocean, | us | 9090 | 9030 | FreeBSD | 0.2.8.11 | 2bitusnyc03 | 1 > 1 | 0 | 02:32:35 | 107.170.205.8 | Digital Ocean, | us | 9090 | 9030 | FreeBSD | 0.2.8.11 | 2bitussfo01 | 1 > 1 | 0 | 02:32:34 | 159.203.33.54 | Digital Ocean, | ca | 9090 | 9030 | FreeBSD | 0.2.8.11 | 2bitcator01 | 1 > 1 | 0 | 02:32:37 | 138.68.0.4 | Digital Ocean, | us | 9090 | 9030 | FreeBSD | 0.2.8.11 | 2bitussfo02 | 1 > 1 | 0 | 02:32:34 | 188.166.241.75 | Digital Ocean, | sg | 9090 | 9030 | FreeBSD | 0.2.8.11 | 2bitsgsin01 | 1 > 1 | 0 | 02:32:33 | 46.101.166.19 | Digital Ocean, | de | 9090 | 9030 | FreeBSD | 0.2.8.11 | 2bitdefra01 | 1 > 1 | 0 | 02:32:33 | 188.166.41.46 | Digital Ocean, | nl | 9090 | 9030 | FreeBSD | 0.2.8.11 | 2bitnlams03 | 1 > 1 | 0 | 02:32:32 | 198.199.72.150 | ServerStack, In | us | 9090 | 9030 | FreeBSD | 0.2.8.11 | 2bitusnyc01 | 1 > Fingerprints: > C3F631DE3EC41854168600AE1AE5728A2EA55CBC,0386ADA6F685FABB04E529C5ED49C3DCFB92A73B,2685BFE15151FEB867E1CD27DCACFB8DA39002E5,D93DDF11BD3F58403A2A94EA62C7FA3D415E9FDF,A144C89AEAD0F9CD38A90A1F2FDF9B21592E6799,F45A1231CD1EC9096FD65142E50B940B3E2B384B,71A61E23D16187ACED135530B606FE052CFF763C,6CF9DFBA9B9304706781F10EB4787DB1BFBFF048,E3BC5F5196C140903D3D46029C2340C79C9BF17C,E7EEA1B771C1DF30684DC200338EA7F6EBAF3858,04FBD9ADF8947F925C4C5D3A57A9B0215251EE7A,E4AE28405E6D1D14E0681491A27FFDDC06643B77 >

1 0

Re: [tor-relays] [tor-r@elays] What's a "useful" relay?
by Rana 24 Dec '16

24 Dec '16

@Ivan >If you think that your relay is underrated or has poor performance try to adjust your hardware/settings. Anyway almost every relay operator has this kind of "operator anxiety". Don't worry. ;) It is not about anxiety. The last thing that would cause anxiety for me is the possibility to find another cool project for my Pi :) >If there were only blazing fast relays it would decrease anonymity because these relays would be placed in some datacenters and operated by small amount of people (entities). >Tor network needs all kinds of relays to be strong. Diversity is about platform, location, connectivity, etc, etc. While I hold the same opinion as you (intuitively) I am interested not in intuition but in in a sober technical analysis, and not in words of encouragement, or in the customary "thank you thank you thank you for running a relay" I hear opinions here that small relays are not really useful, and about small bridges I heard here that they are actually causing DAMAGE. Those opinions were backed by technical arguments, here are a few: - the numerous small relays that change their IP addresses burden the network unnecessarily with frequent re-publishing of their descriptors - small relays that carry a small number of circuits actually DESTROY anonymity since the small number of circuits going through them makes it easier to de-anonymize traffic; - anonymity is much better served by a few large relays since they carry a lot of circuits simultaneously, and for this reason DirAuths try to saturate them before they direct traffic to small relays - the connections through small relays are quickly saturated, making using the internet a horribly slow and unpleasant experience - Isis, the bridge db and bridge authority operator, has asked Tor people who make decisions NOT to recommend that people run bridges on their small residential connections, because the need to re-distribute information about changed IP addresses is a major hurdle towards bridge adoption Or as one DirAuth operator summarized it: "On balance, the very small relays do not contribute enough resources compared to the associated costs to be worthwhile." All of which is exactly the opposite of what you are saying and what was also my intuitive opinion. So I am interested to know if there are solid, TECHNICALLY SOUND opinions in favor of use of small relays. If running a small relay is just for feeling good and displaying political support for privacy rights, then I am outta here. I feel good already and I have other means of expressing my political support. Rana

2 1

Tor Relay on ARM server Marvell Armada 370/XP
by Fabio Pietrosanti (naif) - lists 23 Dec '16

23 Dec '16

Hello, i'm experimenting Tor setup on very cheap servers from scaleaway.com that run a quad-core ARM Marvell Armada 370/XP servers but have unlimited bandwidth. Those are Soc platform: http://natisbad.org/NAS2/refs/Marvell_ARMADA_370_SoC.pdf I saw no information on torproject mailing list about those SOC. I'm trying to push the limits and i saw that those have a crypto acceleration support: https://www.kernel.org/doc/Documentation/devicetree/bindings/crypto/marvell… However with kernel 4.5.7 it does not really work and loading of marvel-cesa gives out error: [6.841862] marvell-cesa: probe of d0090000.crypto failed with error -22 :( I've only built latest Tor 0.2.9 with -O9 -mcpu=marvell-pj4 -mtune=xscale and the Tor Relay is at https://atlas.torproject.org/#details/82C63C5D61D17557B7C5D0E7FDC545A2B6B6B… . Does someone have experienced optimizing and tuning Tor specifically on ARM processors to understand how far those could be optimized? -naif

5 7

What's a "useful" relay?
by Rana 23 Dec '16

23 Dec '16

So - what's the metric for calling a middle relay "useful"? Is it the total number of bytes that it relays daily? https://atlas.torproject.org/#details/707A9A3358E0D8653089AF32A097570A96400C C6 is sending about 0.85 GB every 24 hours. Is it a "useful" relay?

2 1

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
by Rana 23 Dec '16

23 Dec '16

@Patrice: Yes both relays started with brand new identities and the one that is now clinically dead (nickname ZG0) has been wiped out and restarted with a new fingerprint AND a new IP address as I have a dynamic one and I rebooted my router to get a new one). Did not help, so obviously this has everything to do with the network and how dirauths/bwauths test the connection and vote, and absolutely nothing to do with the identity of the relay See my previous messages to confirm that this has absolutely nothing to do with the capabilities of the Pi, which are a gross overkill for the use of (nickname) GG2 that the dirauths and bwauths allow. -----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of Patrice Sent: Thursday, December 22, 2016 2:57 AM To: tor-relays(a)lists.torproject.org Subject: [tor-relays] @Rana - with reference to: Unwarranted discrimination of relays with dynamic Hi, I`ve read your post and questions, also about your 2 Raspberry PIs with the same setting but different locations. I thought about it and my question is: Did these to PIs got a new fresh identity on day zero? If not, it`s worth a try, probably. Kill the old identities and let them by. My fundamental idea is (and that`s why I am writing this): Does my behaviour with the relay (restarting, upgrading, not be onlinening) effect the measurement and therefore the throughput of my relay? Cheers, Patrice _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

7 15

Re: [tor-relays] Is AES-NI enabled in tor?
by Patrice 23 Dec '16

23 Dec '16

> Please don't mix multiple questions into one thread. Sorry, my bad. > Tor does not implement crypto itself (mostly) and relies on a > cryptolibrary (which is OpenSSL/LibreSSL/etc) instead. Thus you should > check if AES-NI is enabled in your cryptolibrary. > > An excerpt from StackOverflow answer [1] about it: > > $ openssl speed -elapsed -evp aes-128-cbc > > $ OPENSSL_ia32cap="~0x200000200000000" openssl speed -elapsed -evp > aes-128-cbc > > "Output of the first line should be significantly faster than the > second." If there is no AES-NI enabled in "OpenSSL" these two should > give similar results. I couldn't do that test. OpenSSL was not installed. After I installed it I could perform that test and it was positive. Here is the output: $ openssl speed -elapsed -evp aes-128-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-128-cbc for 3s on 16 size blocks: 33370007 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 13118341 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 3915543 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 1029134 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 130438 aes-128-cbc's in 3.00s OpenSSL 1.0.1t 3 May 2016 built on: Fri Sep 23 17:53:23 2016 options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 177973.37k 279857.94k 334126.34k 351277.74k 356182.70k $ OPENSSL_ia32cap="~0x200000200000000" openssl speed -elapsed -evp aes-128-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-128-cbc for 3s on 16 size blocks: 6232419 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 1776077 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 454887 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 114409 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 14327 aes-128-cbc's in 3.00s OpenSSL 1.0.1t 3 May 2016 built on: Fri Sep 23 17:53:23 2016 options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 33239.57k 37889.64k 38817.02k 39051.61k 39122.26k But it is a little confusing for me because there is this line in the logs: Tor 0.2.9.8 (git-a0df013ea241b026) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8. From that I thought Tor used already OpenSSL but it wasn't installed. :S I bought this board with this CPU (incl. AES-NI support) because I thought it would give a benefit. > N.B. AES-NI is not a feature of*motherboard* - it's CPU instructions > (NI stands for "New Instructions"). I simply forgot that. ;) Cheers, Patrice

2 1

Re: [tor-relays] tor-relays Digest, Vol 71, Issue 93
by Patrice 22 Dec '16

22 Dec '16

Thank you! That was already the answer. :) > You will not see anything in logs until this value isn't good and was > adjusted by tor. For details, see compute_real_max_mem_in_queues() > function in /src/or/config.c. Cheers, Patrice

1 0

A Question about aes-ni and the use of RAM.
by Patrice 22 Dec '16

22 Dec '16

Hi, does anyone know if the aes-ni support of the motherboard is used by default? (I saw nothing in the logs.) At the beginning I thought so but than I stumbled upon this option: > HardwareAccel 1 After I edited my torrc, this line showed up in my logs: Dec 21 17:34:41.000 [notice] Default OpenSSL engine for RSA is RSAX engine support [rsax] ------------------------------- And my other question is, does tor recognize this option? > MaxMemInQueues 7000 MByte Because I see nothing in the logs. I am not 100% sure but I think tor gave a feedback when I used this option in the earlier versions. Cheers, Patrice

2 2

@Rana - with reference to: Unwarranted discrimination of relays with dynamic
by Patrice 22 Dec '16

22 Dec '16

Hi, I`ve read your post and questions, also about your 2 Raspberry PIs with the same setting but different locations. I thought about it and my question is: Did these to PIs got a new fresh identity on day zero? If not, it`s worth a try, probably. Kill the old identities and let them by. My fundamental idea is (and that`s why I am writing this): Does my behaviour with the relay (restarting, upgrading, not be onlinening) effect the measurement and therefore the throughput of my relay? Cheers, Patrice

1 0