- tor-dev - lists.torproject.org

Hi, all!
by Nick Mathewson 05 Jul '15

05 Jul '15

I'm about to go on vacation, but before I started, Isabela asked me for coverage information on Tor, to help people decide where more tests should be written. I've re-run coverage, and uploaded the gcov output here: https://people.torproject.org/~nickm/volatile/coverage-65a1e27.tar.bz2 That archive includes coverage on current master from * make check * make test-network (uses chutney) * make test-stem (uses stem) * all of the above, combined I'm also attaching a script that I wrote long long ago, and use to summarize coverage file-by-file. Example use: gcov-lines.py ./coverage-65a1e27/cov-all/* yrs, -- Nick

2 1

Re: [tor-dev] Roster introduction (nusenu) (Sean Saito)
by saitosean＠ymail.com 05 Jul '15

05 Jul '15

Hi nusenu, > A few comments: > > - - the page seems to be AS name centric > - first column of the table is AS name > - only clickable column in the table is AS name > > - - the AS column suggests that all relays in a family run in one AS only > > - - the family page of a specific family shows the AS name as title, > this is a bit confusing as one might think that the page shows all > families/relays in the selected AS after clicking an as name on the > start page Agreed, this was just a placeholder. Will put contact info instead for now. In the future I would like families to have ids/nicknames as well. > Family identifier > > - - by looking at your page I assume your family identifier is the > fingerprint of the oldest relay in the family, does that mean that an > operator has to start over at 0 with collecting "points" once he kills > his oldest relay? That is not the case. Thanks for the comments! Sean

1 0

Bi-directional families in Onionoo and consensus weight as measure of relayed bandwidth
by Karsten Loesing 02 Jul '15

02 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Moving this discussion here from another list with Virgil's permission. On 02/07/15 08:42, Virgil Griffith wrote: > Big issues right now are: * Bugs (?) in Onionoo --- Onionoo doesn't > sanitize its data. For example, there's a lack of bidirectionality > between relays of many families. > https://drive.google.com/file/d/0Bwjagz1RgJOnSkx0YTlhMHdfMFU/view?usp=shari… > > There are currently about 665 pairs of family relays without > bidirectionality. This is caused by the .torrc of some relays not > pointing to its family members. > > I am considering doing a service on top of Onionoo that sanitizes > the raw Tor consensus to ensure things like bidirectional families. > It's unclear how much other data needs sanitization. I'd rather want to fix/change Onionoo than have you write another service that processes Tor descriptors. There's even a ticket for this, we're just somewhat stuck by arguing about the best fix. Maybe I should just fix it somehow and, if necessary, fix it more later. https://trac.torproject.org/projects/tor/ticket/16276 Would that solve your problem? What other problems would there be with Onionoo's data? Can you make a wish list? > * A semi-reliable measure for the magnitude of traffic a relay has > routed. We have confirmed instances of relays forging their > observed bandwidth, ergo we can't use that. And thus far > Consensus Weight is the best we've found, but it's unclear whether > we can use that as a proxy of magnitude of relayed traffic. --- > https://docs.google.com/document/d/1v1rutylD6RkBei9rEmSvsgmvQXhrIHXOr85NL3I… > > Right now the lack of a reliable measure of how much bandwidth is > relayed is the largest sticking point. Actually, consensus weight (fraction) is a fine measure, and I like how you're calling it "bandwidth points" in your prototype which doesn't imply a bits per second or related unit. I'd say assign 10,000 bandwidth points to all relays per day, depending on what fraction of total consensus weight a relay had. To me, it's fine that this doesn't translate to bits or bytes. How does that sound? All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVlPKJAAoJEJD5dJfVqbCrZWQH/0lHSdgy4PF7nQ8RMZryKpnf o3Fvw8VkcIwZgJgp0MOLIVu0fZhcD8hhvSWd9yYTSpQwGwBayUJuPE0ao4MbfZYf mwz5hkngzq1Z7654K65m/fYLu7EIbXI86vT4/Cwwh8cnGl/ezaliFVvVMOmKTyOb UtV7T+Lgk5IgsGJOxQbpNHCTxyAokbAygqZ9Eq/6ZWqjZFBZb1P2XjV+IaziGyJl yuxrD66cJe4ZmcpPe9g7mTa9JyQ5kmUOWogXhKTFWDFCcPslc0M49iiYohDmiNxC 5RGKp1dMuYkL6th9b3Uuc3W4TdCMaDHV96BDUD3qdlqCWBU0fD617f31+Hsb6Bg= =0KdX -----END PGP SIGNATURE-----

