tor-dev May 2011

tor-dev@lists.torproject.org

30 participants
21 discussions

New paper by Goldberg, Stebila, and Ostaoglu with proposed circuit handshake
by Nick Mathewson 16 Jan '12

16 Jan '12

Crypto people who have been following threads about the circuit-establishment handshake will be interested in the new paper, "Anonymity and one-way authentication in key-exchange protocols", by Goldberg, Stebila, and Ostaoglu. Here's the version they updated today: http://www.cacr.math.uwaterloo.ca/techreports/2011/cacr2011-11.pdf If we're moving to an improved handshake, this might be a good candidate to consider. The protocol itself is on page 14. Some notes, written by a guy who knows less crypto than everybody involved: * It's a pure Diffie-Hellman based system, which would lend itself nicely to use with ECC. * It seems to require the same number of exponentiations as our current system, but Ian Goldberg notes that if you want to compute X^a and X^b at the same time you can do so more efficiently by taking into account the shared base. * The security proof requires that the Gap DH assumption holds over the group -- basically, that computing the Decisional DH problem is easy, but computing the Computational DH problem is hard. This assumption isn't true of most basic ECC groups -- I think it means you need to use a pairing-based system instead for the proof to hold. I'd bet that the authors aren't seriously suggesting that we use pairing-based crypto, but I'm wondering how much they were able to prove in a groups where DDH is hard. * I haven't read over the security model closely yet; folks should review it for reasonableness. * I'm hoping to write this up as a proposed spec soon, unless Ian or somebody wants to give it a shot. yrs, -- Nick

8 29

Re: [tor-dev] Proposal 178: Require majority of authorities to vote for consensus parameters
by Nick Mathewson 27 Nov '11

27 Nov '11

On Tue, Feb 22, 2011 at 1:34 AM, Sebastian Hahn <hahn.seb(a)web.de> wrote: > Design: > > When the consensus is generated, the directory authorities ensure that > a param is only included in the list of params if at least half of the > total number of authorities votes for that param. The value chosen is > the low-median of all the votes. We don't mandate that the authorities > have to vote on exactly the same value for it to be included because > some consensus parameters could be the result of active measurements > that individual authorities make. This is possibly bikeshed, but I would suggest that instead of requiring half of existing authorities to vote on a particular parameter, we require 3 or more to vote on it. (As a degenerate case, fall back to "at least half" if there are fewer than 6 authorities in the clique.) I think we don't want the number to be _less_ than 3, since 3 is the smallest number of parties who can come up with a low-median that isn't just the diktat of a single member (1 party), or as low as either member wants it to be (2 parties). yrs, -- Nick

2 7

The Torouter project - where are we now?
by Runa A. Sandvik 24 Sep '11

24 Sep '11

Hi everyone, I am trying to figure out how we can move the Torouter project forward. In this email, I will try to summarize the current status of this project. The Torouter project has a total of four bugs in Trac. These are #2334, #2376, #2370 and #2596. #2334: Torouter on Buffalo breaks with large cached-descriptors[.new] files. The quick and easy solution here is to attach a USB stick to the router and use it as Tor's data directory. However, it would be great if someone could take a look at this and figure out a way to solve it. #2376: Torouter on OpenWrt shouldn't have its data directory in /tmp/. The problem with having Tor's data directory in /tmp is that whenever Torouter is rebooted, Tor generates new keys and gets a new fingerprint. There are a couple of different ways to solve this problem; Karsten suggested that we could modify OpenWrt to stop creating a /tmp partition. This probably means that we will have to ship our own OpenWrt image. I'm thinking that another option would be to modify the Tor-OpenWrt-package to use / as the data directory instead of /tmp. However, I wonder if 64M (no matter how it's partitioned) of space on the Buffalo router is insufficient as long as #2334 remains open. #2370: Torouter basic Web UI for OpenWrt. I haven't tried the web interface myself, but development seems to be moving along nicely. I'm not sure what the remaining steps are, other than packaging it as tor-ui (or similar) for OpenWrt. #2596: Figure out a better name than "torouter". Andrew thinks we should come up with a better name for this project, one that does not have "Tor" in the name. Suggestions? The Torouter project also has some open questions (some are mentioned on https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/Torouter as well): 1. How can we make sure that the version of Tor in OpenWrt is always up to date? Should we set up our own OpenWrt repository? Right now, the version of Tor in OpenWrt is 0.2.1.26. Also, should we offer packages for both stable and unstable? 2. We want to collect statistics, which means that we need to ship a GeoIP file as well. I'm thinking we should create a tor-geoipdb package for OpenWrt. Thoughts? 3. Do we want one Tor process for bridging and one for the transparent wifi network? I think this sounds good, if the router can handle it. If not, then just running a bridge is ok too. Have I missed anything important? Are there any other packages that we should include in OpenWrt? Other comments or suggestions? If you have more information or would like to help out, please let me know. Thanks, -- Runa A. Sandvik

8 16

The Torouter and the DreamPlug
by Runa A. Sandvik 11 Jun '11

11 Jun '11

Hi everyone, DreamPlug is a new plug computer from GlobalScale Technologies: http://www.globalscaletechnologies.com/c-5-dreamplugs.aspx. The spec looks good, it runs Ubuntu by default and it doesn't cost too much. I thought that the DreamPlug was going to be very user friendly and a potential candidate for the Torouter project. (Maybe) I was wrong. When the SheevaPlug came out a couple of years ago, it shipped with a web interface that enabled users to change various network options. I thought the DreamPlug would ship with some kind of interface as well (and my plan was to just plug in a Tor page). This is not the case; it ships with lighthttpd by default and displays a static and very simple placeholder page on 192.168.1.1. If we want to use the DreamPlug for the Torouter, we will have to write a web interface for easy configuration of Tor. The interface should probably also provide options to better secure the DreamPlug. Downloading and installing Tor isn't a problem, but the configuration side of things can be tricky for users who aren't used to the command line. Thoughts? Comments? Thanks, -- Runa A. Sandvik

14 44

[Patch] common/procmon.c
by Gisle Vanem 02 Jun '11

02 Jun '11

Hi list! I've been staring at this file for some time trying to find the elusive compile-error (MingW-gcc v4.50) on Win_XP). The bug was a missing comma (!) and a typo ('err_msg' at line 277 changed to 'err_msg'). I've also changed the format for 'err_code' at line 293 into a "%ld" to suppress a warning. How did this go unnoticed for ~1 month? --- Git-latest\src\common\procmon.c Thu May 26 19:30:24 2011 +++ common/procmon.c Tue May 31 22:54:14 2011 @@ -252,7 +252,7 @@ if (!GetExitCodeProcess(procmon->hproc, &exit_code)) { char *errmsg = format_win32_error(GetLastError()); log_warn(procmon->log_domain, "Error \"%s\" occurred while polling " - "handle for monitored process %d; assuming it's dead." + "handle for monitored process %d; assuming it's dead.", errmsg, procmon->pid); tor_free(errmsg); its_dead_jim = 1; @@ -287,12 +287,12 @@ if (!its_dead_jim) log_info(procmon->log_domain, "Failed to open handle to monitored " - "process %d, and error code %d (%s) is not 'invalid " + "process %d, and error code %lu (%s) is not 'invalid " "parameter' -- assuming the process is still alive.", procmon->pid, - err_code, err_msg); + err_code, errmsg); - tor_free(err_msg); + tor_free(errmsg); } } #else ------------- Sorry, no git patch. I'm a git newbie. Gisle V.

2 1

[PATCH] Signed-off-by: Gisle <gvanem@broadpark.no>
by Gisle 01 Jun '11

01 Jun '11

An elusive compile-error (MingW-gcc v4.50 on Win_XP); a missing comma (!) and a typo ('err_msg' at line 277 changed to 'errmsg'). Aso changed the format for 'err_code' at line 293 into a "%ld" to suppress a warning. How did this go unnoticed for ~1 month? Btw. This is my 1st ever 'git commit', so it better work. --- src/common/procmon.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/common/procmon.c b/src/common/procmon.c index 8fcc1af..5c10e9a 100644 --- a/src/common/procmon.c +++ b/src/common/procmon.c @@ -252,7 +252,7 @@ tor_process_monitor_poll_cb(evutil_socket_t unused1, short unused2, if (!GetExitCodeProcess(procmon->hproc, &exit_code)) { char *errmsg = format_win32_error(GetLastError()); log_warn(procmon->log_domain, "Error \"%s\" occurred while polling " - "handle for monitored process %d; assuming it's dead." + "handle for monitored process %d; assuming it's dead.", errmsg, procmon->pid); tor_free(errmsg); its_dead_jim = 1; @@ -287,12 +287,12 @@ tor_process_monitor_poll_cb(evutil_socket_t unused1, short unused2, if (!its_dead_jim) log_info(procmon->log_domain, "Failed to open handle to monitored " - "process %d, and error code %d (%s) is not 'invalid " + "process %d, and error code %lu (%s) is not 'invalid " "parameter' -- assuming the process is still alive.", procmon->pid, - err_code, err_msg); + err_code, errmsg); - tor_free(err_msg); + tor_free(errmsg); } } #else -- 1.7.0.2.msysgit.0

