April 2011 - tor-dev - lists.torproject.org

Improved circuit-setup protocol [was: Re: Designing and implementing improved circuit-setup protocol [was: GSoC 2011]]
by Nick Mathewson 08 Apr '11

08 Apr '11

On Thu, Mar 31, 2011 at 5:52 AM, Robert Ransom <rransom.8774(a)gmail.com> wrote: Hi! I'm going to wait on a full review of your create/extend proposal till it's done, but I though I could potentially answer some questions and offer some comments: 1) I think CREATE cells need to get a field asking for a specific way of handling RELAY cells. If we ever update the relay crypto (that is, the stuff described in 5.5 and 6.1 today) to do something other than AES128_CTR for the encryption, SHA1 for the digest, we'll need a way to ask for it. I suppose that we could do that via adding a new handshake type for a new desired link protocol, but it seems like the two could be more or less orthogonal. 2) I don't get the rationale behind the variable-length type names. Elsewhere in our protocol we'd just use a 1- or 2-byte type field. Do we win a lot by letting these be longer? 3) By convention, everything in our protocol is in "network" (big-endian) byte-order. 4) There needs to be an authenticated way for the client to know which handshake types and link specifier types a given node supports. This could be as simple as a series of statements like "Tor versions xyz and later will support handshake type Y", or as complex as advertising them in router descriptors. 5) I like the idea of separating the link specifiers from the handshake type in EXTENDED cells. 6) I also think it'd be smart to figure out the actual link specifier and handshake types that we want to move to before we decide that we are confident that this format is right. Those can be a different proposal, though. 7) Here's a first cut of what I think might go in a link specifier format: * V4Address -- an ipv4 address, set to 0 if there is no IPv4 address for the node [4 bytes] * V4ORPort [2 bytes] * V6Address -- an ipv6 address, set to 0 if there is no IPv6 address for the node [16 bytes] * V6ORPort [2 bytes] * SHA256 of RSA1024 identity key [32 bytes] When we decide what longer identity keys should look like, we can add a new link specifier format that supports those. 8) This is totally back-of-the-envelope stuff, but it might be a good starting point for crypto discussion. Here's a first cut of what I think might go in an improved RSA handshake: * First 8 bytes of the SHA256 hash of the onion key [8 bytes] (This is here so that onion key rotation can work without having to sometimes try the wrong onion key incorrectly.) * PK-encrypted: * Padding [PK_PAD_LEN bytes] * SHA256 hash of all remaining fields. [32 bytes] * Symmetric key seed [16 bytes] * The first part of g^x. [as much will fit in the PK-encrypted portion] * Symmetrically encrypted: * The rest of g^x. * 0 bytes for padding. Here's a first cut of what I think might go in a hypothetical diffie-hellman based handshake, for use with something like Curve25519. (I'm using g^x and g^y notation here as if this were diffie-hellman in Z_p, since I don't yet trust myself to write ECC stuff correctly. I'm assuming that the node's public onion key is g^x.) * SHA256 of all remaining fields. [32 bytes] * First 8 bytes of the SHA256 hash of the onion key (8 bytes) * g^y1 [DH_LEN bytes] * Encrypted using a symmetric key based on g^(x*y1): * g^y2 [DH_LEN bytes] * 0 bytes for padding In both cases, we'll want a new key derivation function. yrs, -- Nick

4 7

[Patch] src/test.c
by Gisle Vanem 07 Apr '11

07 Apr '11

I don't think it's a good idea to use hard-coded paths. Even in a test source-file. Easy patch: --- Git-latest\src\test\test.c Wed Mar 30 11:58:28 2011 +++ src\test\test.c Thu Mar 31 14:06:14 2011 @@ -86,7 +86,7 @@ #ifdef MS_WINDOWS // XXXX tor_snprintf(temp_dir, sizeof(temp_dir), - "c:\\windows\\temp\\tor_test_%d", (int)getpid()); + "%s\\tor_test_%d", getenv("TEMP"), (int)getpid()); r = mkdir(temp_dir); #else tor_snprintf(temp_dir, sizeof(temp_dir), "/tmp/tor_test_%d", (int) getpid()); ---------- --gv

3 5

Embedding Parrot in Tor as GSoC Project
by Jonathan "Duke" Leto 07 Apr '11

07 Apr '11

Howdy, Parrot recently added a GSoC proposal idea to embed Parrot into Tor. It would be great to get the feedback from Tor developers. Also, this could be under the Parrot or the Tor GSoC project, whichever makes the most sense. The proposal idea could use more detail, but the high-level view that I imagine is: 1) Allow Parrot to talk to libtor (this will use NCI - Native Call Interface) via PIR 2) Ability to create Parrot interpreter objects from within Tor via C 3) Write glue code for a High Level Language (HLL) to talk to libtor There are various HLL's to choose from: Lua, TCL, Perl 6, Winxed, NQP and others. Duke Thanks for your help, Duke [0] http://trac.parrot.org/parrot/wiki/GSoc2011 -- Jonathan "Duke" Leto jonathan(a)leto.net http://leto.net

4 6

GSoC - Torbutton for Thunderbird
by Sukhbir Singh 05 Apr '11

05 Apr '11

Hi! I am interested in participating in Google's Summer of Code this year and implementing the Torbutton equivalent for Thunderbird [0]. I have been discussing the project with Mike Perry and we feel that it is possible to implement this. The first step was removing the hostname Thunderbird puts in the outgoing message header, which we easily fixed. That gave us the initial motivation to pursue this further. There are a number of issue that still remain, however we feel that those can be easily worked out. We have put all probable solutions to Torbutton requirements from [1] in the attachment with this mail and are looking for your suggestions/ comments about this. We have not submitted an application for this to Google yet; I intend to do that after gauging the response towards this proposal from the mailing list. Let's hope that we can make this a success, -- Thanks, Sukhbir Singh [0] - https://www.torproject.org/getinvolved/volunteer.html.en#torbuttonForThunde… [1] - https://www.torproject.org/torbutton/en/design/#requirements Attachment - Plain text

2 1

Torbutton for Thunderbird
by Sukhbir Singh 04 Apr '11

04 Apr '11

Hi! I am interested in participating in Google's Summer of Code this year and implementing the Torbutton equivalent for Thunderbird [0]. I have been discussing the project with Mike Perry and we feel that it is possible to implement this. The first step was removing the hostname Thunderbird puts in the outgoing message header, which we easily fixed. That gave us the initial motivation to pursue this further. There are a number of issue that still remain, however we feel that those can be easily worked out. We have put all probable solutions to Torbutton requirements from [1] in the attachment with this mail and are looking for your suggestions/ comments about this. We have not submitted an application for this to Google yet; I intend to do that after gauging the response towards this proposal from the mailing list. Let's hope that we can make this a success, -- Thanks, Sukhbir Singh [0] - https://www.torproject.org/getinvolved/volunteer.html.en#torbuttonForThunde… [1] - https://www.torproject.org/torbutton/en/design/#requirements Attachment - Plain text

1 0