tor-dev

tor-dev@lists.torproject.org

3581 discussions

[GSoC] [Stegotorus] update
by vmonmoonshine＠gmail.com 13 Aug '12

13 Aug '12

Hello Tor-devers, In last two weeks I was busy implementing the protocol by which the st server sends a url dictionary to the client, so they the client can communicate with server using this url code. It was bit tricky because chop needed to be involved to distinguished between the data being serve to the user and the data for the steg module. This is working now. I also made the curl st client to st server communication non-blocking and now curl sharing the socket with libevent (for the reply). The curl communication with apache server (for providing covers) is still blocking. This is not critical as long as the cover webserver and st server are on the same machine, but is a good feature to think about. You can get everything here: https://github.com/zackw/stegotorus/tree/f--payload-servers But you need to have apache installed on the server and run payload_scraper first: https://github.com/vmon/payload_scraper then copy the generated payload list into apcahe_payload/server_list.txt The name of steg protocol is http_apache (instead of http) The next 10 days will be writing unit tests, testing, and writing documentation for http_steg protocol. Cheers, vmon

1 0

Fwd: [tor-relays] tcmalloc in FreeBSD
by Jordi Espasa Clofent 11 Aug '12

11 Aug '12

Hi, I posted this message in tor-relays, but it seems to me (and another people) that dev mail-list is better channel to use. Thanks! -------- Original Message -------- Hi all, From time to time my tor node (minibofh) stopped to work properly; since it's a tiny FreeBSD VPS, the root origin was some CPU over-consumption. I'm taking some actions to fix it (more swap, freeing CPU from another services... etc). The FreeBSD tor port offers to you the tcmalloc compilation option, so I had some fun reading this interesting paper: http://goog-perftools.sourceforge.net/doc/tcmalloc.html I recompiled the tor port but just using the tcmalloc option. Actually, now I got the google-perftool package and, obviously, the tcmalloc library: mb# pkg_info | grep google google-perftools-1.8.3 Fast, multi-threaded malloc() and nifty performance analysi mb# pkg_info -L google-perftools-1.8.3 | grep malloc.so /usr/local/lib/libtcmalloc.so /usr/local/lib/libtcmalloc.so.2 But, when I'm checking which libraries the tor binary is using, I get: mb# ldd /usr/local/bin/tor /usr/local/bin/tor: libz.so.5 => /lib/libz.so.5 (0x281aa000) libm.so.5 => /lib/libm.so.5 (0x281bc000) libevent-2.0.so.6 => /usr/local/lib/event2/libevent-2.0.so.6 (0x2844e000) libssl.so.7 => /usr/local/lib/libssl.so.7 (0x28489000) libcrypto.so.7 => /usr/local/lib/libcrypto.so.7 (0x284d7000) libthr.so.3 => /lib/libthr.so.3 (0x281df000) libc.so.7 => /lib/libc.so.7 (0x28090000) So... I understand that the tor binary is actually NOT using the new tcmalloc library. Am I wrong? PS. I adding a CC to tor FreeBSD port mantainer.

4 19

Another key exchange algorithm for extending circuits: alternative to ntor?
by Nick Mathewson 11 Aug '12

11 Aug '12

Hi, all! Michael Backes, Aniket Kate, and Esfandiar Mohammadi have a paper in submission called, "An Efficient Key-Exchange for Onion Routing". It's meant to be more CPU-efficient than the proposed "ntor" handshake. With permission from Esfandiar, I'm sending a link to the paper here for discussion. http://www.infsec.cs.uni-saarland.de/~mohammadi/owake.html What do people think? -- Nick

3 7

[Stegotorus] Strange comparison in chop_circuit_t::send_targeted(conn, blocksize)
by vmon 10 Aug '12

10 Aug '12

Hey Zack, Please take a look at this comparison in chop_circuit_t::send_targeted(conn, blocksize): if (avail > blocksize - lo) avail = blocksize - lo; else if (avail > SECTION_LEN) avail = SECTION_LEN; else if (upstream_eof && !sent_fin) // this block will carry the last byte of real data to be sent in // this direction; mark it as such op = op_FIN; Assume SECTION_LEN = 65536 suppose avail = 67000 blocksize - lo = 66500 => avail = 66500 avail = 67000 blocksize - lo = 67500 => avail = 65536 it's like that if avail is very big then the it is OK if it's bigger than SECTION_LEN but if it's moderately big then it shouldn't be bigger than SECTION_LEN, which seems very arbitrary. On the other hand if blocksize - lo < SECTION_LEN again it doesn't make sense, because then it never reaches to (avail > SECTION_LEN). So it's like if SECTION_LEN < blocksize - lo the behavior is random and if it's SECTION_LEN > blocksize - lo is useless. Moreover, when blocksize - lo > avail > SECTION_LEN I'm getting assertion error in the other overload of send_targeted. Everything makes sense and the assertion failure goes away if I replace the code with this: if ((avail > blocksize - lo) || (avail > SECTION_LEN)) { avail = min(blocksize - lo, SECTION_LEN); } else if (upstream_eof && !sent_fin) // this block will carry the last byte of real data to be sent in // this direction; mark it as such op = op_FIN; Please tell me what you think and if the second chunk is the correct replacement? Bests, vmon

