[or-cvs] r11279: merged with trunk revision 11064, fixed some bugs in v2 desc (in tor/branches/114-dist-storage: contrib debian doc doc/design-paper doc/spec/proposals src/common src/or src/tools src/win32)

[kloesing at seul.org]

Author: kloesing
Date: 2007-08-26 17:03:54 -0400 (Sun, 26 Aug 2007)
New Revision: 11279

Added:
   tor/branches/114-dist-storage/doc/spec/proposals/116-two-hop-paths-from-guard.txt
   tor/branches/114-dist-storage/doc/spec/proposals/117-ipv6-exits.txt
Modified:
   tor/branches/114-dist-storage/contrib/tor-mingw.nsi.in
   tor/branches/114-dist-storage/debian/changelog
   tor/branches/114-dist-storage/doc/design-paper/blocking.html
   tor/branches/114-dist-storage/doc/design-paper/blocking.tex
   tor/branches/114-dist-storage/doc/spec/proposals/114-distributed-storage.txt
   tor/branches/114-dist-storage/doc/spec/proposals/115-two-hop-paths.txt
   tor/branches/114-dist-storage/doc/tor.1.in
   tor/branches/114-dist-storage/src/common/crypto.c
   tor/branches/114-dist-storage/src/common/crypto.h
   tor/branches/114-dist-storage/src/or/config.c
   tor/branches/114-dist-storage/src/or/directory.c
   tor/branches/114-dist-storage/src/or/dirserv.c
   tor/branches/114-dist-storage/src/or/or.h
   tor/branches/114-dist-storage/src/or/rendcommon.c
   tor/branches/114-dist-storage/src/or/rendservice.c
   tor/branches/114-dist-storage/src/or/routerlist.c
   tor/branches/114-dist-storage/src/or/routerparse.c
   tor/branches/114-dist-storage/src/or/test.c
   tor/branches/114-dist-storage/src/tools/Makefile.am
   tor/branches/114-dist-storage/src/tools/tor-gencert.c
   tor/branches/114-dist-storage/src/tools/tor-resolve.c
   tor/branches/114-dist-storage/src/win32/orconfig.h
Log:
merged with trunk revision 11064, fixed some bugs in v2 descriptor handling

