Re: [tor-relays] MaxOnionQueueDelay

2013-10-01 Thread nsane
*bump* On Fri, Sep 27, 2013, at 11:37, nsane wrote: > Hello, > > there is a Tor setting "MaxOnionQueueDelay" in torrc (see > https://www.torproject.org/docs/tor-manual-dev.html.en) with a default > of "1750 msec". > > As operator of a Tor relay 0.2.4.17-rc (on Debian) I would like to know > wer

Re: [tor-relays] MaxOnionQueueDelay

2013-10-01 Thread Roger Dingledine
On Fri, Sep 27, 2013 at 11:37:55AM +0200, nsane wrote: > Hello, > > there is a Tor setting "MaxOnionQueueDelay" in torrc (see > https://www.torproject.org/docs/tor-manual-dev.html.en) with a default > of "1750 msec". > > As operator of a Tor relay 0.2.4.17-rc (on Debian) I would like to know > we

Re: [tor-relays] tor 0.2.4.x on the Raspberry Pi. How to?

2013-10-01 Thread Gordon Morehouse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Martin Kepplinger: > In order to run an obfsproxy bridge on my Pi, I need tor from git > or tor's experimental repos; raspbian's packages are too old > right? > > I got confused with recent discussions on raspberry pi here. What's > the simples way

Re: [tor-relays] MaxOnionQueueDelay

2013-10-01 Thread Gordon Morehouse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 nsane: > Hello, > > there is a Tor setting "MaxOnionQueueDelay" in torrc (see > https://www.torproject.org/docs/tor-manual-dev.html.en) with a > default of "1750 msec". > > As operator of a Tor relay 0.2.4.17-rc (on Debian) I would like to > know

Re: [tor-relays] MaxOnionQueueDelay

2013-10-01 Thread nsane
Then this setting doesn't make any sense as an operator has no information or hints to set an appropriate value. So, there is no need for this setting in the torrc file. -- http://www.fastmail.fm - A no graphics, no pop-ups email service ___ tor-relay

Re: [tor-relays] hardware accelerated crypto

2013-10-01 Thread Andy Isaacson
On Fri, Sep 13, 2013 at 12:25:47AM +0200, Sarah Vigote wrote: > I would like to run a 100Mb/s tor exit node, but I have issues wrt > power consumption. > > reading > http://ortizaudio.blogspot.fr/2011/10/using-dreamplugs-crypto-chip.html > it seems dreamplugs has *fast* aes-128-ecb. > > Does anyo

Re: [tor-relays] hardware accelerated crypto

2013-10-01 Thread jason
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm not sure why I missed this first post but I'm very interested in working on this project with whomever is interested. I bought a pogoplug v2 specifically to test it's usefulness as a tor exit or relay. - -Jason On 10/01/2013 06:39 PM, Andy Isaacs

[tor-relays] Warnings in log

2013-10-01 Thread Konrad Neitzel
Hi all, I am running a tor node (idkneitzel) on a linux server (using opensuse 12.3). Today I saw: Oct 01 14:20:34.000 [warn] Failing because we have 8163 connections already. Please raise your ulimit -n. So I modified the /etc/security/limits.conf and added: * softnofile

Re: [tor-relays] Reimbursement of Exit Operators

2013-10-01 Thread Andy Isaacson
On Wed, Sep 18, 2013 at 09:07:14PM +0300, J.C. wrote: > Another amateur relay operator here, i run the node "namelesshero" > and I sure hope however this cost reimbursing plan eventually pans > out, it won't discourage small folk like us from running relays. I, > too, believe the exact opposite is

Re: [tor-relays] Relay security, re: local network

2013-10-01 Thread Andy Isaacson
On Thu, Sep 26, 2013 at 02:08:13PM +0300, Joe wrote: > I'll have to reconsider, then. I assume middle relays see less > traffic than exits? I don't think that's true, currently it seems we need more middle nodes than exit nodes based on my reading of the network statistics. > I also keep reading

Re: [tor-relays] Warnings in log

2013-10-01 Thread Roger Dingledine
On Tue, Oct 01, 2013 at 08:42:51PM +0200, Konrad Neitzel wrote: > I am running a tor node (idkneitzel) on a linux server (using opensuse > 12.3). > > Today I saw: > Oct 01 14:20:34.000 [warn] Failing because we have 8163 connections > already. Please raise your ulimit -n. > > So I modified the /e

Re: [tor-relays] hardware accelerated crypto

2013-10-01 Thread Andy Isaacson
On Tue, Oct 01, 2013 at 06:45:52PM +, jason wrote: > I'm not sure why I missed this first post but I'm very interested in > working on this project with whomever is interested. I bought a > pogoplug v2 specifically to test it's usefulness as a tor exit or relay. First step is, run "openssl sp

[tor-relays] Directory traffic

2013-10-01 Thread Jobiwan Kenobi
As of between 18:00 and 19:00 yesterday (9/30/13) directory traffic on my relay has gone up dramatically, from mere background noise to more than half my advertised bandwidth, and hasn't really come down since. I pasted the numbers from /opt/var/lib/tor/state into a spreadsheet and made a grap

Re: [tor-relays] Warnings in log

2013-10-01 Thread Konrad Neitzel
Hi! On Tue, 2013-10-01 at 15:00 -0400, Roger Dingledine wrote: > On Tue, Oct 01, 2013 at 08:42:51PM +0200, Konrad Neitzel wrote: > > So I modified the /etc/security/limits.conf and added: > > * softnofile 65000 > > * softnofile 65535 > Did yo

Re: [tor-relays] hardware accelerated crypto

2013-10-01 Thread jason
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I would love to do all this actually but I never managed to get the hw accelerated crypto (ssl/tls) bits working to experiment with. I'd be up for restarting this if I knew I could consult with one or two others who had a genuine interest in this. - -J

Re: [tor-relays] hardware accelerated crypto

2013-10-01 Thread Jeroen Massar
On 2013-10-01 21:20, Andy Isaacson wrote: > On Tue, Oct 01, 2013 at 06:45:52PM +, jason wrote: >> I'm not sure why I missed this first post but I'm very interested in >> working on this project with whomever is interested. I bought a >> pogoplug v2 specifically to test it's usefulness as a tor

[tor-relays] relays "in the cloud"

2013-10-01 Thread Jonathan D. Proulx
Hi All, There must be discussion of this I'm not finding so references to that are welcomed. As I understand it there are three risk layers in each Tor node: 1) The node operator (who has r00t) 2) The data center (who has net) 3) The legal jurisdiction I've recently started running a couple of

Re: [tor-relays] Warnings in log

2013-10-01 Thread Grozdan
On Tue, Oct 1, 2013 at 9:51 PM, Konrad Neitzel wrote: > Hi! > > On Tue, 2013-10-01 at 15:00 -0400, Roger Dingledine wrote: > > On Tue, Oct 01, 2013 at 08:42:51PM +0200, Konrad Neitzel wrote: > > > So I modified the /etc/security/limits.conf and added: > > > * softnofile

Re: [tor-relays] hardware accelerated crypto

2013-10-01 Thread Joshua Datko
I was looking into this for the BeagleBone black [1], which has on-chip accelerators for AES, SHA (1 I think), and md5. The TI processor also has a HWRNG. My belief was that by using the cryptodev kernel module [2] I could get this working, but I ran in some issues building the kernel and then I

Re: [tor-relays] Warnings in log

2013-10-01 Thread krishna e bera
On 13-10-01 03:00 PM, Roger Dingledine wrote: > On Tue, Oct 01, 2013 at 08:42:51PM +0200, Konrad Neitzel wrote: >> And now I also got the following warning: >> Oct 01 18:25:19.000 [warn] Cannot get strong entropy: no entropy source >> found. > > That sounds like a side effect of not having enough

Re: [tor-relays] relays "in the cloud"

2013-10-01 Thread Andy Isaacson
On Tue, Oct 01, 2013 at 04:42:53PM -0400, Jonathan D. Proulx wrote: > As I understand it there are three risk layers in each Tor node: > > 1) The node operator (who has r00t) > 2) The data center (who has net) > 3) The legal jurisdiction > > I've recently started running a couple of relays on pu

Re: [tor-relays] hardware accelerated crypto

2013-10-01 Thread Gordon Morehouse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I'm interested if there are any hardware accelerators in either the Raspberry Pi (which needs all the help it can get) or the Cubieboard 2 (A20-based). Best, - -Gordon M. Joshua Datko: > I was looking into this for the BeagleBone black [1], which

Re: [tor-relays] relays "in the cloud"

2013-10-01 Thread grarpamp
On Tue, Oct 1, 2013 at 7:35 PM, Andy Isaacson wrote: > In summary, it seems likely that IaaS is pwned wholesale. Colo hardware > is somewhat more expensive to attack and possibly succeeds in raising > the bar from "software" to "attacker has to roll a truck to pwn me", > which is my current recom