2 1

Re: [tor-dev] Another key exchange algorithm for extending circuits: alternative to ntor?
by aniket kate 09 Aug '12

09 Aug '12

> Date: Thu, 9 Aug 2012 00:22:59 +0000 > From: Robert Ransom <rransom.8774(a)gmail.com> > > On 8/8/12, Nick Mathewson <nickm(a)freehaven.net> wrote: > >> Michael Backes, Aniket Kate, and Esfandiar Mohammadi have a paper in >> submission called, "An Efficient Key-Exchange for Onion Routing". >> It's meant to be more CPU-efficient than the proposed "ntor" >> handshake. With permission from Esfandiar, I'm sending a link to the >> paper here for discussion. >> >> http://www.infsec.cs.uni-saarland.de/~mohammadi/owake.html >> >> What do people think? > > > * If you finish my implementation of the Ed25519 group operations > (which you would need in order to implement this protocol), you can > use them to implement a signature-based protocol (specified as > A-DHKE-1 in http://eprint.iacr.org/1999/012), which requires only one > precomputed and one on-line exponentiation per protocol run on the > server when implemented with a slightly modified version of Ed25519. > (The client's performance is much less important than the server's.) I went through A-DHKE-1 description (Page 36 of Eprint 1999/012). I find that A-DHKE-1 also requires one online signature generation on the server side along with one online exponentiation. Therefore, A-DHKE-1 is computationally more expensive than the discussed protocol and probably even the ntor protocol based on the employed signature scheme. -Aniket

2 1

How about virtual machines?
by Admin 09 Aug '12

09 Aug '12

Hello Developers, My testing shows that you can setup encrypted virtual machines in a country with easy access to broadband, and have someone from a country where good computer hardware is hard to find, the Internet got cut off to a point where only dial up is available, and manage to give these people access to broadband and high range hardware. In order to do this, you need to setup a remote desktop virtualization, where the user is able to use all of the resources of a virtual machine, while only using it's current device for rendering the screen of the vm and as keyboard, mouse or touch input. This virtual machine could reset it's state once the user logs off, leaving no trace of what he did while he was on it. Considering the only connection the user is actually making is to the vm location, there is way an oppressive government can figure out which sites are currently being visited or what the user is doing, unless it is already inside taking screenshots and keylogging. There is also the possibility of making cheap dial up enabled USB dongles, which are specialized in screen rendering by PCoIP and can be connected to any device, such as a smart tvs and tablets. Testing shows you can make Android virtual machines for those connecting through a touch enabled device, and keep the device's touch functions. Let me know what you think. Cheers

1 0

Is it possible to run private Exit nodes?
by SiNA Rabbani 08 Aug '12

08 Aug '12

I have been running private bridges for my VIP contacts for a long time. I use PublishServerDescriptor 0 to keep my bridges private. Is it possible to also run a private Exit node? What would happen, if I hard coded an exit into my torrc that is not published (if possible at all)? All the best, SiNA -- “If I had eight hours to chop down a tree, I’d spend the first six of them sharpening my axe.” -Abraham Lincoln

3 2

Next Tor release timeframes?
by Roger Dingledine 08 Aug '12

08 Aug '12

1) Do we have any requirements to release an 0.2.4.1-alpha at any particular date? I haven't been following e.g. the latest SponsorG timelines. 2) Nick was enthusiastic about an 0.2.2.38 with the latest fix. Nick, do you still think that's important? My sense is that it's a totally esoteric theoretical attack where there's no rush to release. 3) For the next 0.2.3 rc, we might want to merge at least: https://trac.torproject.org/projects/tor/ticket/6252 https://trac.torproject.org/projects/tor/ticket/6404 --Roger

3 2

[patch] fix vidalia compilation in gcc 4.7
by Jason A. Donenfeld 08 Aug '12

08 Aug '12

Fixed in a gentoo bug report: https://422645.bugs.gentoo.org/attachment.cgi?id=320722

2 1

http_apache_steg_t is working now
by vmonmoonshine＠gmail.com 08 Aug '12

08 Aug '12

Hey Zack, I have pushed the working version of http_apache_steg_t. On server side it asks apache for the load, on the client side it uses the url dictionary and parameter values. http_apache_steg_t is inherited from http_steg_t. But because of all those macro hackish tricks (which expect you to inherit only from steg_t), it feels bit odd (when c++ natively support polymorphism maybe we don't need these macros). So you can test it writing http_apache instead of http in the command line. (but you need apache installed on server side and you need to run payload_scraper first) Downstream client to server is only curl now and hence probably more robust while passing proxies. It's blocking though. I'll make non-blocking in near future. I'm going to implement the protocol for passing the dictionary from the server to client in following few days and spends next week testing, writing tests and applying your comments on github (including spelling and grammatical mistakes :p ) Cheers, vmon P.S. I'm slowly re-styling stuff in the steg directory to c++ style, meanwhile it might look even uglier and messier, but it'll be pretier at end.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev