tor-commits August 2012

tor-commits@lists.torproject.org

19 participants
901 discussions

[tor/master] Remove tor_malloc_roundup().
by nickm＠torproject.org 13 Aug '12

13 Aug '12

commit f45cde05f934ee95e0002ff7d72f7006ce156a4c Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Aug 13 13:27:32 2012 -0400 Remove tor_malloc_roundup(). This function never actually did us any good, and it added a little complexity. See the changes file for more info. --- configure.in | 31 +++++++++++-------------------- src/common/memarea.c | 2 +- src/common/mempool.c | 12 +----------- src/common/util.c | 31 ------------------------------- src/common/util.h | 1 - src/or/buffers.c | 4 +--- 6 files changed, 14 insertions(+), 67 deletions(-) diff --git a/configure.in b/configure.in index c107148..02041c5 100644 --- a/configure.in +++ b/configure.in @@ -317,18 +317,6 @@ AC_CHECK_FUNCS( vasprintf \ ) -using_custom_malloc=no -if test x$enable_openbsd_malloc = xyes ; then - AC_DEFINE(HAVE_MALLOC_GOOD_SIZE, 1, [Defined if we have the malloc_good_size function]) - using_custom_malloc=yes -fi -if test x$tcmalloc = xyes ; then - using_custom_malloc=yes -fi -if test $using_custom_malloc = no ; then - AC_CHECK_FUNCS(mallinfo malloc_good_size malloc_usable_size) -fi - if test "$enable_threads" = "yes"; then AC_CHECK_HEADERS(pthread.h) AC_CHECK_FUNCS(pthread_create) @@ -703,14 +691,6 @@ AC_CHECK_HEADERS( AC_CHECK_HEADERS(sys/param.h) -TOR_CHECK_PROTOTYPE(malloc_good_size, HAVE_MALLOC_GOOD_SIZE_PROTOTYPE, -[#ifdef HAVE_MALLOC_H -#include <malloc.h> -#endif -#ifdef HAVE_MALLOC_MALLOC_H -#include <malloc/malloc.h> -#endif]) - AC_CHECK_HEADERS(net/if.h, net_if_found=1, net_if_found=0, [#ifdef HAVE_SYS_TYPES_H #include <sys/types.h> @@ -1032,6 +1012,17 @@ if test x$tcmalloc = xyes ; then LDFLAGS="-ltcmalloc $LDFLAGS" fi +using_custom_malloc=no +if test x$enable_openbsd_malloc = xyes ; then + using_custom_malloc=yes +fi +if test x$tcmalloc = xyes ; then + using_custom_malloc=yes +fi +if test $using_custom_malloc = no ; then + AC_CHECK_FUNCS(mallinfo) +fi + # By default, we're going to assume we don't have mlockall() # bionic and other platforms have various broken mlockall subsystems. # Some systems don't have a working mlockall, some aren't linkable, diff --git a/src/common/memarea.c b/src/common/memarea.c index 07bd593..e87c0fb 100644 --- a/src/common/memarea.c +++ b/src/common/memarea.c @@ -118,7 +118,7 @@ alloc_chunk(size_t sz, int freelist_ok) size_t chunk_size = freelist_ok ? CHUNK_SIZE : sz; memarea_chunk_t *res; chunk_size += SENTINEL_LEN; - res = tor_malloc_roundup(&chunk_size); + res = tor_malloc(chunk_size); res->next_chunk = NULL; res->mem_size = chunk_size - CHUNK_HEADER_SIZE - SENTINEL_LEN; res->next_mem = res->u.mem; diff --git a/src/common/mempool.c b/src/common/mempool.c index 2416bce..b255386 100644 --- a/src/common/mempool.c +++ b/src/common/mempool.c @@ -70,7 +70,6 @@ #define ASSERT(x) tor_assert(x) #undef ALLOC_CAN_RETURN_NULL #define TOR -//#define ALLOC_ROUNDUP(p) tor_malloc_roundup(p) /* End Tor dependencies */ #else /* If you're not building this as part of Tor, you'll want to define the @@ -165,25 +164,16 @@ static mp_chunk_t * mp_chunk_new(mp_pool_t *pool) { size_t sz = pool->new_chunk_capacity * pool->item_alloc_size; -#ifdef ALLOC_ROUNDUP - size_t alloc_size = CHUNK_OVERHEAD + sz; - mp_chunk_t *chunk = ALLOC_ROUNDUP(&alloc_size); -#else mp_chunk_t *chunk = ALLOC(CHUNK_OVERHEAD + sz); -#endif + #ifdef MEMPOOL_STATS ++pool->total_chunks_allocated; #endif CHECK_ALLOC(chunk); memset(chunk, 0, sizeof(mp_chunk_t)); /* Doesn't clear the whole thing. */ chunk->magic = MP_CHUNK_MAGIC; -#ifdef ALLOC_ROUNDUP - chunk->mem_size = alloc_size - CHUNK_OVERHEAD; - chunk->capacity = chunk->mem_size / pool->item_alloc_size; -#else chunk->capacity = pool->new_chunk_capacity; chunk->mem_size = sz; -#endif chunk->next_mem = chunk->mem; chunk->pool = pool; return chunk; diff --git a/src/common/util.c b/src/common/util.c index 492ea32..ce67252 100644 --- a/src/common/util.c +++ b/src/common/util.c @@ -290,37 +290,6 @@ _tor_free(void *mem) tor_free(mem); } -#if defined(HAVE_MALLOC_GOOD_SIZE) && !defined(HAVE_MALLOC_GOOD_SIZE_PROTOTYPE) -/* Some version of Mac OSX have malloc_good_size in their libc, but not - * actually defined in malloc/malloc.h. We detect this and work around it by - * prototyping. - */ -extern size_t malloc_good_size(size_t size); -#endif - -/** Allocate and return a chunk of memory of size at least *<b>size</b>, using - * the same resources we would use to malloc *<b>sizep</b>. Set *<b>sizep</b> - * to the number of usable bytes in the chunk of memory. */ -void * -_tor_malloc_roundup(size_t *sizep DMALLOC_PARAMS) -{ -#ifdef HAVE_MALLOC_GOOD_SIZE - tor_assert(*sizep < SIZE_T_CEILING); - *sizep = malloc_good_size(*sizep); - return _tor_malloc(*sizep DMALLOC_FN_ARGS); -#elif 0 && defined(HAVE_MALLOC_USABLE_SIZE) && !defined(USE_DMALLOC) - /* Never use malloc_usable_size(); it makes valgrind really unhappy, - * and doesn't win much in terms of usable space where it exists. */ - void *result; - tor_assert(*sizep < SIZE_T_CEILING); - result = _tor_malloc(*sizep DMALLOC_FN_ARGS); - *sizep = malloc_usable_size(result); - return result; -#else - return _tor_malloc(*sizep DMALLOC_FN_ARGS); -#endif -} - /** Call the platform malloc info function, and dump the results to the log at * level <b>severity</b>. If no such function exists, do nothing. */ void diff --git a/src/common/util.h b/src/common/util.h index 4ab9316..c059730 100644 --- a/src/common/util.h +++ b/src/common/util.h @@ -76,7 +76,6 @@ /* Memory management */ void *_tor_malloc(size_t size DMALLOC_PARAMS) ATTR_MALLOC; void *_tor_malloc_zero(size_t size DMALLOC_PARAMS) ATTR_MALLOC; -void *_tor_malloc_roundup(size_t *size DMALLOC_PARAMS) ATTR_MALLOC; void *_tor_calloc(size_t nmemb, size_t size DMALLOC_PARAMS) ATTR_MALLOC; void *_tor_realloc(void *ptr, size_t size DMALLOC_PARAMS); char *_tor_strdup(const char *s DMALLOC_PARAMS) ATTR_MALLOC ATTR_NONNULL((1)); diff --git a/src/or/buffers.c b/src/or/buffers.c index 9acc229..a8d06ce 100644 --- a/src/or/buffers.c +++ b/src/or/buffers.c @@ -192,8 +192,6 @@ chunk_new_with_alloc_size(size_t alloc) freelist->lowest_length = freelist->cur_length; ++freelist->n_hit; } else { - /* XXXX take advantage of tor_malloc_roundup, once we know how that - * affects freelists. */ if (freelist) ++freelist->n_alloc; else @@ -216,7 +214,7 @@ static INLINE chunk_t * chunk_new_with_alloc_size(size_t alloc) { chunk_t *ch; - ch = tor_malloc_roundup(&alloc); + ch = tor_malloc(alloc); ch->next = NULL; ch->datalen = 0; ch->memlen = CHUNK_SIZE_WITH_ALLOC(alloc);

1 0

[metrics-web/master] Cut off enough days from direct/bridge user graphs.
by karsten＠torproject.org 13 Aug '12

13 Aug '12

commit 4d68e1420c2615b94e51f2405ba663da3d051312 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Mon Aug 13 12:05:28 2012 +0200 Cut off enough days from direct/bridge user graphs. Fixes #6593. --- rserve/csv.R | 4 ++-- rserve/graphs.R | 4 ++-- rserve/tables.R | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/rserve/csv.R b/rserve/csv.R index eec76d9..44c6495 100644 --- a/rserve/csv.R +++ b/rserve/csv.R @@ -153,7 +153,7 @@ export_direct_users <- function(path) { drv <- dbDriver("PostgreSQL") con <- dbConnect(drv, user = dbuser, password = dbpassword, dbname = db) q <- paste("SELECT date, country, r, bwp, brn, bwn, brp, bwr, brr", - "FROM user_stats WHERE date < current_date - 1", + "FROM user_stats WHERE date < current_date - 3", "ORDER BY date, country") rs <- dbSendQuery(con, q) u <- fetch(rs, n = -1) @@ -171,7 +171,7 @@ export_bridge_users <- function(path) { drv <- dbDriver("PostgreSQL") con <- dbConnect(drv, user = dbuser, password = dbpassword, dbname = db) q <- paste("SELECT date, country, users AS bridgeusers", - "FROM bridge_stats WHERE date < current_date - 1", + "FROM bridge_stats WHERE date < current_date - 3", "ORDER BY date, country") rs <- dbSendQuery(con, q) bridgeusers <- fetch(rs, n = -1) diff --git a/rserve/graphs.R b/rserve/graphs.R index 87917aa..4f444b3 100644 --- a/rserve/graphs.R +++ b/rserve/graphs.R @@ -671,7 +671,7 @@ plot_direct_users <- function(start, end, country, events, path, nocutoff, q <- paste("SELECT date, r, bwp, brn, bwn, brp, bwr, brr, country ", "FROM user_stats WHERE date >= '", start, "' AND date <= '", end, "' ", ifelse(nocutoff == "off", - " AND date < current_date - 1 ", ""), + " AND date < current_date - 3 ", ""), " AND (country = 'zy'", ifelse(country == "all", "", paste(" OR country = '", country, "'", sep = "")), ")", sep = "") rs <- dbSendQuery(con, q) @@ -747,7 +747,7 @@ plot_bridge_users <- function(start, end, country, path, dpi) { con <- dbConnect(drv, user = dbuser, password = dbpassword, dbname = db) q <- paste("SELECT date, users FROM bridge_stats ", "WHERE date >= '", start, "' AND date <= '", end, "' ", - "AND date < current_date - 1", + "AND date < current_date - 3", " AND country = '", ifelse(country == "all", "zy", country), "'", sep = "") rs <- dbSendQuery(con, q) diff --git a/rserve/tables.R b/rserve/tables.R index cb74379..8817112 100644 --- a/rserve/tables.R +++ b/rserve/tables.R @@ -7,7 +7,7 @@ write_direct_users <- function(start, end, path) { con <- dbConnect(drv, user = dbuser, password = dbpassword, dbname = db) q <- paste("SELECT date, country, r, bwp, brn, bwn, brp, bwr, brr ", "FROM user_stats WHERE date >= '", start, "' AND date <= '", end, - "' AND date < current_date - 1 ORDER BY date, country", sep = "") + "' AND date < current_date - 3 ORDER BY date, country", sep = "") rs <- dbSendQuery(con, q) u <- fetch(rs, n = -1) dbDisconnect(con)

1 0

[research-web/master] Reformat links in the navigation bar.
by karsten＠torproject.org 13 Aug '12

13 Aug '12

commit 2c43c769929e3ac407827093b8d5ee6dc5d7d278 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Mon Aug 13 09:33:15 2012 +0200 Reformat links in the navigation bar. --- groups.html | 8 ++++---- ideas.html | 8 ++++---- index.html | 8 ++++---- techreports.html | 8 ++++---- 4 files changed, 16 insertions(+), 16 deletions(-) diff --git a/groups.html b/groups.html index 165d267..a923d6d 100644 --- a/groups.html +++ b/groups.html @@ -14,10 +14,10 @@ <img src="/images/top-left.png" alt="Click to go to home page" width="193" height="79"></a></td> <td class="banner-middle"> - <a href="index.html">Home</a><br> - Groups<br> - <a href="ideas.html">Ideas</a><br> - <a href="techreports.html">Tech Reports</a><br> + <a href="index.html">Home</a> + Groups + <a href="ideas.html">Ideas</a> + <a href="techreports.html">Tech Reports</a> </td> <td class="banner-right"></td> </tr> diff --git a/ideas.html b/ideas.html index fd5fbe6..904ddaa 100644 --- a/ideas.html +++ b/ideas.html @@ -14,10 +14,10 @@ <img src="/images/top-left.png" alt="Click to go to home page" width="193" height="79"></a></td> <td class="banner-middle"> - <a href="index.html">Home</a><br> - <a href="groups.html">Groups</a><br> - Ideas<br> - <a href="techreports.html">Tech Reports</a><br> + <a href="index.html">Home</a> + <a href="groups.html">Groups</a> + Ideas + <a href="techreports.html">Tech Reports</a> </td> <td class="banner-right"></td> </tr> diff --git a/index.html b/index.html index cc48583..4f77d2a 100644 --- a/index.html +++ b/index.html @@ -14,10 +14,10 @@ <img src="/images/top-left.png" alt="Click to go to home page" width="193" height="79"></a></td> <td class="banner-middle"> - Home<br> - <a href="groups.html">Groups</a><br> - <a href="ideas.html">Ideas</a><br> - <a href="techreports.html">Tech Reports</a><br> + Home + <a href="groups.html">Groups</a> + <a href="ideas.html">Ideas</a> + <a href="techreports.html">Tech Reports</a> </td> <td class="banner-right"></td> </tr> diff --git a/techreports.html b/techreports.html index 5eadafc..c104a00 100644 --- a/techreports.html +++ b/techreports.html @@ -14,10 +14,10 @@ <img src="/images/top-left.png" alt="Click to go to home page" width="193" height="79"></a></td> <td class="banner-middle"> - <a href="index.html">Home</a><br> - <a href="groups.html">Groups</a><br> - <a href="ideas.html">Ideas</a><br> - Tech Reports<br> + <a href="index.html">Home</a> + <a href="groups.html">Groups</a> + <a href="ideas.html">Ideas</a> + Tech Reports </td> <td class="banner-right"></td> </tr>

1 0

[research-web/master] move the pets and anonbib references to the frontpage
by arma＠torproject.org 13 Aug '12

13 Aug '12

commit d8eaa70279e380d73d0150c06dbc2b33e96f3810 Author: Roger Dingledine <arma(a)torproject.org> Date: Mon Aug 13 03:28:48 2012 -0400 move the pets and anonbib references to the frontpage and remove the redundant text too --- ideas.html | 14 -------- index.html | 109 ------------------------------------------------------------ 2 files changed, 0 insertions(+), 123 deletions(-) diff --git a/ideas.html b/ideas.html index 7947755..fd5fbe6 100644 --- a/ideas.html +++ b/ideas.html @@ -28,20 +28,6 @@ <h2>Research Ideas</h2> <br> -<p> -If you're interested in anonymity research, you must make it to the -<a href="http://petsymposium.org/">Privacy Enhancing Technologies -Symposium</a>. Everybody who's anybody in the anonymity research world -will be there. Stipends are generally available for people whose presence -will benefit the community. -</p> - -<p>To get up to speed on anonymity research, read <a -href="http://freehaven.net/anonbib/">these papers</a> (especially the -ones in boxes). -We also keep a list of <a href="techreports.html">Tor Tech Reports</a> -that are (co-)authored by Tor developers.</p> - <p>We need people to attack the system, quantify defenses, etc. Here are some example projects:</p> diff --git a/index.html b/index.html index 450824c..cc48583 100644 --- a/index.html +++ b/index.html @@ -110,35 +110,6 @@ really important. So let us know, and we'll work something out. </ul> -<a id="Groups"></a> -<h2><a class="anchor" href="#Groups">Research Groups</a></h2> -<br> - -<p>Interested to find other anonymity researchers? Here are some -research groups you should take a look at.</p> - -<ul> -<li>Ian Goldberg's <a href="http://crysp.uwaterloo.ca/">CrySP</a> group -at Waterloo. -</li> -<li><a href="http://www-users.cs.umn.edu/~hopper/">Nick Hopper</a>'s -group at UMN. -</li> -<li><a href="http://www.hatswitch.org/~nikita/">Nikita Borisov</a>'s -group at Illinois. -</li> -<li>Micah Sherr's <a href="https://security.cs.georgetown.edu/">SecLab</a> -group at Georgetown. -</li> -<li>Matt Wright's <a href="http://isec.uta.edu/">iSec</a> group at -UTA. -</li> -</ul> - -<a id="Ideas"></a> -<h2><a class="anchor" href="#Ideas">Research Ideas</a></h2> -<br> - <p> If you're interested in anonymity research, you must make it to the <a href="http://petsymposium.org/">Privacy Enhancing Technologies @@ -153,86 +124,6 @@ ones in boxes). We also keep a list of <a href="techreports.html">Tor Tech Reports</a> that are (co-)authored by Tor developers.</p> -<p>We need people to attack the system, quantify defenses, -etc. Here are some example projects:</p> - -<ul> - -<li>What algorithm should we use to assign Guard flags such that a) -we assign the flag to as many relays as possible, yet b) we minimize -the chance that Alice will use an attacker's node as a guard? See the -<a href="https://blog.torproject.org/research-problem-better-guard-rotation-paramete…">blog -post</a> for details. -</li> - -<li>For various diversity metrics, how has the diversity of -the Tor network changed over time? How robust is it to change or -attack? These results can help us make better design decisions. See the <a -href="https://blog.torproject.org/research-problem-measuring-safety-tor-network">blog post</a> -for details. -</li> - -<li>If we prevent the really loud users from using too much of the Tor -network, how much can it help? We've instrumented Tor's entry relays -so they can rate-limit connections from users, and we've instrumented -the directory authorities so they can change the rate-limiting -parameters globally across the network. Which parameter values improve -performance for the Tor network as a whole? How should relays adapt -their rate-limiting parameters based on their capacity and based on -the network load they see, and what rate-limiting algorithms will work -best? See the <a -href="https://blog.torproject.org/research-problem-adaptive-throttling-tor-client…">blog -post</a> for details. -</li> - -<li>Right now Tor clients are willing to reuse a given circuit for ten -minutes after it's first used. The goal is to avoid loading down the -network with too many circuit creations, yet to also avoid having -clients use the same circuit for so long that the exit node can build a -useful pseudonymous profile of them. Alas, ten minutes is probably way -too long, especially if connections from multiple protocols (e.g. IM and -web browsing) are put on the same circuit. If we keep fixed the overall -number of circuit extends that the network needs to do, are there more -efficient and/or safer ways for clients to allocate streams to circuits, -or for clients to build preemptive circuits? Perhaps this research item -needs to start with gathering some traces of what requests typical -clients try to launch, so you have something realistic to try to optimize. -</li> - -<li>The "website fingerprinting attack": make a list of a few -hundred popular websites, download their pages, and make a set of -"signatures" for each site. Then observe a Tor client's traffic. As -you watch him receive data, you quickly approach a guess about which -(if any) of those sites he is visiting. First, how effective is -this attack on the deployed Tor design? The problem with all the -previous attack papers is that they look at timing and counting of -IP packets on the wire. But OpenSSL's TLS records, plus Tor's use of -TCP pushback to do rate limiting, means that tracing by IP packets -produces very poor results. The right approach is to realize that -Tor uses OpenSSL, look inside the TLS record at the TLS headers, and -figure out how many 512-byte cells are being sent or received. Then -start exploring defenses: for example, we could change Tor's cell -size from 512 bytes to 1024 bytes, we could employ padding techniques -like <a href="http://freehaven.net/anonbib/#timing-fc2004">defensive -dropping</a>, or we could add traffic delays. How much of an impact do -these have, and how much usability impact (using some suitable metric) -is there from a successful defense in each case?</li> - - - -<li>More coming soon. See also the "Research" section of the <a -href="https://www.torproject.org/getinvolved/volunteer.html.en#Research">volunteer</a> page for -other topics. -</li> - -</ul> - </div> </div>

1 0

[research-web/master] break out index into groups and ideas file. muck with header too.
by arma＠torproject.org 13 Aug '12

13 Aug '12

commit bfb9d189e3adebbce09b26a6b876ed15c7e9d06a Author: Roger Dingledine <arma(a)torproject.org> Date: Mon Aug 13 03:25:20 2012 -0400 break out index into groups and ideas file. muck with header too. some further mucking with the header is probably in order, for example to change the color of the page you're on. --- groups.html | 57 ++++++++++++++++++++++++ ideas.html | 130 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ index.html | 6 ++- techreports.html | 6 ++- 4 files changed, 197 insertions(+), 2 deletions(-) diff --git a/groups.html b/groups.html new file mode 100644 index 0000000..165d267 --- /dev/null +++ b/groups.html @@ -0,0 +1,57 @@ +<html> +<head> +<title>Tor Research: Research Groups</title> +<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> +<link href="css/stylesheet-ltr.css" type="text/css" rel="stylesheet"> +<link href="/images/favicon.ico" type="image/x-icon" rel="shortcut icon"> +</head> +<body> + +<table class="banner" border="0" cellpadding="0" cellspacing="0" summary=""> +<tr> + <td class="banner-left"> + <a href="index.html"> + <img src="/images/top-left.png" alt="Click to go to home page" + width="193" height="79"></a></td> + <td class="banner-middle"> + <a href="index.html">Home</a><br> + Groups<br> + <a href="ideas.html">Ideas</a><br> + <a href="techreports.html">Tech Reports</a><br> + </td> + <td class="banner-right"></td> +</tr> +</table> + +<div class="center"> +<div class="main-column"> +<h2>Research Groups</h2> +<br> + +<p>Interested to find other anonymity researchers? Here are some +research groups you should take a look at.</p> + +<ul> +<li>Ian Goldberg's <a href="http://crysp.uwaterloo.ca/">CrySP</a> group +at Waterloo. +</li> +<li><a href="http://www-users.cs.umn.edu/~hopper/">Nick Hopper</a>'s +group at UMN. +</li> +<li><a href="http://www.hatswitch.org/~nikita/">Nikita Borisov</a>'s +group at Illinois. +</li> +<li>Micah Sherr's <a href="https://security.cs.georgetown.edu/">SecLab</a> +group at Georgetown. +</li> +<li>Matt Wright's <a href="http://isec.uta.edu/">iSec</a> group at +UTA. +</li> +</ul> + +</div> +</div> + +</body> +</html> + diff --git a/ideas.html b/ideas.html new file mode 100644 index 0000000..7947755 --- /dev/null +++ b/ideas.html @@ -0,0 +1,130 @@ +<html> +<head> +<title>Tor Research: Research Ideas</title> +<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> +<link href="css/stylesheet-ltr.css" type="text/css" rel="stylesheet"> +<link href="/images/favicon.ico" type="image/x-icon" rel="shortcut icon"> +</head> +<body> + +<table class="banner" border="0" cellpadding="0" cellspacing="0" summary=""> +<tr> + <td class="banner-left"> + <a href="index.html"> + <img src="/images/top-left.png" alt="Click to go to home page" + width="193" height="79"></a></td> + <td class="banner-middle"> + <a href="index.html">Home</a><br> + <a href="groups.html">Groups</a><br> + Ideas<br> + <a href="techreports.html">Tech Reports</a><br> + </td> + <td class="banner-right"></td> +</tr> +</table> + +<div class="center"> +<div class="main-column"> +<h2>Research Ideas</h2> +<br> + +<p> +If you're interested in anonymity research, you must make it to the +<a href="http://petsymposium.org/">Privacy Enhancing Technologies +Symposium</a>. Everybody who's anybody in the anonymity research world +will be there. Stipends are generally available for people whose presence +will benefit the community. +</p> + +<p>To get up to speed on anonymity research, read <a +href="http://freehaven.net/anonbib/">these papers</a> (especially the +ones in boxes). +We also keep a list of <a href="techreports.html">Tor Tech Reports</a> +that are (co-)authored by Tor developers.</p> + +<p>We need people to attack the system, quantify defenses, +etc. Here are some example projects:</p> + +<ul> + +<li>What algorithm should we use to assign Guard flags such that a) +we assign the flag to as many relays as possible, yet b) we minimize +the chance that Alice will use an attacker's node as a guard? See the +<a href="https://blog.torproject.org/research-problem-better-guard-rotation-paramete…">blog +post</a> for details. +</li> + +<li>For various diversity metrics, how has the diversity of +the Tor network changed over time? How robust is it to change or +attack? These results can help us make better design decisions. See the <a +href="https://blog.torproject.org/research-problem-measuring-safety-tor-network">blog post</a> +for details. +</li> + +<li>If we prevent the really loud users from using too much of the Tor +network, how much can it help? We've instrumented Tor's entry relays +so they can rate-limit connections from users, and we've instrumented +the directory authorities so they can change the rate-limiting +parameters globally across the network. Which parameter values improve +performance for the Tor network as a whole? How should relays adapt +their rate-limiting parameters based on their capacity and based on +the network load they see, and what rate-limiting algorithms will work +best? See the <a +href="https://blog.torproject.org/research-problem-adaptive-throttling-tor-client…">blog +post</a> for details. +</li> + +<li>Right now Tor clients are willing to reuse a given circuit for ten +minutes after it's first used. The goal is to avoid loading down the +network with too many circuit creations, yet to also avoid having +clients use the same circuit for so long that the exit node can build a +useful pseudonymous profile of them. Alas, ten minutes is probably way +too long, especially if connections from multiple protocols (e.g. IM and +web browsing) are put on the same circuit. If we keep fixed the overall +number of circuit extends that the network needs to do, are there more +efficient and/or safer ways for clients to allocate streams to circuits, +or for clients to build preemptive circuits? Perhaps this research item +needs to start with gathering some traces of what requests typical +clients try to launch, so you have something realistic to try to optimize. +</li> + +<li>The "website fingerprinting attack": make a list of a few +hundred popular websites, download their pages, and make a set of +"signatures" for each site. Then observe a Tor client's traffic. As +you watch him receive data, you quickly approach a guess about which +(if any) of those sites he is visiting. First, how effective is +this attack on the deployed Tor design? The problem with all the +previous attack papers is that they look at timing and counting of +IP packets on the wire. But OpenSSL's TLS records, plus Tor's use of +TCP pushback to do rate limiting, means that tracing by IP packets +produces very poor results. The right approach is to realize that +Tor uses OpenSSL, look inside the TLS record at the TLS headers, and +figure out how many 512-byte cells are being sent or received. Then +start exploring defenses: for example, we could change Tor's cell +size from 512 bytes to 1024 bytes, we could employ padding techniques +like <a href="http://freehaven.net/anonbib/#timing-fc2004">defensive +dropping</a>, or we could add traffic delays. How much of an impact do +these have, and how much usability impact (using some suitable metric) +is there from a successful defense in each case?</li> + + + +<li>More coming soon. See also the "Research" section of the <a +href="https://www.torproject.org/getinvolved/volunteer.html.en#Research">volunteer</a> page for +other topics. +</li> + +</ul> + +</div> +</div> + +</body> +</html> + diff --git a/index.html b/index.html index 54b1e85..450824c 100644 --- a/index.html +++ b/index.html @@ -14,7 +14,11 @@ <img src="/images/top-left.png" alt="Click to go to home page" width="193" height="79"></a></td> <td class="banner-middle"> - Tor Research<br></td> + Home<br> + <a href="groups.html">Groups</a><br> + <a href="ideas.html">Ideas</a><br> + <a href="techreports.html">Tech Reports</a><br> + </td> <td class="banner-right"></td> </tr> </table> diff --git a/techreports.html b/techreports.html index 4242910..5eadafc 100644 --- a/techreports.html +++ b/techreports.html @@ -14,7 +14,11 @@ <img src="/images/top-left.png" alt="Click to go to home page" width="193" height="79"></a></td> <td class="banner-middle"> - Tor Research</td> + <a href="index.html">Home</a><br> + <a href="groups.html">Groups</a><br> + <a href="ideas.html">Ideas</a><br> + Tech Reports<br> + </td> <td class="banner-right"></td> </tr> </table>

1 0

[tor/master] forward-port the 0.2.2.38 changelog
by arma＠torproject.org 13 Aug '12

13 Aug '12

commit 37d19fdfcd4bc82da3276c18b616e7c64ca0c6ab Author: Roger Dingledine <arma(a)torproject.org> Date: Mon Aug 13 00:35:37 2012 -0400 forward-port the 0.2.2.38 changelog --- ChangeLog | 25 +++++++++++++++++++++++++ ReleaseNotes | 25 +++++++++++++++++++++++++ 2 files changed, 50 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index 5f985e9..896fc70 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,28 @@ +Changes in version 0.2.2.38 - 2012-08-12 + Tor 0.2.2.38 fixes a rare race condition that can crash exit relays; + fixes a remotely triggerable crash bug; and fixes a timing attack that + could in theory leak path information. + + o Security fixes: + - Avoid read-from-freed-memory and double-free bugs that could occur + when a DNS request fails while launching it. Fixes bug 6480; + bugfix on 0.2.0.1-alpha. + - Avoid an uninitialized memory read when reading a vote or consensus + document that has an unrecognized flavor name. This read could + lead to a remote crash bug. Fixes bug 6530; bugfix on 0.2.2.6-alpha. + - Try to leak less information about what relays a client is + choosing to a side-channel attacker. Previously, a Tor client would + stop iterating through the list of available relays as soon as it + had chosen one, thus finishing a little earlier when it picked + a router earlier in the list. If an attacker can recover this + timing information (nontrivial but not proven to be impossible), + they could learn some coarse-grained information about which relays + a client was picking (middle nodes in particular are likelier to + be affected than exits). The timing attack might be mitigated by + other factors (see bug 6537 for some discussion), but it's best + not to take chances. Fixes bug 6537; bugfix on 0.0.8rc1. + + Changes in version 0.2.3.20-rc - 2012-08-05 Tor 0.2.3.20-rc is the third release candidate for the Tor 0.2.3.x series. It fixes a pair of code security bugs and a potential anonymity diff --git a/ReleaseNotes b/ReleaseNotes index 93e38fa..e9f6055 100644 --- a/ReleaseNotes +++ b/ReleaseNotes @@ -3,6 +3,31 @@ This document summarizes new features and bugfixes in each stable release of Tor. If you want to see more detailed descriptions of the changes in each development snapshot, see the ChangeLog file. +Changes in version 0.2.2.38 - 2012-08-12 + Tor 0.2.2.38 fixes a rare race condition that can crash exit relays; + fixes a remotely triggerable crash bug; and fixes a timing attack that + could in theory leak path information. + + o Security fixes: + - Avoid read-from-freed-memory and double-free bugs that could occur + when a DNS request fails while launching it. Fixes bug 6480; + bugfix on 0.2.0.1-alpha. + - Avoid an uninitialized memory read when reading a vote or consensus + document that has an unrecognized flavor name. This read could + lead to a remote crash bug. Fixes bug 6530; bugfix on 0.2.2.6-alpha. + - Try to leak less information about what relays a client is + choosing to a side-channel attacker. Previously, a Tor client would + stop iterating through the list of available relays as soon as it + had chosen one, thus finishing a little earlier when it picked + a router earlier in the list. If an attacker can recover this + timing information (nontrivial but not proven to be impossible), + they could learn some coarse-grained information about which relays + a client was picking (middle nodes in particular are likelier to + be affected than exits). The timing attack might be mitigated by + other factors (see bug 6537 for some discussion), but it's best + not to take chances. Fixes bug 6537; bugfix on 0.0.8rc1. + + Changes in version 0.2.2.37 - 2012-06-06 Tor 0.2.2.37 introduces a workaround for a critical renegotiation bug in OpenSSL 1.0.1 (where 20% of the Tor network can't talk to itself

1 0

[tor/release-0.2.3] forward-port the 0.2.2.38 changelog
by arma＠torproject.org 13 Aug '12

13 Aug '12

commit 09ac43bce23bf23431f8d191de241eb7e1776e4b Author: Roger Dingledine <arma(a)torproject.org> Date: Mon Aug 13 00:34:03 2012 -0400 forward-port the 0.2.2.38 changelog --- ChangeLog | 25 +++++++++++++++++++++++++ ReleaseNotes | 25 +++++++++++++++++++++++++ 2 files changed, 50 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index 5f985e9..896fc70 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,28 @@ +Changes in version 0.2.2.38 - 2012-08-12 + Tor 0.2.2.38 fixes a rare race condition that can crash exit relays; + fixes a remotely triggerable crash bug; and fixes a timing attack that + could in theory leak path information. + + o Security fixes: + - Avoid read-from-freed-memory and double-free bugs that could occur + when a DNS request fails while launching it. Fixes bug 6480; + bugfix on 0.2.0.1-alpha. + - Avoid an uninitialized memory read when reading a vote or consensus + document that has an unrecognized flavor name. This read could + lead to a remote crash bug. Fixes bug 6530; bugfix on 0.2.2.6-alpha. + - Try to leak less information about what relays a client is + choosing to a side-channel attacker. Previously, a Tor client would + stop iterating through the list of available relays as soon as it + had chosen one, thus finishing a little earlier when it picked + a router earlier in the list. If an attacker can recover this + timing information (nontrivial but not proven to be impossible), + they could learn some coarse-grained information about which relays + a client was picking (middle nodes in particular are likelier to + be affected than exits). The timing attack might be mitigated by + other factors (see bug 6537 for some discussion), but it's best + not to take chances. Fixes bug 6537; bugfix on 0.0.8rc1. + + Changes in version 0.2.3.20-rc - 2012-08-05 Tor 0.2.3.20-rc is the third release candidate for the Tor 0.2.3.x series. It fixes a pair of code security bugs and a potential anonymity diff --git a/ReleaseNotes b/ReleaseNotes index 93e38fa..e9f6055 100644 --- a/ReleaseNotes +++ b/ReleaseNotes @@ -3,6 +3,31 @@ This document summarizes new features and bugfixes in each stable release of Tor. If you want to see more detailed descriptions of the changes in each development snapshot, see the ChangeLog file. +Changes in version 0.2.2.38 - 2012-08-12 + Tor 0.2.2.38 fixes a rare race condition that can crash exit relays; + fixes a remotely triggerable crash bug; and fixes a timing attack that + could in theory leak path information. + + o Security fixes: + - Avoid read-from-freed-memory and double-free bugs that could occur + when a DNS request fails while launching it. Fixes bug 6480; + bugfix on 0.2.0.1-alpha. + - Avoid an uninitialized memory read when reading a vote or consensus + document that has an unrecognized flavor name. This read could + lead to a remote crash bug. Fixes bug 6530; bugfix on 0.2.2.6-alpha. + - Try to leak less information about what relays a client is + choosing to a side-channel attacker. Previously, a Tor client would + stop iterating through the list of available relays as soon as it + had chosen one, thus finishing a little earlier when it picked + a router earlier in the list. If an attacker can recover this + timing information (nontrivial but not proven to be impossible), + they could learn some coarse-grained information about which relays + a client was picking (middle nodes in particular are likelier to + be affected than exits). The timing attack might be mitigated by + other factors (see bug 6537 for some discussion), but it's best + not to take chances. Fixes bug 6537; bugfix on 0.0.8rc1. + + Changes in version 0.2.2.37 - 2012-06-06 Tor 0.2.2.37 introduces a workaround for a critical renegotiation bug in OpenSSL 1.0.1 (where 20% of the Tor network can't talk to itself

1 0

r25750: {website} 0.2.2.38 tarball is up (in website/trunk: . include)
by Roger Dingledine 13 Aug '12

13 Aug '12

Author: arma Date: 2012-08-13 04:32:00 +0000 (Mon, 13 Aug 2012) New Revision: 25750 Modified: website/trunk/Makefile website/trunk/include/versions.wmi Log: 0.2.2.38 tarball is up Modified: website/trunk/Makefile =================================================================== --- website/trunk/Makefile 2012-08-12 21:13:26 UTC (rev 25749) +++ website/trunk/Makefile 2012-08-13 04:32:00 UTC (rev 25750) @@ -10,7 +10,7 @@ # 4. make # 5. ./publish -export STABLETAG=tor-0.2.2.37 +export STABLETAG=tor-0.2.2.38 export DEVTAG=tor-0.2.3.20-rc WMLBASE=. Modified: website/trunk/include/versions.wmi =================================================================== --- website/trunk/include/versions.wmi 2012-08-12 21:13:26 UTC (rev 25749) +++ website/trunk/include/versions.wmi 2012-08-13 04:32:00 UTC (rev 25750) @@ -1,4 +1,4 @@ -<define-tag version-stable whitespace=delete>0.2.2.37</define-tag> +<define-tag version-stable whitespace=delete>0.2.2.38</define-tag> <define-tag version-alpha whitespace=delete>0.2.3.20-rc</define-tag> <define-tag version-win32-stable whitespace=delete>0.2.2.37</define-tag>

1 0

[tor/release-0.2.2] give 0.2.2.38 a release blurb
by arma＠torproject.org 12 Aug '12

12 Aug '12

commit 49d150a9fad2cb8d3887af1e112b15365c11f4ba Author: Roger Dingledine <arma(a)torproject.org> Date: Sun Aug 12 18:11:34 2012 -0400 give 0.2.2.38 a release blurb --- ChangeLog | 4 ++++ ReleaseNotes | 4 ++++ 2 files changed, 8 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index 2be41ec..3d24db5 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,4 +1,8 @@ Changes in version 0.2.2.38 - 2012-08-12 + Tor 0.2.2.38 fixes a rare race condition that can crash exit relays; + fixes a remotely triggerable crash bug; and fixes a timing attack that + could in theory leak path information. + o Security fixes: - Avoid read-from-freed-memory and double-free bugs that could occur when a DNS request fails while launching it. Fixes bug 6480; diff --git a/ReleaseNotes b/ReleaseNotes index 39ce420..58e95b7 100644 --- a/ReleaseNotes +++ b/ReleaseNotes @@ -4,6 +4,10 @@ of Tor. If you want to see more detailed descriptions of the changes in each development snapshot, see the ChangeLog file. Changes in version 0.2.2.38 - 2012-08-12 + Tor 0.2.2.38 fixes a rare race condition that can crash exit relays; + fixes a remotely triggerable crash bug; and fixes a timing attack that + could in theory leak path information. + o Security fixes: - Avoid read-from-freed-memory and double-free bugs that could occur when a DNS request fails while launching it. Fixes bug 6480;

1 0

[torbrowser/maint-2.3] bump recommended-versions for 2.3.20-alpha-1
by erinn＠torproject.org 12 Aug '12

12 Aug '12

commit 8f065c86df82311cf4e07f8d147d9eec5f9e46d7 Author: Erinn Clark <erinn(a)torproject.org> Date: Sun Aug 12 22:20:01 2012 +0100 bump recommended-versions for 2.3.20-alpha-1 --- build-scripts/recommended-versions | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/build-scripts/recommended-versions b/build-scripts/recommended-versions index 90662a0..d26819d 100644 --- a/build-scripts/recommended-versions +++ b/build-scripts/recommended-versions @@ -4,8 +4,8 @@ "2.2.37-2-Windows", "2.2.37-2-Linux-i686", "2.2.37-2-Linux-x86_64", -"2.3.19-alpha-1-MacOS-i386", -"2.3.19-alpha-1-Windows", -"2.3.19-alpha-1-Linux-i386", -"2.3.19-alpha-1-Linux-x86_64" +"2.3.20-alpha-1-MacOS-i386", +"2.3.20-alpha-1-Windows", +"2.3.20-alpha-1-Linux-i386", +"2.3.20-alpha-1-Linux-x86_64" ]

1 0

← Newer
1
...
54
55
56
57
58
59
60
...
91
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits August 2012