2 1

Code Review (arm) - Initial commit for the menu code
by Damian Johnson 28 May '11

28 May '11

Hi all. Kamran and I are gonna doing code reviews publicly so if you're interested and spot issues we miss then feel free to chime in. -Damian Change: https://gitweb.torproject.org/user/krkhan/arm.git/commitdiff/5fd9b5f74a86eb… > ARM_CONTROLLER = Controller(stdscr, stickyPanels, pagePanels, menu) What sort of persistent state will the menu require? If we can make it a popup function (like "showHelpPopup()") that would be preferable (less parameter juggling). But if you expect it to remember something between menu requests then this makes sense. > menu.draw() Maybe rename this to "showMenu()"? The draw method is part of panel which threw me off a bit. > self._rootEntry = (entry and isinstance(entry, ParentEntry)) and entry or DEFAULT_ROOT Interesting pattern, but it's kinda hard to read (or make sense of unless you've seen it before). Maybe something a little less compact would be clearer? if entry and isinstance(entry, ParentEntry): self._rootEntry = entry else: self._rootEntry = DEFAULT_ROOT > titles = map(attrgetter('title'), self._rootEntry.children) This took me a couple minutes with the interactive interpretor to make sense of too. Maybe list comprehension instead of the attrgetter would help? titles = [menuItem.title for menuItem in self._rootEntry.children] > titlewidth = max(map(lambda title: len(title), titles)) + 2 Neat. Honestly I'm greener than I should be with lamdas. The pattern I'd use for this is... titlewidth = max([len(entry) for entry in titles]) + 2 but up to you. The later is more familiar to me but I'm not sure which can claim the best readability. > # total number of titles that can be printed in current width Why are you giving all titles equal distance? Does this make it look better? I'd assume that would be best to have dynamic widths, leaving some entries unprinted if we run out of room (this is done all around so I can get you an example if you'd like). I'm thrilled you're taking variable screen sizes into account! > titleformat = curses.A_NORMAL > > if index == self._selection[0]: > titleformat = curses.A_STANDOUT Alternative option... titleformat = curses.A_STANDOUT if index == self._selection[0] else curses.A_NORMAL > popup.win.addch(top, left, curses.ACS_VLINE) > popup.win.addstr(top, left, entry.title.center(titlewidth), titleformat) > popup.win.addch(top, left, curses.ACS_VLINE) Noooooooo! Don't do this! If you can help it _never_ draw to the raw curses window. If this ever attempts to draw outside the curses window it will crash. The panel class has safe proxies for everything that you should need. In this case... popup.addch(top, left, curses.ACS_VLINE) popup.addstr(top, left, entry.title.center(titlewidth), titleformat) popup.addch(top, left, curses.ACS_VLINE) will do the same. There's, of course, exceptions like popup.win.box() and popup.win.refresh() (those are safe). > DEFAULT_ROOT = ParentEntry(title="Root", children=( I've been defining constants outside of classes so they can be easier to spot at the top of files. However, this is just a stylistic preference of mine - if you prefer constants to be a class attribute then that's fine. > for index in self._selection: > if isinstance(entry, ParentEntry): > entry = entry.children[index] > else: > break > > if isinstance(entry, LeafEntry): > entry.callback(entry) It looks like if self._selection is an invalid path you do nothing? Maybe we should log something or raise an exception... Your usage of named tuples and index lists will, I think, make this harder and more confusing than it needs to be. Instead I'd suggest a MenuItem class that has... getLabel() -> text for the option isLeaf() -> boolean for if we're a leaf or not getSubmenu() -> returns a list of MenuItems below it - either an empty list or None if a leaf node (whatever makes most sense to you) getParent() -> parent MenuItem next(), prev() -> returns a MenuItem instance for the next or previous option for the menu list we're in select() -> event handler Constructing the menu will be a little more interesting, but rendering it, navigation, and selection will all become trivial. It'll also avoid the situation where _selection is out of sync with _rootEntry (for that matter, we wouldn't need a rootEntry...).

2 2

was my LDAP account ever setup?
by Nathan Freitas 25 May '11

25 May '11

Seems like this ticket is still open: https://trac.torproject.org/projects/tor/ticket/3068 and I am problems like this: git remote add public ssh://git-rw.torproject.org/n8fr8/orbot git push public master Permission denied (publickey). fatal: The remote end hung up unexpectedly thx!

1 0

Re: [tor-dev] arm - new identity ...
by Damian Johnson 23 May '11

23 May '11

Hi Dominik. Sounds good, we should keep this simple (at least for the first version) so lets go with #2 and #3. Developing this should be pretty straight forward... 1. Add "sendNewnym", "isNewnymAvailable", and "getNewnymWait" methods to 'src/util/torTools.py'. All of these should be very easy. 2. Add a handler for sending a newnym in 'src/cli/headerPanel.py'. This is done by overwriting the "handleKey(self, key)" method - for an example see just about any of the other panels. I'm currently working on another feature for the header panel (reattaching to tor instances) so there might be a handler here by the time you start. I'm fine with F5. From the curses documentation it sounds like you can compare the keycode to the curses.KEY_F5 constant. 3. Adding the newnym to the header panel - this will be the hardest part (but still not too difficult). This will only be visible when we're a non-relay, and involves filling in... https://gitweb.torproject.org/arm.git/blob/HEAD:/src/cli/headerPanel.py#l259 Normally this could say something like "Press F5 for a new identity", then after they send a newnym instead display "Building circuits (newnym signal unavailable for X seconds)". 4. Coordinate with Kamran for the menu option. Maybe we want to somehow make it disabled while sending a newnym is unavailable? > - mumble with krkhan (and you?) I'm looking forward to it. We should be able to set this up next week. Cheers! -Damian On Mon, May 23, 2011 at 7:04 AM, dominik <d.schuetzdeller(a)gmx.de> wrote: > hello atagar, > im sorry for not sending this email yesterday. my vserver hoster has reset > the wrong vserver and caused some trouble =( > ... anyway > > i had 3 ideas realizing this: > 1. build a new "page" > that page should contain possibilities for adding nodes to use (entry or > bridges, relay and exit). it should also contain > some informations about flags from that nodes; especially if that node is > a known bad node. there should also be a > new identity button. > 2. implement it within the menues krkhan is working on > as i now heard krkhan is working on a menu, what would be the best and > user friendliest way for implementing the > stuff in there and create some masks for the according informations to be > put in there. > 3. using a hotkey for some things like "new identity" > first of all i thought about using the "f5"-button as a hotkey for using > new circuits. i like the idea of using the same hotkey > as it is used in the browser. > that new identity thing how ever needs to have a check whether the node > where it runs on is a client or some other thing. > > ok... before you are going to ask how i am going further - this is what my > todo list says: > - delete torsh from monitoring programs in the thesis > - describe whether there is a magical setup for nagios for ~6 different > nodes or not ... > - describe and edit features for arm > - search an elegant way for recreating a new circuit in pytorctl > - mumble with krkhan (and you?) > - based on the things said i am going to begin implementations (from > saturday on fulltime) > > after all my decision of working on arm after my thesis still is the same... > even if python3 has a weird utf8 handling. > i will also work on torsh as a fun project > > best regards > dominik > > > > > > >

1 0

Re: [tor-dev] [tor-commits] [tor/maint-0.2.2] The first argument for a libevent callback should be evutil_socket_t
by Robert Ransom 23 May '11

23 May '11

On Mon, 23 May 2011 05:18:07 +0000 (UTC) nickm(a)torproject.org wrote: > commit 1e69c60dccc358a7146c2b5e7825ea729498b41b > Author: Nick Mathewson <nickm(a)torproject.org> > Date: Mon May 23 01:12:00 2011 -0400 > > The first argument for a libevent callback should be evutil_socket_t > --- > src/common/procmon.c | 5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/src/common/procmon.c b/src/common/procmon.c > index cee956a..bd25bc1 100644 > --- a/src/common/procmon.c > +++ b/src/common/procmon.c > @@ -34,7 +34,7 @@ typedef int pid_t; > /* Currently we need to poll in some way on all systems. */ > > #ifdef PROCMON_POLLS > -static void tor_process_monitor_poll_cb(int unused1, short unused2, > +static void tor_process_monitor_poll_cb(evutil_socket_t unused1, short unused2, > void *procmon_); This will break the build on libevent 1.x systems (until you merge your bug3270 branch that #defines evutil_socket_t on such systems). Robert Ransom

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev May 2011