4 7

Tor Messenger Third Alpha
by Sukhbir Singh 01 Jul '15

01 Jul '15

Hi, Tor Messenger is an instant messaging client currently under development. It is designed to make connections using the Tor network and will therefore be a valuable piece in the privacy-enhancing software toolkit (web: Tor Browser, email: Thunderbird + TorBirdy, chat: Tor Messenger.) Based on the Instantbird IM client, Tor Messenger: - sends all traffic over Tor, - enforces Off-the-Record Messaging (OTR) for one-on-one conversations by default, - can be used with a wide variety of chat networks, - has an easy-to-use graphical user interface localized into multiple languages. * Current Status Today we are releasing the third alpha version with which we hope to gain both usability and security related feedback. There have been two previous alpha releases to the mailling lists that have already helped smooth out some of the rougher edges. * What's New in Tor Messenger 0.0.6 - Support for Windows and OS X builds (in addition to Linux) - Improved privacy and security with network and application-related enhancements - Improved usability of the Instantbird OTR extension - Private key and known fingerprint management - XMPP in-band account registration support - Build localization support (currently Arabic; Chinese, Spanish, Farsi, and other languages coming soon) * Bundles Linux (32-bit): https://people.torproject.org/~sukhbir/tor-messenger-0.0.6/tor-messenger-0.… Linux (64-bit): https://people.torproject.org/~sukhbir/tor-messenger-0.0.6/tor-messenger-0.… Windows: https://people.torproject.org/~sukhbir/tor-messenger-0.0.6/tor-messenger-0.… OS X: https://people.torproject.org/~sukhbir/tor-messenger-0.0.6/tor-messenger-0.… sha256sum: https://people.torproject.org/~sukhbir/tor-messenger-0.0.6/sha256sums.txt https://people.torproject.org/~sukhbir/tor-messenger-0.0.6/sha256sums.txt.a… The bundles are signed with the key 0xB297B391. * Instructions - On Linux, extract the bundle and then run: ./start-tor-messenger. - On OS X, copy the Tor Messenger application from the disk image to your local disk before running it. On all platforms, Tor Messenger sets the profile folder to the installation directory. * Code We are doing automated builds of Tor Messenger for all platforms using rbm (Reproducible Build Manager): https://gitweb.torproject.org/tor-messenger-build.git * Arabic Language Pack https://people.torproject.org/~sukhbir/tor-messenger-0.0.6/tor-messenger-ar… Install the language pack as an add-on and then set "general.useragent.locale" to "ar". (Thanks to Sherief Alaa for the translation.) * Feedback This is an early release and there may be serious privacy leaks and other issues -- please DO NOT recommend Tor Messenger to end users; this release is only for developers and advanced users who would like to help us with testing but understand the risks involved with using alpha software. With this release, we invite feedback not limited to anonymity leaks, usability issues, feature requests and suggestions for improvement. Please submit your feedback using the bug tracker (bugs.torproject.org; select the "Tor Messenger" component). You can also talk to us on this mailing list or on IRC. Thanks, Arlo Breault, Nicolas Vigier, Sukhbir Singh

3 4

Stormy update
by Griffin Boyce 01 Jul '15

01 Jul '15

Hey all, It seems like time to give the tor-dev list an update on Stormy's development. Right now, the scripts are undergoing third-party testing to identify any obvious bugs before sending them to security auditors. Testing should be finished imminently, any bugs found will be fixed this week, and then sent to auditors (along with the GUI). The security audit may take about two to three weeks [1]. Currently, Stormy's functions include installing typical onion service dependencies (webserver+tor), setting up a Ghost-based content management system, creating a personal cloud server to handle files/rss feeds/calendars/tasks, installing an XMPP/jabber server for private communications, and installing an IRC server for group communications. Shortcomings and future work: Like all software projects, Stormy has some shortcomings. Users can't configure multiple onion services on the same machine as Stormy doesn't account for virtual hosts. For users to run more than one onion service, they must be on separate physical or virtual machines. Stormy also doesn't detect the currently-running clearnet service, so users who seek to make their existing service also an onion service may need to adjust their configuration manually. Currently, Stormy lives on my github page [2], though once it passes a security audit, the goal is for it to live within Tor's git repositories. best, Griffin [1] Cupcake's audit took about two weeks, so that's really my only real data point for audit timing. [2] https://github.com/glamrock/stormy -- “Sometimes the questions are complicated and the answers are simple.” ― Dr. Seuss

2 1

Re: [tor-dev] Discussions
by Cory Pruce 01 Jul '15

01 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yep, you got it! People find it easiest to read mailing list posts if the subjects match. And the threading works better that way, too. Any time you reply to and quote a previous email, cut out the extra stuff the mailing list adds in. And cutting out people's long signatures helps, too. Imagine you've googled a problem, and you're reading each email by itself - what do people need to know to follow the conversation? > I see now about top-posting though :D > Thanks, we all do that from time to time - most mail clients automatically top-post. > I kept the mailing list in the > loop for the readpassphrase.h but it's your call where you want to go > through the environment. I'm cool either way :-) > Stick as much as you like on the mailing list. People will tell you if it's too much. In fact, I'll stick my reply to your question about testing on tor-dev, as it's relevant. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7 - --------------------------------------------------------------------------------------------- Awesome thanks Tim! I'm going to set up chutney later. Could you please send me the next steps you think would be good for a Tor testing environment? Thanks for your help! Cory -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVksKGAAoJEB7DuCIJauCgM7MP/1ZbuSuo53Mz/8YBzA8FZPX1 yATAWJudqPaPH0m1nQS72x2Bzarz5UhCCGq2YpAhocoo1rEam+wIqcSJ7KUVso1H 1ViuKRjUWjgevAB33zdCWkZZtaKhg/r8zFpqMD8VL6N2ae3ypiY+nnw0vyEJZNZf YnUjoH+YNab/ftRv16/d72bmzHeylVRBcJX6OmSzSlCuCWROlptez3hG+xl52NHv q1obXuyWn36ba8agIeo3OFIX7sQ9Ok3Hvyr/Sve9QEt+FnB24yswS5X3izl8MtZZ Rs9Kz/RZsrH8AGAWmz+h6IIdGK/cmycsLk7bQyDzWHjzuDuIOtvXe5B4xizmoNEW in0Qxg5LfSklc8nN2531AbMExMoQsOW7ciNbQK7lQQlm8ZRb5U/ghWhjKc6PqZ8Z bWGv/vQQyzOQofsgaOm9Tul8vOPGk/e7a5mWRLj167ZuFRY/9d8I4K2mdjm45OQT Lz/gloDCV61IcMzEmmj3Ga8U2oWDicmKbJeNk7RnD9nPNr3JR9yKLEDRUD59Fp43 i4ZplSV0eIFDzozx0aZnVE/ctqyK9wDWWBVaTbsJfXcdV5h+DfGbtzPIdq2CA/cl 1Id94kqqGL00MlYuzw0eHcH5ssUIpVRGg96njolcCFgE/ipfWrFCTW+dxpuXD+p2 0unsHjaY0Am+T+NMPmCr =v2h0 -----END PGP SIGNATURE-----

2 2

Re: [tor-dev] Discussions
by teor 30 Jun '15

30 Jun '15

> On 1 Jul 2015, at 01:29 , Cory Pruce <corypruce(a)gmail.com> wrote: > > I've been able to do a > make install and am ready to continue setting up the test environment. I > see chutney on your github. I'll get that set up when I get home. Do you > have any advice for testing Tor? Also, feel free to move this to the > mailing list whenever you feel it's appropriate. > Hi Cory, I'm moving this to tor-dev as it's relevant to other developers. Chutney Please use the official chutney repository at git.torproject.org <http://git.torproject.org/> My chutney repository a little messy at the moment, and I've merged draft throughput-testing code into my master branch. You're welcome to test the draft code by merging https://github.com/teor2345/chutney/tree/bug14175-bandwidth <https://github.com/teor2345/chutney/tree/bug14175-bandwidth> The throughput-testing functionality works, but it needs to be tidied up, and have the hard-coded constants turned into command-line options. So it's not ready for release, but it is ready for an early review to check for functionality gaps and bugs. You might find throughput metrics useful to confirm that any multithreading changes are actually improving performance. Testing Once tor is built, you can test it using: # basic tests make test # extended tests make check # benchmarks /src/test/bench # verify tor connectivity using a local test network - requires chutney make test-network # verify that the core functionality of tor works, requires chutney and IPv6 on localhost src/test/test-network.sh --flavour bridges+ipv6+hs # verify that the core functionality of tor works, using chutney, but without IPv6 src/test/test-network.sh --flavour bridges src/test/test-network.sh --flavour hs There's also various other testing tools: shadow Tor network simulator static analysers, such as coverity and clang-scan dynamic sanitizers: Undefined Behaviour (UBSan), Address (ASAN), … fuzzing (I'm working on some tor-specific harnesses for fuzzing, but they're not ready) and I'm sure there are others which I've missed. Generally, I'm happy with code once I know it: * compiles with no warnings, * passes the extended unit tests (make check), including any tests written for new functionality, and * passes all the connectivity tests in a comprehensive test network (bridges+ipv6+hs). For bonus points, you can compile tor using UBSan and ASAN. If you're using clang, you'll find that tor/contrib/clang helps with setting this up. It lists known undefined behaviour in the Tor codebase, so it may be useful if you want to do something similar with gcc. (However, getting sanitizers to work can be incredibly fiddly and a total time-suck, too. So if it's just not working, skip it.) I'll also occasionally run code through a static analyser, to find subtle bugs which haven't been uncovered using UBSan/ASAN. Again, this isn't something everyone needs to do. Others may have advice on testing multithreading code in particular. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0

Damian's Status Report - June 2015
by Damian Johnson 29 Jun '15

29 Jun '15

Guten morgen lovely people of the Internet. This June my grandpa passed away so spent quite a bit of time with family. Tor stuff didn't get much attention, but I did revise a couple small parts of Nyx. -------------------------------------------------------------------------------- Nyx Installer and Descriptor Dialog Rewrite -------------------------------------------------------------------------------- This month I rewrote the installer of Nyx and its descriptor dialog. As usual this was mostly about cleaning and stabilizing the codebase. Only functional changes were... * Our setup.py now supports --man-page and --sample-path arguments for customizing resource locations. * Test coverage for installation. * Installing and our tests are now python3 compatible. Sadly no, this doesn't mean Nyx runs under python3 just yet but it's a step in that direction. * The descriptor dialog now shows microdescriptors (this part of the codebase predated them). Cheers! -Damian

1 0

Re: [tor-dev] tor-dev Digest, Vol 53, Issue 27
by Cory Pruce 29 Jun '15

29 Jun '15

Thanks teor, that'd be awesome! I've been able to resolve most of the dependencies easily until the file "readpassphrase.h" (and thus .o) was shown to be missing during make. Are you still using the git branch? I'll definitely take a look into the throughput tool once I get set up :D - Cory On Mon, Jun 29, 2015 at 5:00 AM, <tor-dev-request(a)lists.torproject.org> wrote: > Send tor-dev mailing list submissions to > tor-dev(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > or, via email, send a message with subject or body 'help' to > tor-dev-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-dev-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-dev digest..." > > > Today's Topics: > > 1. List of projects (Cory Pruce) > 2. Re: List of projects (Nick Mathewson) > 3. Re: List of projects (Cory Pruce) > 4. Re: Multithreaded crypto on Tor (teor) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 28 Jun 2015 11:12:45 -0700 > From: Cory Pruce <corypruce(a)gmail.com> > To: dgoulet(a)torproject.org, nickm(a)torproject.org, > meejah(a)torproject.org, atagar(a)torproject.org, > tor-dev(a)lists.torproject.org > Subject: [tor-dev] List of projects > Message-ID: <5590391D.6020900(a)gmail.com> > Content-Type: text/plain; charset=utf-8 > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hey, > > I see now that the multithreading on the crypto operations is at least > partly resolved (#9682) but there still exists more to be done. I could > help on the condition variables and possibly more with that project or > another one from the project ideas on the Tor volunteer page. For > example, I've worked with the Stem library before doing primarily > traffic analysis in a class at Carnegie Mellon. If no one has worked on > the first option, I could do that as well. Please let me know if any of > you are willing to discuss these with me! I'd like to hear back knowing > that I'm talking to other human beings :-) Sorry if this isn't the way I > should be contacting. If so, let me know! > > - - Cory > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQIcBAEBAgAGBQJVkDkdAAoJEB7DuCIJauCg7q0P/0KNxwoLPo1ZlsO7X5/p+yC5 > qHDHrAuVworNkER/t35xEQPJmGy9hTp7XaxHm2JWwbKpkWtS9dbTVA5LPD5esRsz > z5dhJOwKOXh9BIQ3qjBk22OPg1YbUJ8ykwTiwUY5BM/Tilk6UZqmjZDCOlpp5ufv > F4w9tUL9ug+K6VRnM/XksZhYjx1Wnhei5PesfZoTBiggj4T0q/16amduIhyALilm > HY5hHVCxo9mvmBBwzUwkRhi+kQ39eeLCggRbBqQv+WsYH8FNesoUcxFjy/AGzTGT > 4Ul4M8E41oHudtvmFIqzEgMmV5TjZaSR5X52aW+7mQAXRAH6IzxX8E+ji5CJIWLo > pE2zPV3dX+AsYx1lkU/x0hZvX2537wt8pNWka0ORTn7HKLnb/6NoaC7gYHr8ZftR > gcbSru49xyWNmzjfXSok7Unfih37MQY8Y1nGNqauHo8lZ38qmAnsdaGzAB409RgP > R30G82hg2QRFBA1486IqP/LtSxhk1UdEyWWvVlXWOYRvVF68l3g1mHVswIxT3k4G > z3a+0EmwF52xxvzgmMwTlxeWfa1/3uQA3w2el9e92/Xtc5lw66nE/k+kX7Mpg7GM > kDFZ0UkBgxXATy0kuCdU7enZjzpn6M1vDwhfmovpGAMDVaaMZzzII17KEJyVv8Sp > G7Wxg+lZjr9SOvRIOxf1 > =Ebps > -----END PGP SIGNATURE----- > > > > > ------------------------------ > > Message: 2 > Date: Sun, 28 Jun 2015 17:35:47 -0400 > From: Nick Mathewson <nickm(a)torproject.org> > To: Cory Pruce <corypruce(a)gmail.com> > Cc: Damian Johnson <atagar(a)torproject.org>, meejah(a)torproject.org, > tor-dev(a)lists.torproject.org, David Goulet <dgoulet(a)torproject.org > > > Subject: Re: [tor-dev] List of projects > Message-ID: > <CAKDKvuzxLDGjokxZK26_X=_ > H9-J_wMdOYrOakyGv2cs6kdPSig(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Sun, Jun 28, 2015 at 2:12 PM, Cory Pruce <corypruce(a)gmail.com> wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hey, > > > > I see now that the multithreading on the crypto operations is at least > > partly resolved (#9682) but there still exists more to be done. I could > > help on the condition variables and possibly more with that project or > > another one from the project ideas on the Tor volunteer page. For > > example, I've worked with the Stem library before doing primarily > > traffic analysis in a class at Carnegie Mellon. If no one has worked on > > the first option, I could do that as well. Please let me know if any of > > you are willing to discuss these with me! I'd like to hear back knowing > > that I'm talking to other human beings :-) Sorry if this isn't the way I > > should be contacting. If so, let me know! > > Hi, Cory, and sorry about the delay! I saw your earlier two messages, > and I just thought I'd send you a quick note today to say, "Yup, we > got them!" I'm going to be a little more slow responding than I would > like, since I'm preparing for a trip to PETS > (https://petsymposium.org/2015/) but I'll try to write back some > actual useful info as soon as I can. > > cheers, > -- > Nick > > > ------------------------------ > > Message: 3 > Date: Sun, 28 Jun 2015 14:37:07 -0700 > From: Cory Pruce <corypruce(a)gmail.com> > To: Nick Mathewson <nickm(a)torproject.org> > Cc: atagar(a)torproject.org, meejah(a)torproject.org, David Goulet > <dgoulet(a)torproject.org>, tor-dev(a)lists.torproject.org > Subject: Re: [tor-dev] List of projects > Message-ID: > < > CANOqyr7fzF2ADbmYof+Pufd3DGgFwVNqmLkZzvVSKecz_7QywQ(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Awesome, no worries. Thanks! > On Jun 28, 2015 2:35 PM, "Nick Mathewson" <nickm(a)torproject.org> wrote: > > > On Sun, Jun 28, 2015 at 2:12 PM, Cory Pruce <corypruce(a)gmail.com> wrote: > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Hey, > > > > > > I see now that the multithreading on the crypto operations is at least > > > partly resolved (#9682) but there still exists more to be done. I could > > > help on the condition variables and possibly more with that project or > > > another one from the project ideas on the Tor volunteer page. For > > > example, I've worked with the Stem library before doing primarily > > > traffic analysis in a class at Carnegie Mellon. If no one has worked on > > > the first option, I could do that as well. Please let me know if any of > > > you are willing to discuss these with me! I'd like to hear back knowing > > > that I'm talking to other human beings :-) Sorry if this isn't the way > I > > > should be contacting. If so, let me know! > > > > Hi, Cory, and sorry about the delay! I saw your earlier two messages, > > and I just thought I'd send you a quick note today to say, "Yup, we > > got them!" I'm going to be a little more slow responding than I would > > like, since I'm preparing for a trip to PETS > > (https://petsymposium.org/2015/) but I'll try to write back some > > actual useful info as soon as I can. > > > > cheers, > > -- > > Nick > > >

1 1

Re: [tor-dev] Multithreaded crypto on Tor
by teor 29 Jun '15

29 Jun '15

> Date: Sat, 27 Jun 2015 20:44:02 -0700 > From: Cory Pruce <corypruce(a)gmail.com> > To: tor-dev(a)lists.torproject.org > Subject: [tor-dev] Multithreaded crypto on Tor > Message-ID: <558F6D82.2010400(a)gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi! > > Let me start by introducing myself. My name is Cory Pruce, am an > Information Technology - Information Security Master's student at > Carnegie Mellon, and would like to get more involved in Tor! I have done > a bit of programming in C and have a pretty substantial crypto > background. I'm not in the Google summer of code but would really like > to complete this project :D (see screenshot) Please let me know if > anyone is currently working on this and if Nick, David, or anyone would > like to give me some advice and be someone I can bounce ideas off of :-) > > Thanks and I hope to hear back soon! > > - Cory > > P.S. I have cloned the repo and have been looking through relay.* and > cpuworker.* files. I just would like to speak with someone before I jump > in :p Hi Cory, Multithreaded crypto is a *very* popular request on the tor-relays mailing list, as many relays have multiple cores, and significant network bandwidth. Tor limits the number of relays per IPv4 address to 2 to mitigate sybil attacks, so the best way for relay operators to increase their throughput is multithreaded crypto. I'm not familiar with the specifics of tor's multithreading implementation, but please contact me if you need assistance setting up a local test network. I've made some recent changes to the chutney test tool which allow throughput to be measured. These changes work on Linux and OS X, but they're still under review, and the git branch isn't as organised as I would like. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0