/home/or/svnrepo/hooks/commit-email.pl: `/usr/bin/svnlook diff /home/or/svnrepo -r 11279' failed with this output:
Modified: tor/branches/114-dist-storage/contrib/tor-mingw.nsi.in
===================================================================
--- tor/branches/114-dist-storage/contrib/tor-mingw.nsi.in	2007-08-26 19:30:57 UTC (rev 11278)
+++ tor/branches/114-dist-storage/contrib/tor-mingw.nsi.in	2007-08-26 21:03:54 UTC (rev 11279)
@@ -5,7 +5,7 @@
 ;
 !include "MUI.nsh"
 
-!define VERSION "0.2.0.2-alpha-dev"
+!define VERSION "0.2.0.4-alpha-dev"
 !define INSTALLER "tor-${VERSION}-win32.exe"
 !define WEBSITE "http://tor.eff.org/"
 

Modified: tor/branches/114-dist-storage/debian/changelog
===================================================================
--- tor/branches/114-dist-storage/debian/changelog	2007-08-26 19:30:57 UTC (rev 11278)
+++ tor/branches/114-dist-storage/debian/changelog	2007-08-26 21:03:54 UTC (rev 11279)
@@ -1,3 +1,15 @@
+tor (0.2.0.4-alpha-1) experimental; urgency=high
+
+  * New upstream version.
+
+ -- Peter Palfrader <weasel at debian.org>  Thu,  2 Aug 2007 07:09:36 +0200
+
+tor (0.2.0.3-alpha-1) experimental; urgency=low
+
+  * New upstream version.
+
+ -- Peter Palfrader <weasel at debian.org>  Tue, 31 Jul 2007 07:03:00 +0200
+
 tor (0.2.0.2-alpha-1) experimental; urgency=low
 
   * New upstream version.
@@ -16,6 +28,19 @@
 
  -- Peter Palfrader <weasel at debian.org>  Sat,  2 Jun 2007 14:31:15 +0200
 
+tor (0.1.2.16-1) unstable; urgency=high
+
+  * New upstream version.
+
+ -- Peter Palfrader <weasel at debian.org>  Thu,  2 Aug 2007 06:43:09 +0200
+
+tor (0.1.2.15-1) unstable; urgency=low
+
+  * New upstream version.
+  * Change build-depends from tetex to texlive suite.
+
+ -- Peter Palfrader <weasel at debian.org>  Thu, 19 Jul 2007 22:33:43 +0200
+
 tor (0.1.2.14-1) unstable; urgency=low
 
   * New upstream version.

Modified: tor/branches/114-dist-storage/doc/design-paper/blocking.html
===================================================================
--- tor/branches/114-dist-storage/doc/design-paper/blocking.html	2007-08-26 19:30:57 UTC (rev 11278)
+++ tor/branches/114-dist-storage/doc/design-paper/blocking.html	2007-08-26 21:03:54 UTC (rev 11279)
@@ -1516,7 +1516,7 @@
 a USB-based Tor image would be smart. There's Torpark, and hopefully
 there will be more thoroughly analyzed and trustworthy options down the
 road. Worries remain about hardware or software keyloggers and other
-spyware, as well as and physical surveillance.
+spyware, as well as physical surveillance.
 
 <div class="p"><!----></div>
 If the system lets you boot from a CD or from a USB key, you can gain

Modified: tor/branches/114-dist-storage/doc/design-paper/blocking.tex
===================================================================
--- tor/branches/114-dist-storage/doc/design-paper/blocking.tex	2007-08-26 19:30:57 UTC (rev 11278)
+++ tor/branches/114-dist-storage/doc/design-paper/blocking.tex	2007-08-26 21:03:54 UTC (rev 11279)
@@ -1425,7 +1425,7 @@
 a USB-based Tor image would be smart. There's Torpark, and hopefully
 there will be more thoroughly analyzed and trustworthy options down the
 road. Worries remain about hardware or software keyloggers and other
-spyware, as well as and physical surveillance.
+spyware, as well as physical surveillance.
 
 If the system lets you boot from a CD or from a USB key, you can gain
 a bit more security by bringing a privacy LiveCD with you. (This

Modified: tor/branches/114-dist-storage/doc/spec/proposals/114-distributed-storage.txt
===================================================================
--- tor/branches/114-dist-storage/doc/spec/proposals/114-distributed-storage.txt	2007-08-26 19:30:57 UTC (rev 11278)
+++ tor/branches/114-dist-storage/doc/spec/proposals/114-distributed-storage.txt	2007-08-26 21:03:54 UTC (rev 11279)
@@ -1,7 +1,7 @@
 Filename: 114-distributed-storage.txt
 Title: Distributed Storage for Tor Hidden Service Descriptors
-Version: $Revision: 10821 $
-Last-Modified: $Date: 2007-07-12 19:06:13 +0100 (Do, 12 Jul 2007) $
+Version: $Revision: 11224 $
+Last-Modified: $Date: 2007-08-20 17:32:00 +0100 (Mo, 20 Aug 2007) $
 Author: Karsten Loesing
 Created: 13-May-2007
 Status: Open
@@ -9,10 +9,13 @@
 Change history:
 
   13-May-2007  Initial proposal
-  14-May-2007  Added changes suggested by Lasse Overlier
+  14-May-2007  Added changes suggested by Lasse Øverlier
   30-May-2007  Changed descriptor format, key length discussion, typos
   09-Jul-2007  Incorporated suggestions by Roger, added status of specification
                and implementation for upcoming GSoC mid-term evaluation
+  11-Aug-2007  Updated implementation statuses, included non-consecutive
+               replication to descriptor format
+  20-Aug-2007  Renamed config option HSDir as HidServDirectoryV2
 
 Overview:
 
@@ -128,8 +131,13 @@
     - routerlist.c: Changed router_get_routerlist() to initialize routing list.
     - or.h: Added hs_dirs member to routerlist_t.
 
-      [July 9: Specified and running, though the routing list is compiled for
-       each request anew.]
+    - Changed routerlist_free() to free storage held by routing list.
+    - Added UPDATE_HS_DIRS_INTERVAL.
+    - Added update_hs_dir_routing_table().
+    - Changed run_scheduled_events().
+    - Added is_hs_dir member to routerstatus_t.
+    
+      [Aug 11: Specified and running.]
 
   /2/ Determine responsible hidden service directory
 
@@ -144,11 +152,13 @@
     - rend-spec.txt, section 1.4: Added description of how to determine the
       responsible node(s) for a given descriptor ID.
 
-    - routerlist.c: Added get_responsible_hs_dir() to determine the router that
-      is responsible for a given descriptor ID.
-    - container.h: Added prototype for smartlist_digest_next_circular().
-    - container.c: Added implementation for smartlist_digest_next_circular().
-
+    - routerlist.c: Added get_responsible_hs_dirs() to determine the routers
+      that are responsible for a given descriptor ID.
+      
+    - Added is_hs_dir member to routerstatus_t.
+    - Added have_enough_hs_dirs().
+    - Added next_hs_dir().
+    
       [July 9: Specified and running.]
     
   Hidden service clients and providers:
@@ -177,11 +187,11 @@
 
     Every onion router that has its directory port open can decide whether it
     wants to store and serve hidden service descriptors by setting a new config
-    option "HSDir" 0|1 to 1. An onion router with this config option being set
-    includes the flag "hidden-service-dir" in its router descriptors that it
-    sends to directory authorities.
+    option "HidServDirectoryV2" 0|1 to 1. An onion router with this config
+    option being set includes the flag "hidden-service-dir" in its router
+    descriptors that it sends to directory authorities.
 
-    - tor.1.in: Added the config option HSDir.
+    - tor.1.in: Added the config option HidServDirectoryV2.
     - dir-spec.txt, section 2.1: Added the flag hidden-service-dir to the
       router descriptor format.
     - rend-spec.txt, section 3.1: Added process of configuring a hidden service
@@ -189,8 +199,8 @@
 
     - router.c: Changed router_dump_router_to_string() to include the
       hidden-service-dir flag in a router descriptor if configured.
-    - or.h: Added HSDir to or_options_t.
-    - config.c: Added config option HSDir.
+    - or.h: Added HidServDirectoryV2 to or_options_t.
+    - config.c: Added config option HidServDirectoryV2.
 
       [July 9: Specified and running.]
       
@@ -220,20 +230,19 @@
     - routerparse.c: Added 8 keywords to directory_keyword to parse v2 hidden
       service descriptors.
     - rendcommon.c: Added rend_cache_store_v2_dir() to allow a hidden service
-      directory to store a v2 descriptor in the local cache under its
-      descriptor ID instead of its service ID.
-    - rendcommon.c: Moved the parsing part from rend_cache_store() to the new
-      function rend_cache_store_parse() to reuse it for v2 descriptors.
+      directory to parse a v2 descriptor and store it in the local cache under
+      its descriptor ID instead of its service ID.
     - or.h: Added constant REND_DESC_ID_V2_LEN to reflect that v2 descriptor
       IDs are longer than v0/1 onion addresses.
 
-      [July 9: Base version specified and running; no checking of published
-       descriptors, tunneling over BEGIN_DIR cells not yet implemented.]
+    - Changed directory_handle_command_post().
+    
+      [Aug 11: Specified and running.]
 
   /7/ Accept v2 fetch requests
 
     Same as /6/, but with fetch requests for hidden service descriptors.
-    (requires /4/)
+    (requires /2/ and /4/)
 
     - rend-spec.txt, section 3.3: Added the processing of v2 fetch requests.
 
@@ -243,8 +252,9 @@
     - or.h: Added constant REND_DESC_ID_V2_LEN to reflect that v2 descriptor
       IDs are longer than v0/1 onion addresses.
 
-      [July 9: Base version specified and running; tunneling over BEGIN_DIR
-       cells not yet implemented.]
+    - Changed directory_handle_command_get().
+    
+      [Aug 11: Specified and running.]
 
   /8/ Replicate descriptors with neighbors
 
@@ -261,8 +271,19 @@
 
     - rend-spec.txt, section 3.3: Added the replication of v2 descriptors.
 
-      [July 9: To some extend specified, but not yet implemented.]
+    - Added HS_DIR_REPLICATION_INTERVAL.
+    - Added next_hs_dir and previous_hs_dir.
+    - Changed directory_handle_command_get().
+    - Changed run_scheduled_events.
+    - Added hs_dir_perform_replication().
+    - Added rend_cache_lookup_v2_replicas.
+    - Added DIR_PURPOSE_REPLICATE_RENDDESC_V2.
+    - Changed directory_initiate_command.
+    - directory_send_command.
+    - Changed connection_dir_client_reached_eof.
 
+      [Aug 11: To some extend specified, running.]
+
   Authoritative directory nodes:
 
   /9/ Confirm a router's hidden service directory functionality
@@ -286,16 +307,17 @@
       "hidden-service-directory" flag in router descriptors.
     - routerparse.c: Added 1 keyword to directory_keyword to parse the
       "hidden-service-dir" flag in router descriptors.
-    - or.h: Added is_hs_dir member to routerinfo_t and to routerstatus_t.
+    - or.h: Added is_hs_dir and wants_to_be_hs_dir members to routerinfo_t.
     - dirserv.c: Changed routerstatus_format_entry() to include the "HSDir"
       flag in vote and consensus status documents.
     - dirserv.c: Changed set_routerstatus_from_routerinfo() to set the "HSDir"
       flag.
 
-      [July 9: Base version specified and running in which all nodes that have
-       the hidden-service-dir flag set in their router descriptor get the
-       HSDir flag, not only those which are running for at least 24 hours.]
+    - Added dirserv_thinks_router_is_hs_dir().
+    - Added MIN_UPTIME_HS_DIR and HS_DIR_REACHABLE_TIMEOUT.
 
+      [Aug 11: Specified and running.]
+
   Hidden service provider:
 
   /10/ Configure v2 hidden service
@@ -339,6 +361,8 @@
       service provider uses a freshly generated public key for every
       introduction point.
 
+    - TODO: Change in rend_encode_v2_descriptors.
+
       [July 9: Specified, but not yet implemented.]
 
   /12/ Encode v2 descriptors and send v2 publish requests
@@ -352,7 +376,7 @@
     the next period. Publication is performed by sending the descriptor to all
     hidden service directories that are responsible for keeping replicas for
     the descriptor ID. This includes two non-consecutive replicas that are
-    stored at 3 consecutive nodes each. (requires /1/ and /3/)
+    stored at 3 consecutive nodes each. (requires /1/, /2/, and /3/)
 
     - rend-spec.txt, section 1.2: Added the new v2 hidden service descriptor
       format.
@@ -365,25 +389,20 @@
     - rendservice.c: Changed rend_consider_services_upload() to also initiate
       the upload of v2 descriptors, if configured.
     - rendservice.c: Extended rend_service_t by a member secret_cookie.
-    - rendcommon.c: Added rend_compute_v2_descriptor_fields() to prepare the
-      encoding of a v2 descriptor.
     - rendcommon.c: Added rend_encode_v2_descriptor() to encode a v2
       descriptor.
-    - or.h: Added 7 new members to rend_service_descriptor_t to store
-      v2-specific information.
     - or.h: Added constant DIR_PURPOSE_UPLOAD_RENDDESC_V2.
     - directory.c: Added directory_post_to_hs_dir().
     - directory.c: Changed directory_initiate_command() to also recognize v2
       publish requests.
     - directory.c: Changed directory_send_command() to also prepare v2 publish
       requests.
-    - directory.c: Changed directory_handle_command_post() to handle v2 publish
-      requests.
     - crypto.c: Added implementation for crypto_cipher_encrypt_cbc().
 
-      [July 9: Base version specified and running; yet, replication is not
-       implemented, republication does not depend on publication periods, yet.]
+    - Changed connection_dir_client_reached_eof().
 
+      [Aug 11: Specified and running.]
+
   Hidden service client:
 
   /13/ Send v2 fetch requests
@@ -407,10 +426,10 @@
 
     - rendcommon.c: Changed rend_cache_lookup_entry to enable it to also lookup
       v2 descriptors.
-    - rendcommon.c: Added rend_compute_desc_id() to generate v2 descriptor IDs
+    - rendcommon.c: Added rend_compute_v2_desc_id() to generate v2 descriptor IDs
       from v2 onion addresses.
     - rendcommon.c: Changed rend_valid_service_id() to also consider v2 onion
-      addresses as valid and return the version number of the request (1 or 2).
+      addresses as valid and return the version number of the request (0 or 2).
     - rendclient.c: Added rend_client_refetch_v2_renddesc() to fetch v2 service
       descriptors using the secret cookie.
     - rendclient.c: Changed rend_client_remove_intro_point() to copy the secret
@@ -425,16 +444,14 @@
       fetch requests.
     - directory.c: Changed directory_send_command() to also prepare v2 fetch
       requests.
-    - directory.c: Changed directory_handle_command_get() to handle v2 fetch
-      requests.
     - connection_edge.c: Changed connection_ap_handshake_rewrite_and_attach()
       to fetch v2 service descriptors.
     - connection_edge.c: Changed parse_extended_hostname() to accept both,
       current and v2 onion addresses.
     - config.c: Added config options FetchV2HidServDescriptors.
 
-      [July 9: Base version specified and running in which only one node is
-       responsible for a specific descriptor ID.]
+      [Aug 11: Base version specified and running, but no memory of failed
+       hidden service directories, yet.]
 
   /14/ Process v2 fetch reply and parse v2 descriptors
 
@@ -454,15 +471,14 @@
       introduction points of v2 hidden service descriptors.
     - routerparse.c: Added desc_token_table[] to parse v2 hidden service
       descriptors.
-    - routerparse.c: Added 8 to directory_keyword to parse v2 hidden service
-      descriptors, and 5 to parse the decrypted list of introduction points.
+    - routerparse.c: Added 8 keywords to directory_keyword to parse v2 hidden
+      service descriptors, and 5 to parse the decrypted list of introduction
+      points.
     - rendcommon.c: Added rend_cache_store_v2_client() to parse a v2 descriptor
       and parse the encrypted list of introduction points.
-    - or.h: Added secret_cookie to edge_connection_t, to dir_connection_t, and
-      to origin_circuit_t to be able to decrypt introduction points when
-      receiving a v2 descriptor.
-    - or.h: Added 7 new members to rend_service_descriptor_t to store
-      v2-specific information.
+    - or.h: Added rend_version and secret_cookie to edge_connection_t, to
+      dir_connection_t, and to origin_circuit_t to be able to decrypt
+      introduction points when receiving a v2 descriptor.
     - directory.c: Changed connection_dir_client_reached_eof() to also parse v2
       fetch replies.
     - crypto.c: Added implementation for crypto_cipher_decrypt_cbc().
@@ -492,8 +508,6 @@
     - or.h: Added secret_cookie to edge_connection_t, to dir_connection_t, and
       to origin_circuit_t to be able to decrypt introduction points when
       receiving a v2 descriptor.
-    - or.h: Added 7 new members to rend_service_descriptor_t to store
-      v2-specific information.
     - circuitlist.c: Changed _circuit_mark_for_close() to pass the secret
       cookie to rend_client_remove_intro_point() when an intro circ has failed.
     - circuituse.c: Changed circuit_get_open_circ_or_launch() to fetch a v2
@@ -510,12 +524,12 @@
     The new v2 hidden service descriptor format looks like this:
 
       onion-address = h(public-key) + cookie
-      descriptor-id = h(h(public-key) + h(time-period + cookie))
+      descriptor-id = h(h(public-key) + h(time-period + cookie + relica))
       descriptor-content = {
         descriptor-id,
         version,
         public-key,
-        h(time-period + cookie),
+        h(time-period + cookie + replica),
         timestamp,
         protocol-versions,
         { introduction-points } encrypted with cookie
@@ -531,13 +545,14 @@
     
     Therefore, "descriptor-id" is derived from the "public-key" of the hidden
     service provider, the current "time-period" which changes every 24 hours,
-    and a secret "cookie" shared between hidden service provider and clients.
-    (The "time-period" is constructed in a way that time periods do not change
-    at the same moment for all descriptors by deriving a value between 0:00 and
-    23:59 hours from "public-key" and making the descriptors of this hidden
+    a secret "cookie" shared between hidden service provider and clients, and
+    a "replica" denoting the number of this non-consecutive replica. (The
+    "time-period" is constructed in a way that time periods do not change at
+    the same moment for all descriptors by deriving a value between 0:00 and
+    23:59 hours from h(public-key) and making the descriptors of this hidden
     service provider expire at that time of the day.) The "descriptor-id" is
     defined to be 160 bits long. [extending the "descriptor-id" length
-    suggested by LO]
+    suggested by LØ]
     
     Only the hidden service provider and the clients are able to generate
     future "descriptor-ID"s. Hence, the "onion-address" is extended from now 
@@ -556,7 +571,7 @@
     The "introduction-points" that are included in the descriptor are encrypted
     using the same "cookie" that is shared between hidden service provider and
     clients. [correction to use another key than h(time-period + cookie) as
-    encryption key for introduction points made by LO]
+    encryption key for introduction points made by LØ]
 
     A new text-based format is proposed for descriptors instead of an extension
     of the existing binary format for reasons of future extensibility.
@@ -670,8 +685,8 @@
 
   tor.1.in
 
-    Added the config options HSDir (/5/), PublishV2HidServDescriptors (/10/),
-    and FetchV2HidServDescriptors (/13/).
+    Added the config options HidServDirectoryV2 (/5/),
+    PublishV2HidServDescriptors (/10/), and FetchV2HidServDescriptors (/13/).
 
     Added the files hostname2 and secret_cookie (/10/).
 
@@ -780,8 +795,8 @@
 
   config.c
 
-    Added config options FetchV2HidServDescriptors (/13/), HSDir (/5/), and
-    PublishV2HidServDescriptors (/10/).
+    Added config options FetchV2HidServDescriptors (/13/),
+    HidServDirectoryV2 (/5/), and PublishV2HidServDescriptors (/10/).
 
   connection_edge.c
 
@@ -834,7 +849,7 @@
 
     Added hs_dirs member to routerlist_t (/1/).
 
-    Added FetchV2HidServDescriptors (/13/), HSDir (/5/), and
+    Added FetchV2HidServDescriptors (/13/), HidServDirectoryV2 (/5/), and
     PublishV2HidServDescriptors (/10/) to or_options_t.
 
     Added 7 new members to rend_service_descriptor_t to store v2-specific
@@ -940,4 +955,10 @@
     Added rend_decrypt_introduction_points() to decrypt and parse the list of
     introduction points (/14/).
 
- 
+Test: 
+
+  The changes were tested via test functions in test.c for separate,
+  short-running functionality and using an automatic validation based on
+  PuppeTor.
+
+  
\ No newline at end of file

Modified: tor/branches/114-dist-storage/doc/spec/proposals/115-two-hop-paths.txt
===================================================================
--- tor/branches/114-dist-storage/doc/spec/proposals/115-two-hop-paths.txt	2007-08-26 19:30:57 UTC (rev 11278)
+++ tor/branches/114-dist-storage/doc/spec/proposals/115-two-hop-paths.txt	2007-08-26 21:03:54 UTC (rev 11279)
@@ -1,7 +1,7 @@
 Filename: 115-two-hop-paths.txt
 Title: Two Hop Paths
 Version: $Revision: 10625 $
-Last-Modified: $Date: 2007-06-17 00:23:19 +0100 (So, 17 Jun 2007) $
+Last-Modified: $Date: 2007-06-17 01:23:19 +0200 (So, 17 Jun 2007) $
 Author: Mike Perry
 Created:
 Status: Open

Added: tor/branches/114-dist-storage/doc/spec/proposals/116-two-hop-paths-from-guard.txt
===================================================================
--- tor/branches/114-dist-storage/doc/spec/proposals/116-two-hop-paths-from-guard.txt	                        (rev 0)
+++ tor/branches/114-dist-storage/doc/spec/proposals/116-two-hop-paths-from-guard.txt	2007-08-26 21:03:54 UTC (rev 11279)
@@ -0,0 +1,120 @@
+Filename: 116-two-hop-paths-from-guards.txt
+Title: Two hop paths from entry guards
+Version: $Revision: 10685 $
+Last-Modified: $Date: 2007-06-26 23:57:09 +0200 (Di, 26 Jun 2007) $
+Author: Michael Lieberman
+Created: 26-Jun-2007
+Status: Open
+
+This proposal is related to (but different from) Mike Perry's proposal 115
+"Two Hop Paths."
+
+Overview:
+
+Volunteers who run entry guards should have the option of using only 2
+additional tor nodes when constructing their own tor circuits.
+
+While the option of two hop paths should perhaps be extended to every client
+(as discussed in Mike Perry's thread), I believe the anonymity properties of
+two hop paths are particularly well-suited to client computers that are also
+serving as entry guards.
+
+First I will describe the details of the strategy, as well as possible
+avenues of attack. Then I will list advantages and disadvantages. Then, I
+will discuss some possibly safer variations of the strategy, and finally
+some implementation issues.
+
+Details:
+
+Suppose Alice is an entry guard, and wants to construct a two hop circuit.
+Alice chooses a middle node at random (not using the entry guard strategy),
+and gains anonymity by having her traffic look just like traffic from
+someone else using her as an entry guard.
+
+Can Alice's middle node figure out that she is initiator of the traffic? I
+can think of four possible approaches for distinguishing traffic from Alice
+with traffic through Alice:
+
+1) Notice that communication from Alice comes too fast: Experimentation is
+needed to determine if traffic from Alice can be distinguished from traffic
+from a computer with a decent link to Alice.
+
+2) Monitor Alice's network traffic to discover the lack of incoming packets
+at the appropriate times. If an adversary has this ability, then Alice
+already has problems in the current system, because the adversary can run a
+standard timing attack on Alice's traffic.
+
+3) Notice that traffic from Alice is unique in some way such that if Alice
+was just one of 3 entry guards for this traffic, then the traffic should be
+coming from two other entry guards as well. An example of "unique traffic"
+could be always sending 117 packets every 3 minutes to an exit node that
+exits to port 4661. However, if such patterns existed with sufficient
+precision, then it seems to me that Tor already has a problem. (This "unique
+traffic" may not be a problem if clients often end up choosing a single
+entry guard because their other two are down. Does anyone know if this is
+the case?)
+
+4) First, control the middle node *and* some other part of the traffic,
+using standard attacks on a two hop circuit without entry nodes (my recent
+paper on Browser-Based Attacks would work well for this
+http://petworkshop.org/2007/papers/PET2007_preproc_Browser_based.pdf). With
+control of the circuit, we can now cause "unique traffic" as in 3).
+Alternatively, if we know something about Alice independently, and we can
+see what websites are being visited, we might be able to guess that she is
+the kind of person that would visit those websites.
+
+Anonymity Advantages:
+
+-Alice never has the problem of choosing a malicious entry guard. In some
+sense, Alice acts as her own entry guard.
+
+Anonymity Disadvantages:
+
+-If Alice's traffic is identified as originating from herself (see above for
+how hard that might be), then she has the anonymity of a 2 hop circuit
+without entry guards.
+
+Additional advantages:
+
+-A discussion of the latency advantages of two hop circuits is going on in
+Mike Perry's thread already.
+-Also, we can advertise this change as "Run an entry guard and decrease your
+own Tor latency." This incentive has the potential to add nodes to the
+network, improving the network as a whole.
+
+Safer variations:
+
+To solve the "unique traffic" problem, Alice could use two hop paths only
+1/3 of the time, and choose 2 other entry guards for the other 2/3 of the
+time. All the advantages are now 1/3 as useful (possibly more, if the other
+2 entry guards are not always up).
+
+To solve the problem that Alice's responses are too fast, Alice could delay
+her responses (ideally based on some real data of response time when Alice
+is used an entry guard). This loses most of the speed advantages of the two
+hop path, but if Alice is a fast entry guard, it doesn't lose everything. It
+also still has the (arguable) anonymity advantage that Alice doesn't have to
+worry about having a malicious entry guard.
+
+Implementation details:
+For Alice to remain anonymous using this strategy, she has to actually be
+acting as an entry guard for other nodes. This means the two hop option can
+only be available to whatever high-performance threshold is currently set on
+entry guards. Alice may need to somehow check her own current status as an
+entry guard before choosing this two hop strategy.
+
+Another thing to consider: suppose Alice is also an exit node. If the
+fraction of exit nodes in existence is too small, she may rarely or never be
+chosen as an entry guard. It would be sad if we offered an incentive to run
+an entry guard that didn't extend to exit nodes. I suppose clients of Exit
+nodes could pull the same trick, and bypass using Tor altogether (zero hop
+paths), though that has additional issues.*
+
+Mike Lieberman
+MIT
+
+*Why we shouldn't recommend Exit nodes pull the same trick:
+1) Exit nodes would suffer heavily from the problem of "unique traffic"
+mentioned above.
+2) It would give governments an incentive to confiscate exit nodes to see if
+they are pulling this trick.

Added: tor/branches/114-dist-storage/doc/spec/proposals/117-ipv6-exits.txt
===================================================================
--- tor/branches/114-dist-storage/doc/spec/proposals/117-ipv6-exits.txt	                        (rev 0)
+++ tor/branches/114-dist-storage/doc/spec/proposals/117-ipv6-exits.txt	2007-08-26 21:03:54 UTC (rev 11279)
@@ -0,0 +1,387 @@
+Proposal : IPv6 exit
+
+Overview
+
+   Extend Tor for TCP exit via IPv6 transport and DNS resolution of IPv6
+   addresses.  This proposal does not imply any IPv6 support for OR
+   traffic, only exit and name resolution.
+
+
+Contents
+
+0. Motivation
+
+   As the IPv4 address space becomes more scarce there is increasing
+   effort to provide Internet services via the IPv6 protocol.  Many
+   hosts are available at IPv6 endpoints which are currently
+   inaccessible for Tor users.
+
+   Extending Tor to support IPv6 exit streams and IPv6 DNS name
+   resolution will allow users of the Tor network to access these hosts.
+   This capability would be present for those who do not currently have
+   IPv6 access, thus increasing the utility of Tor and furthering
+   adoption of IPv6.
+
+
+1. Design
+
+1.1. General design overview
+
+   There are three main components to this proposal.  The first is a
+   method for routers to advertise their ability to exit IPv6 traffic.
+   The second is the manner in which routers resolve names to IPv6
+   addresses.  Last but not least is the method in which clients
+   communicate with Tor to resolve and connect to IPv6 endpoints
+   anonymously.
+
+1.2. Router IPv6 exit support
+
+   In order to specify exit policies and IPv6 capability new directives
+   in the Tor configuration will be needed.  If a router advertises IPv6
+   exit policies in its descriptor this will signal the ability to
+   provide IPv6 exit.  There are a number of additional default deny
+   rules associated with this new address space which are detailed in
+   the addendum.
+
+   When Tor is started on a host it should check for the presence of a
+   global unicast IPv6 address and if present include the default IPv6
+   exit policies and any user specified IPv6 exit policies.
+
+   If a user provides IPv6 exit policies but no global unicast IPv6
+   address is available Tor should generate a warning and not publish the
+   IPv6 policies in the router descriptor.
+
+   It should be noted that IPv4 mapped IPv6 addresses are not valid exit
+   destinations.  This mechanism is mainly used to interoperate with
+   both IPv4 and IPv6 clients on the same socket.  Any attempts to use
+   an IPv4 mapped IPv6 address, perhaps to circumvent exit policy for
+   IPv4, must be refused.
+
+1.3. DNS name resolution of IPv6 addresses (AAAA records)
+
+   In addition to exit support for IPv6 TCP connections, a method to
+   resolve domain names to their respective IPv6 addresses is also
+   needed.  This is accomplished in the existing DNS system via AAAA
+   records.  Routers will perform both A and AAAA requests when
+   resolving a name so that the client can utilize an IPv6 endpoint when
+   available or preferred.
+
+   To avoid potential problems with caching DNS servers that behave
+   poorly all NXDOMAIN responses to AAAA requests should be ignored if a
+   successful response is received for an A request.  This implies that
+   both AAAA and A requests will always be performed for each name
+   resolution.
+
+   For reverse lookups on IPv6 addresses, like that used for
+   RESOLVE_PTR, Tor will perform the necessary PTR requests via
+   IP6.ARPA.
+
+   All routers which perform DNS resolution on behalf of clients
+   (RELAY_RESOLVE) should perform and respond with both A and AAAA
+   resources.
+
+1.4. Client interaction with IPv6 exit capability
+
+1.4.1. Usability goals
+
+   There are a number of behaviors which Tor can provide when
+   interacting with clients that will improve the usability of IPv6 exit
+   capability.  These behaviors are designed to make it simple for
+   clients to express a preference for IPv6 transport and utilize IPv6
+   host services.
+
+1.4.2. SOCKSv5 IPv6 client behavior
+
+   The SOCKS version 5 protocol supports IPv6 connections.  When using
+   SOCKSv5 with hostnames it is difficult to determine if a client
+   wishes to use an IPv4 or IPv6 address to connect to the desired host
+   if it resolves to both address types.
+
+   In order to make this more intuitive the SOCKSv5 protocol can be
+   supported on a local IPv6 endpoint, [::1] port 9050 for example.
+   When a client requests a connection to the desired host via an IPv6
+   SOCKS connection Tor will prefer IPv6 addresses when resolving the
+   host name and connecting to the host.
+
+   Likewise, RESOLVE and RESOLVE_PTR requests from an IPv6 SOCKS
+   connection will return IPv6 addresses when available, and fall back
+   to IPv4 addresses if not.
+
+1.4.3. MAPADDRESS behavior
+
+   The MAPADDRESS capability supports clients that may not be able to
+   use the SOCKSv4a or SOCKSv5 hostname support to resolve names via
+   Tor.  This ability should be extended to IPv6 addresses in SOCKSv5 as
+   well.
+
+   When a client requests an address mapping from the wildcard IPv6
+   address, [::0], the server will respond with a unique local IPv6
+   address on success.  It is important to note that there may be two
+   mappings for the same name if both an IPv4 and IPv6 address are
+   associated with the host.  In this case a CONNECT to a mapped IPv6
+   address should prefer IPv6 for the connection to the host, if
+   available, while CONNECT to a mapped IPv4 address will prefer IPv4.
+
+   It should be noted that IPv6 does not provide the concept of a host
+   local subnet, like 127.0.0.0/8 in IPv4.  For this reason integration
+   of Tor with IPv6 clients should consider a firewall or filter rule to
+   drop unique local addresses to or from the network when possible.
+   These packets should not be routed, however, keeping them off the
+   subnet entirely is worthwhile.
+
+1.4.3.1. Generating unique local IPv6 addresses
+
+   The usual manner of generating a unique local IPv6 address is to
+   select a Global ID part randomly, along with a Subnet ID, and sharing
+   this prefix among the communicating parties who each have their own
+   distinct Interface ID.  In this style a given Tor instance might
+   select a random Global and Subnet ID and provide MAPADDRESS
+   assignments with a random Interface ID as needed.  This has the
+   potential to associate unique Global/Subnet identifiers with a given
+   Tor instance and may expose attacks against the anonymity of Tor
+   users.
+
+   Tor avoid this potential problem entirely MAPADDRESS must always
+   generate the Global, Subnet, and Interface IDs randomly for each
+   request.  It is also highly suggested that explicitly specifying an
+   IPv6 source address instead of the wildcard address not be supported
+   to ensure that a good random address is used.
+
+1.4.4. DNSProxy IPv6 client behavior
+
+   A new capability in recent Tor versions is the transparent DNS proxy.
+   This feature will need to return both A and AAAA resource records
+   when responding to client name resolution requests.
+
+   The transparent DNS proxy should also support reverse lookups for
+   IPv6 addresses.  It is suggested that any such requests to the
+   deprecated IP6.INT domain should be translated to IP6.ARPA instead.
+   This translation is not likely to be used and is of low priority.
+
+   It would be nice to support DNS over IPv6 transport as well, however,
+   this is not likely to be used and is of low priority.
+
+1.4.5. TransPort IPv6 client behavior
+
+   Tor also provides transparent TCP proxy support via the Trans*
+   directives in the configuration.  The TransListenAddress directive
+   should accept an IPv6 address in addition to IPv4 so that IPv6 TCP
+   connections can be transparently proxied.
+
+1.5. Additional changes
+
+   The RedirectExit option should be deprecated rather than extending
+   this feature to IPv6.
+
+
+2. Spec changes
+
+2.1. Tor specification
+
+   In '6.2. Opening streams and transferring data' the following should
+   be changed to indicate IPv6 exit capability:
+
+      "No version of Tor currently generates the IPv6 format."
+
+   In '6.4. Remote hostname lookup' the following should be updated to
+   reflect use of ip6.arpa in addition to in-addr.arpa.
+
+      "For a reverse lookup, the OP sends a RELAY_RESOLVE cell containing an
+       in-addr.arpa address."
+
+   In 'A.1. Differences between spec and implementation' the following
+   should be updated to indicate IPv6 exit capability:
+
+      "The current codebase has no IPv6 support at all."
+
+2.2. Directory specification
+
+   In '2.1. Router descriptor format' a new set of directives is needed
+   for IPv6 exit policy.  The existing accept/reject directives should
+   be clarified to indicate IPv4 or wildcard address relevance.  The new
+   IPv6 directives will be in the form of:
+
+      "accept6" exitpattern NL
+      "reject6" exitpattern NL
+
+   The section describing accept6/reject6 should explain that the
+   presence of accept6 or reject6 exit policies in a router descriptor
+   signals the ability of that router to exit IPv6 traffic (according to
+   IPv6 exit policies).
+
+   The "[::]/0" notation is used to represent "all IPv6 addresses".
+   "[::0]/0" may also be used for this representation.
+
+   If a user specifies a 'reject6 [::]/0:*' policy in the Tor
+   configuration this will be interpreted as forcing no IPv6 exit
+   support and no accept6/reject6 policies will be included in the
+   published descriptor.  This will prevent IPv6 exit if the router host
+   has a global unicast IPv6 address present.
+
+   It is important to note that a wildcard address in an accept or
+   reject policy applies to both IPv4 and IPv6 addresses.
+
+2.3. Control specification
+
+   In '3.8. MAPADDRESS' the potential to have to addresses for a given
+   name should be explained.  The method for generating unique local
+   addresses for IPv6 mappings needs explanation as described above.
+
+   When IPv6 addresses are used in this document they should include the
+   brackets for consistency.  For example, the null IPv6 address should
+   be written as "[::0]" and not "::0".  The control commands will
+   expect the same syntax as well.
+
+   In '3.9. GETINFO' the "address" command should return both public
+   IPv4 and IPv6 addresses if present.  These addresses should be
+   separated via \r\n.
+
+
+2.4. Tor SOCKS extensions
+
+   In '2. Name lookup' a description of IPv6 address resolution is
+   needed for SOCKSv5 as described above.  IPv6 addresses should be
+   supported in both the RESOLVE and RESOLVE_PTR extensions.
+
+   A new section describing the ability to accept SOCKSv5 clients on a
+   local IPv6 address to indicate a preference for IPv6 transport as
+   described above is also needed.  The behavior of Tor SOCKSv5 proxy
+   with an IPv6 preference should be explained, for example, preferring
+   IPv6 transport to a named host with both IPv4 and IPv6 addresses
+   available (A and AAAA records).
+
+
+3. Questions and concerns
+
+3.1. DNS A6 records
+
+   A6 is explicitly avoided in this document.  There are potential
+   reasons for implementing this, however, the inherent complexity of
+   the protocol and resolvers make this unappealing.  Is there a
+   compelling reason to consider A6 as part of IPv6 exit support?
+
+3.2. IPv4 and IPv6 preference
+
+   The design above tries to infer a preference for IPv4 or IPv6
+   transport based on client interactions with Tor.  It might be useful
+   to provide more explicit control over this preference.  For example,
+   an IPv4 SOCKSv5 client may want to use IPv6 transport to named hosts
+   in CONNECT requests while the current implementation would assume an
+   IPv4 preference.  Should more explicit control be available, through
+   either configuration directives or control commands?
+
+   Many applications support a inet6-only or prefer-family type option
+   that provides the user manual control over address preference.  This
+   could be provided as a Tor configuration option.
+
+   An explicit preference is still possible by resolving names and then
+   CONNECTing to an IPv4 or IPv6 address as desired, however, not all
+   client applications may have this option available.
+
+3.3. Support for IPv6 only transparent proxy clients
+
+   It may be useful to support IPv6 only transparent proxy clients using
+   IPv4 mapped IPv6 like addresses.  This would require transparent DNS
+   proxy using IPv6 transport and the ability to map A record responses
+   into IPv4 mapped IPv6 like addresses in the manner described in the
+   "NAT-PT" RFC for a traditional Basic-NAT-PT with DNS-ALG.  The
+   transparent TCP proxy would thus need to detect these mapped addresses
+   and connect to the desired IPv4 host.
+
+   The IPv6 prefix used for this purpose must not be the actual IPv4
+   mapped IPv6 address prefix, though the manner in which IPv4 addresses
+   are embedded in IPv6 addresses would be the same.
+
+   The lack of any IPv6 only hosts which would use this transparent proxy
+   method makes this a lot of work for very little gain.  Is there a
+   compelling reason to support this NAT-PT like capability?
+
+3.4. IPv6 DNS and older Tor routers
+
+   It is expected that many routers will continue to run with older
+   versions of Tor when the IPv6 exit capability is released.  Clients
+   who wish to use IPv6 will need to route RELAY_RESOLVE requests to the
+   newer routers which will respond with both A and AAAA resource
+   records when possible.
+
+   One way to do this is to route RELAY_RESOLVE requests to routers with
+   IPv6 exit policies published, however, this would not utilize current
+   routers that can resolve IPv6 addresses even if they can't exit such
+   traffic.
+
+   There was also concern expressed about the ability of existing clients
+   to cope with new RELAY_RESOLVE responses that contain IPv6 addresses.
+   If this breaks backward compatibility, a new request type may be
+   necessary, like RELAY_RESOLVE6, or some other mechanism of indicating
+   the ability to parse IPv6 responses when making the request.
+
+3.5. IPv4 and IPv6 bindings in MAPADDRESS
+
+   It may be troublesome to try and support two distinct address mappings
+   for the same name in the existing MAPADDRESS implementation.  If this
+   cannot be accommodated then the behavior should replace existing
+   mappings with the new address regardless of family.  A warning when
+   this occurs would be useful to assist clients who encounter problems
+   when both an IPv4 and IPv6 application are using MAPADDRESS for the
+   same names concurrently, causing lost connections for one of them.
+
+4. Addendum
+
+4.1. Sample IPv6 default exit policy
+
+   reject 0.0.0.0/8
+   reject 169.254.0.0/16
+   reject 127.0.0.0/8
+   reject 192.168.0.0/16
+   reject 10.0.0.0/8
+   reject 172.16.0.0/12
+   reject6 [0000::]/8
+   reject6 [0100::]/8
+   reject6 [0200::]/7
+   reject6 [0400::]/6
+   reject6 [0800::]/5
+   reject6 [1000::]/4
+   reject6 [4000::]/3
+   reject6 [6000::]/3
+   reject6 [8000::]/3
+   reject6 [A000::]/3
+   reject6 [C000::]/3
+   reject6 [E000::]/4
+   reject6 [F000::]/5
+   reject6 [F800::]/6
+   reject6 [FC00::]/7
+   reject6 [FE00::]/9
+   reject6 [FE80::]/10
+   reject6 [FEC0::]/10
+   reject6 [FF00::]/8
+   reject *:25
+   reject *:119
+   reject *:135-139
+   reject *:445
+   reject *:1214
+   reject *:4661-4666
+   reject *:6346-6429
+   reject *:6699
+   reject *:6881-6999
+   accept *:*
+   # accept6 [2000::]/3:* is implied
+
+4.2. Additional resources
+
+   'DNS Extensions to Support IP Version 6'
+   http://www.ietf.org/rfc/rfc3596.txt
+
+   'DNS Extensions to Support IPv6 Address Aggregation and Renumbering'
+   http://www.ietf.org/rfc/rfc2874.txt
+
+   'SOCKS Protocol Version 5'
+   http://www.ietf.org/rfc/rfc1928.txt
+
+   'Unique Local IPv6 Unicast Addresses'
+   http://www.ietf.org/rfc/rfc4193.txt
+
+   'INTERNET PROTOCOL VERSION 6 ADDRESS SPACE'
+   http://www.iana.org/assignments/ipv6-address-space
+
+   'Network Address Translation - Protocol Translation (NAT-PT)'
+   http://www.ietf.org/rfc/rfc2766.txt

Modified: tor/branches/114-dist-storage/doc/tor.1.in
===================================================================
--- tor/branches/114-dist-storage/doc/tor.1.in	2007-08-26 19:30:57 UTC (rev 11278)
+++ tor/branches/114-dist-storage/doc/tor.1.in	2007-08-26 21:03:54 UTC (rev 11279)
@@ -166,10 +166,23 @@
 If this option is set to 1, don't allow any connections on the control port
 except when the connecting process knows the contents of a file named
 "control_auth_cookie", which Tor will create in its data directory.  This
-authentication methods should only be used on systems with good filesystem
+authentication method should only be used on systems with good filesystem
 security. (Default: 0)
 .LP
 .TP
+\fBCookieAuthFile \fR\fIPath\fP
+If set, this option overrides the default location and file name for Tor's
+cookie file.  (See CookieAuthentication above.)
+.LP
+.TP
+\fBCookieAuthFileGroupReadable \fR\fB0\fR|\fB1\R|\fIGroupName\fP
+If this option is set to 0, don't allow the filesystem group to read
+the cookie file.  If the option is set to 1, make the cookie file
+readable by the default GID.  [Making the file readable by other
+groups is not yet implemented; let us know if you need this for some
+reason.]  (Default: 0).
+.LP
+.TP
 \fBDataDirectory \fR\fIDIR\fP
 Store working data in DIR (Default: @LOCALSTATEDIR@/lib/tor)
 .LP
@@ -958,6 +971,12 @@
 this. (Default: 0)
 .LP
 .TP
+\fBMinUptimeHidServDirectoryV2 \fR\fIN\fR \fBseconds\fR|\fBminutes\fR|\fBhours\fR|\fBdays\fR|\fBweeks\fP
+When this option is set in addition to \fBHSAuthoritativeDir\fP, Tor
+considers hidden service directories after the given time as feasible for
+storing and serving v2 rendezvous service descriptors. (Default: 24 hours)
+.LP
+.TP
 \fBHSAuthorityRecordStats \fR\fB0\fR|\fB1\fR\fP
 When this option is set in addition to \fBHSAuthoritativeDir\fP, Tor
 periodically (every 15 minutes) writes statistics about hidden service
@@ -1186,7 +1205,10 @@
 .LP
 .TP
 .B \fIDataDirectory\fP/control_auth_cookie
-Used for cookie authentication with the controller. Regenerated on startup.  See control-spec.txt for details.  Only used when cookie authentication is enabled.
+Used for cookie authentication with the controller. Location can be
+overridden by the CookieAuthFile config option. Regenerated on startup.
+See control-spec.txt for details.  Only used when cookie authentication
+is enabled.
 .LP
 .TP
 .B \fIDataDirectory\fP/keys/*

Modified: tor/branches/114-dist-storage/src/common/crypto.c
===================================================================
--- tor/branches/114-dist-storage/src/common/crypto.c	2007-08-26 19:30:57 UTC (rev 11278)
+++ tor/branches/114-dist-storage/src/common/crypto.c	2007-08-26 21:03:54 UTC (rev 11279)
@@ -1144,48 +1144,77 @@
   return 0;
 }
 
-/** Encrypt <b>fromlen</b> bytes from <b>from</b> with the symmetric key
- * <b>key</b> of 16 bytes length to <b>to</b>. The length of <b>to</b> needs to
- * be the length of <b>from</b> plus 32 (up to 16 bytes for padding and exactly
- * 16 bytes for the initialization vector). On success, return the number of
- * bytes written, on failure, return -1.
+#define AES_CIPHER_BLOCK_SIZE (16)
+
+#define AES_IV_SIZE (16)
+
+/** Encrypt <b>fromlen</b> bytes (at least 1) from <b>from</b> with the
+ * symmetric key <b>key</b> of 16 bytes length to <b>to</b> of length
+ * <b>tolen</b> which needs to be <b>fromlen</b>, padded to the next 16
+ * bytes, plus exactly 16 bytes for the initialization vector. On success,
+ * return the number of bytes written, on failure, return -1.
  */
 int
-crypto_cipher_encrypt_cbc(char *key, char *to, const char *from,
+crypto_cipher_encrypt_cbc(char *key, char *to, size_t tolen, const char *from,
                           size_t fromlen)
 {
 
-  EVP_CIPHER_CTX ctx; /* cipher context */
-  unsigned char iv[16]; /* initialization vector */
+  EVP_CIPHER_CTX ctx_msg, ctx_iv; /* cipher contexts for message and IV */
+  unsigned char iv[AES_IV_SIZE]; /* initialization vector */
   int outlen, tmplen; /* length of encrypted strings (w/ and wo/ final data) */
 
   tor_assert(key);
   tor_assert(to);
+  tor_assert(tolen >= fromlen + AES_IV_SIZE +
+                    (AES_CIPHER_BLOCK_SIZE - fromlen % AES_CIPHER_BLOCK_SIZE));
   tor_assert(from);
-  tor_assert(fromlen);
+  tor_assert(fromlen > 0);
 
-  /* initialize cipher context */
-  EVP_CIPHER_CTX_init(&ctx);
+  /* generate random initialization vector */
+  crypto_rand((char *)iv, AES_IV_SIZE);
 
-  /* generate random initialization vector and write it to the first 16 bytes
-   * of the result*/
-  crypto_rand((char *)iv, 16);
-  memcpy((unsigned char *)to, iv, 16);
+  /* initialize cipher context for the initialization vector */
+  EVP_CIPHER_CTX_init(&ctx_iv);
 
+  /* set up cipher context for the initialization vector for encryption with
+   * cipher type AES-128 in ECB mode, default implementation, given key, and
+   * no initialization vector */
+  EVP_EncryptInit_ex(&ctx_iv, EVP_aes_128_ecb(), NULL, (unsigned char *)key,
+                     NULL);
+
+  /* encrypt initialization vector (no padding necessary) and write it to the
+   * first 16 bytes of the result */
+  if (!EVP_EncryptUpdate(&ctx_iv, (unsigned char *)to, &outlen, iv,
+                         AES_IV_SIZE)) {
+    crypto_log_errors(LOG_WARN, "encrypting initialization vector");
+    return -1;
+  }
+
+  /* clear all information from cipher context for the initialization vector
+   * and free up any allocated memory associate with it */
+  EVP_CIPHER_CTX_cleanup(&ctx_iv);
+
+  /* initialize cipher context for the message */
+  EVP_CIPHER_CTX_init(&ctx_msg);
+
   /* set up cipher context for encryption with cipher type AES-128 in CBC mode,
    * default implementation, given key, and initialization vector */
-  EVP_EncryptInit_ex(&ctx, EVP_aes_128_cbc(), NULL, (unsigned char *)key, iv);
+  EVP_EncryptInit_ex(&ctx_msg, EVP_aes_128_cbc(), NULL, (unsigned char *)key,
+                     iv);
 
   /* encrypt fromlen bytes from buffer from and write the encrypted version to
    * buffer to */
-  if (!EVP_EncryptUpdate(&ctx, ((unsigned char *)to) + 16, &outlen,
+  if (!EVP_EncryptUpdate(&ctx_msg,
+                        ((unsigned char *)to) + AES_IV_SIZE, &outlen,
                         (const unsigned char *)from, (int)fromlen)) {
     crypto_log_errors(LOG_WARN, "encrypting");
     return -1;
   }
 
   /* encrypt the final data */
-  if (!EVP_EncryptFinal_ex(&ctx, ((unsigned char *)to)+16+outlen, &tmplen)) {
+  if (!EVP_EncryptFinal_ex(&ctx_msg,
+                        ((unsigned char *)to) + AES_IV_SIZE + outlen,
+                        &tmplen)) {
     crypto_log_errors(LOG_WARN, "encrypting the final data");
     return -1;
   }
@@ -1193,52 +1222,73 @@
 
   /* clear all information from cipher context and free up any allocated memory
    * associate with it */
-  EVP_CIPHER_CTX_cleanup(&ctx);
+  EVP_CIPHER_CTX_cleanup(&ctx_msg);
 
   /* return number of written bytes */
-  return outlen + 16;
+  return outlen + AES_IV_SIZE;
 }
 
-/** Decrypt <b>fromlen</b> bytes from <b>from</b> with the symmetric key
- * <b>key</b> of 16 bytes length to <b>to</b>. The length of <b>to</b> may be
- * the length of <b>from</b> minus 16 (up to 16 bytes for padding and exactly
- * 16 bytes for the initialization vector). On success, return the number of
- * bytes written, on failure (including providing the wrong key), return -1.
+/** Decrypt <b>fromlen</b> bytes (at least 1) from <b>from</b> with the
+ * symmetric key <b>key</b> of 16 bytes length to <b>to</b> of length
+ * <b>tolen</b> which may be <b>fromlen</b> minus 16 for the initialization
+ * vector (the size of padding cannot be determined in advance). On success,
+ * return the number of bytes written, on failure (including providing the
+ * wrong key), return -1.
  */
 int
-crypto_cipher_decrypt_cbc(char *key, char *to, const char *from,
+crypto_cipher_decrypt_cbc(char *key, char *to, size_t tolen, const char *from,
                           size_t fromlen)
 {
-  EVP_CIPHER_CTX ctx; /* cipher context */
-  unsigned char iv[16]; /* initialization vector */
+  EVP_CIPHER_CTX ctx_msg, ctx_iv; /* cipher contexts for message and IV */
+  unsigned char iv[AES_IV_SIZE]; /* initialization vector */
   int outlen, tmplen; /* length of decrypted strings (w/ and wo/ final data) */
 
   tor_assert(key);
   tor_assert(to);
+  tor_assert(tolen >= fromlen - AES_IV_SIZE);
   tor_assert(from);
-  tor_assert(fromlen);
+  tor_assert(fromlen > 0);
 
-  /* initialize cipher contex */
-  EVP_CIPHER_CTX_init(&ctx);
+  /* initialize cipher context for the initialization vector */
+  EVP_CIPHER_CTX_init(&ctx_iv);
 
-  /* copy initialization vector from buffer */
-  memcpy(iv, (unsigned const char *)from, 16);
+  /* set up cipher context for the initialization vector for decryption with
+   * cipher type AES-128 in ECB mode, default implementation, given key, and
+   * no initialization vector */
+  EVP_DecryptInit_ex(&ctx_iv, EVP_aes_128_ecb(), NULL, (unsigned char *)key,
+                     NULL);
 
+  /* decrypt initialization vector (is not padded) */
+  if (!EVP_DecryptUpdate(&ctx_iv, iv, &outlen, (const unsigned char *)from,
+                         AES_IV_SIZE)) {
+    crypto_log_errors(LOG_WARN, "decrypting initialization vector");
+    return -1;
+  }
+
+  /* clear all information from cipher context for the initialization vector
+   * and free up any allocated memory associate with it */
+  EVP_CIPHER_CTX_cleanup(&ctx_iv);
+
+  /* initialize cipher context for the message */
+  EVP_CIPHER_CTX_init(&ctx_msg);
+
   /* set up cipher context for decryption with cipher type AES-128 in CBC mode,
    * default implementation, given key, and initialization vector */
-  EVP_DecryptInit_ex(&ctx, EVP_aes_128_cbc(), NULL, (unsigned char *)key, iv);
+  EVP_DecryptInit_ex(&ctx_msg, EVP_aes_128_cbc(), NULL, (unsigned char *)key,
+                     iv);
 
   /* decrypt fromlen-16 bytes from buffer from and write the decrypted version
    * to buffer to */
-  if (!EVP_DecryptUpdate(&ctx, (unsigned char *)to, &outlen,
-                        ((const unsigned char *)from) + 16,
-                        (int)fromlen - 16)) {
+  if (!EVP_DecryptUpdate(&ctx_msg, (unsigned char *)to, &outlen,
+                        ((const unsigned char *)from) + AES_IV_SIZE,
+                        (int)fromlen - AES_IV_SIZE)) {
     crypto_log_errors(LOG_INFO, "decrypting");
     return -1;
   }
 
   /* decrypt the final data */
-  if (!EVP_DecryptFinal_ex(&ctx, ((unsigned char *)to) + outlen, &tmplen)) {
+  if (!EVP_DecryptFinal_ex(&ctx_msg, ((unsigned char *)to) + outlen,
+                           &tmplen)) {
     crypto_log_errors(LOG_INFO, "decrypting the final data");
     return -1;
   }
@@ -1246,7 +1296,7 @@
 
   /* clear all information from cipher context and free up any allocated memory
    * associate with it */
-  EVP_CIPHER_CTX_cleanup(&ctx);
+  EVP_CIPHER_CTX_cleanup(&ctx_msg);
 
   /* return number of written bytes */
   return outlen;

Modified: tor/branches/114-dist-storage/src/common/crypto.h
===================================================================
--- tor/branches/114-dist-storage/src/common/crypto.h	2007-08-26 19:30:57 UTC (rev 11278)
+++ tor/branches/114-dist-storage/src/common/crypto.h	2007-08-26 21:03:54 UTC (rev 11279)
@@ -124,10 +124,10 @@
 int crypto_cipher_decrypt(crypto_cipher_env_t *env, char *to,
                           const char *from, size_t fromlen);
 
-int crypto_cipher_encrypt_cbc(char *key, char *to, const char *from,
-                              size_t fromlen);
-int crypto_cipher_decrypt_cbc(char *key, char *to, const char *from,
-                              size_t fromlen);
+int crypto_cipher_encrypt_cbc(char *key, char *to, size_t tolen,
+                              const char *from, size_t fromlen);
+int crypto_cipher_decrypt_cbc(char *key, char *to, size_t tolen,
+                              const char *from, size_t fromlen);
 
 /* SHA-1 */
 int crypto_digest(char *digest, const char *m, size_t len);

Modified: tor/branches/114-dist-storage/src/or/config.c
===================================================================
--- tor/branches/114-dist-storage/src/or/config.c	2007-08-26 19:30:57 UTC (rev 11278)
+++ tor/branches/114-dist-storage/src/or/config.c	2007-08-26 21:03:54 UTC (rev 11279)
@@ -204,6 +204,8 @@
   VAR("MaxAdvertisedBandwidth",MEMUNIT,MaxAdvertisedBandwidth,"1 GB"),
   VAR("MaxCircuitDirtiness", INTERVAL, MaxCircuitDirtiness,  "10 minutes"),
   VAR("MaxOnionsPending",    UINT,     MaxOnionsPending,     "100"),
+  VAR("MinUptimeHidServDirectoryV2", INTERVAL, MinUptimeHidServDirectoryV2,
+                                                             "24 hours"),
   OBSOLETE("MonthlyAccountingStart"),
   VAR("MyFamily",            STRING,   MyFamily,             NULL),
   VAR("NewCircuitPeriod",    INTERVAL, NewCircuitPeriod,     "30 seconds"),
@@ -2780,6 +2782,12 @@
     return -1;
   }
 
+  if (options->MinUptimeHidServDirectoryV2 < 0) {
+    log_warn(LD_CONFIG, "MinUptimeHidServDirectoryV2 option must be at least "
+                        "0 seconds. Changing to 0.");
+    options->MinUptimeHidServDirectoryV2 = 0;
+  }
+
   if (options->RendPostPeriod < MIN_REND_POST_PERIOD) {
     log(LOG_WARN,LD_CONFIG,"RendPostPeriod option must be at least %d seconds."
         " Clipping.", MIN_REND_POST_PERIOD);

Modified: tor/branches/114-dist-storage/src/or/directory.c
===================================================================
--- tor/branches/114-dist-storage/src/or/directory.c	2007-08-26 19:30:57 UTC (rev 11278)
+++ tor/branches/114-dist-storage/src/or/directory.c	2007-08-26 21:03:54 UTC (rev 11279)
@@ -2115,7 +2115,6 @@
           write_http_response_header(conn, strlen(descp), "text/plain",
                                      NULL, 0);
           connection_write_to_buf(descp, strlen(descp), TO_CONN(conn));
-          tor_free(descp);
           break;
         case 0: /* well-formed but not present */
           write_http_status_line(conn, 404, "Not found");
@@ -2741,6 +2740,8 @@
   routerstatus_t *pred_status;
   local_routerstatus_t *succ_router;
   routerstatus_t *succ_status;
+  /* To be sure, update routing table. */
+  update_hs_dir_routing_table();
   /* Check if I am acting as hidden service directory and there are enough
    * other hidden service directories available; otherwise there is no
    * replication necessary/possible. */
@@ -2755,7 +2756,17 @@
     predecessor0 = predecessor1;
     predecessor1 = previous_hs_dir(predecessor0);
     pred_router = router_get_combined_status_by_digest(predecessor0);
+    if (!pred_router) {
+      log_warn(LD_REND, "Did not find combined status for router. "
+                        "Skipping router for replication.");
+      continue;
+    }
     pred_status = &(pred_router->status);
+    if (!pred_status) {
+      log_warn(LD_REND, "Could not determine router status. "
+                        "Skipping router for replication.");
+      continue;
+    }
     base32_encode(from_id_base32, REND_DESC_ID_V2_LEN + 1, predecessor1,
                   DIGEST_LEN);
     base32_encode(to_id_base32, REND_DESC_ID_V2_LEN + 1, predecessor0,
@@ -2770,19 +2781,29 @@
    * NUMBER_OF_CONSECUTIVE_REPLICAS - 1 successors. */
   direct_predecessor = previous_hs_dir(me);
   successor = next_hs_dir(me);
-  for (i = 0; i < NUMBER_OF_CONSECUTIVE_REPLICAS - 1; i++) {
+  for (i = 0; i < NUMBER_OF_CONSECUTIVE_REPLICAS - 1;
+       i++, successor = next_hs_dir(successor)) {
     succ_router = router_get_combined_status_by_digest(successor);
+    if (!succ_router) {
+      log_warn(LD_REND, "Did not find combined status for router. "
+                        "Skipping router for replication.");
+      continue;
+    }
     succ_status = &(succ_router->status);
-    base32_encode(from_id_base32, REND_DESC_ID_V2_LEN + 1, direct_predecessor,
-                  DIGEST_LEN);
-    base32_encode(to_id_base32, REND_DESC_ID_V2_LEN + 1, me,
-                  DIGEST_LEN);
+    if (!succ_status) {
+      log_warn(LD_REND, "Could not determine router status. "
+                        "Skipping router for replication.");
+      continue;
+    }
+    base32_encode(from_id_base32, REND_DESC_ID_V2_LEN + 1,
+                  direct_predecessor, DIGEST_LEN);
+    base32_encode(to_id_base32, REND_DESC_ID_V2_LEN + 1,
+                  me, DIGEST_LEN);
     log_debug(LD_REND, "Requesting descriptors in interval %s to %s for "
                        "which I am primarily responsible from successor.",
              from_id_base32,
              to_id_base32);
     hs_dir_fetch_replicas(succ_status, from_id_base32, to_id_base32);
-    successor = next_hs_dir(successor);
   }
   /* Clean up descriptors for which I am not reponsible (neither primarily
    * nor for replication). */

Modified: tor/branches/114-dist-storage/src/or/dirserv.c
===================================================================
--- tor/branches/114-dist-storage/src/or/dirserv.c	2007-08-26 19:30:57 UTC (rev 11278)
+++ tor/branches/114-dist-storage/src/or/dirserv.c	2007-08-26 21:03:54 UTC (rev 11279)
@@ -1551,7 +1551,7 @@
   int uptime = real_uptime(router, now);
 
   return (router->wants_to_be_hs_dir &&
-          (unsigned)uptime > MIN_UPTIME_HS_DIR &&
+          uptime > get_options()->MinUptimeHidServDirectoryV2 &&
           ((router_is_me(router) && !we_are_hibernating()) ||
            (now < router->last_reachable + HS_DIR_REACHABLE_TIMEOUT)));
 }

Modified: tor/branches/114-dist-storage/src/or/or.h
===================================================================