- tor-dev - lists.torproject.org

Size issues with Orbot statically linking OpenSSL
by Nathan Freitas 17 Jan '12

17 Jan '12

With the recent problems related to SSLv3 with versions of OpenSSL less than 1.0.0f, we have been investigating how to deal with this on Android for Orbot. Historically, we have used the version of OpenSSL provided by the Android device itself, which has ranged from 0.9.8 to 1.0.0e (the latest on ICS 4.0). We have now produced a build of OpenSSL 1.0.0f with the necessary Android patches, and statically linked this into the Tor binary we ship inside of Orbot. (We already do this for LibEvent, since that is not included in Android itself). With both OpenSSL and LibEvent linked, the Tor binary increases from 3MB to about 8MB. 8MB is not terrible, but once you include the Orbot app, Privoxy and other files, we are getting into the 10MB+ range. I think this is all fine, and we can enable users to run the app from a secured partition on their external storage, but I did just want to run this by all of you to see if there are any options for limiting the size of libssl.a and libcrypto.a, and the resulting Tor binary. Thx! +n8fr8

4 6

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

16 Jan '12

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

8 29

Sanitizing IPv6 addresses in bridge descriptors
by Karsten Loesing 16 Jan '12

16 Jan '12

Hi Linus, Ian, list, now that we have bridges running on IPv6 addresses, some bridge operators enabled that feature on their public bridges and published descriptors to the bridge authority. I wonder how to sanitize these addresses for metrics data. (Currently, lines containing IPv6 addresses are simply discarded in the sanitized output.) Here's how we sanitize IPv4 addresses (from https://metrics.torproject.org/formats.html#bridgedesc) > Replace IP address with IP address hash: Of course, the IP address > needs to be removed, too. It is replaced with 10.x.x.x with x.x.x > being the 3 byte output of H(IP address | bridge identity | > secret)[:3]. The input IP address is the 4-byte long binary > representation of the bridge's current IP address. The bridge > identity is the 20-byte long binary representation of the bridge's > long-term identity fingerprint. The secret is a 31-byte long secure > random string that changes once per month for all descriptors and > statuses published in that month. H() is SHA-256. The [:3] operator > means that we pick the 3 most significant bytes of the result. The idea is that it should be hard to derive the original IPv6 address from the sanitized address. At the same time it should be easy to notice whether the address of a given bridge has changed within the same month. Here's my plan for IPv6 addresses: - Shorter secret: For the hash function input, use the 16 byte long binary representation of the bridge's current IP address, the 20 bytes of the fingerprint, but only a 19 byte long secure random string that changes once per month. The idea is to keep the input to one SHA block (447 bits) as suggested by Ian on January 2, 2011 on this list: (16 + 20 + 19) * 8 = 440. - Alternative to shorter secret: Use the same 31 byte long secret and live with the fact that the hash input now spans two SHA blocks. Maybe use a 75 byte long secret to have an input of two SHA blocks. - Write 3 bytes of the sanitized IPv6 address in [::] notation. We're writing sanitized IPv4 addresses as 10.x.x.x. Is there a counterpart for IPv6 addresses? It should be obvious that these are "private" addresses, but I'd like to keep the notation unchanged to keep parsing tools simple. - Alternative to using 3 bytes: Should we use fewer or more bytes from the SHA-256 output for IPv6 addresses? Thanks, Karsten

3 5

Transitioning to new crypto (again, but with substance)
by Watson Ladd 14 Jan '12

14 Jan '12

Dear all, After thinking hard about the issues involved with new cryptography in Tor I came to the following idea for a somewhat reasonable upgrade path for OP's and OR's that preserves everyone's privacy and security at all points (to the extent that this is possible: new connections are by new clients). The only issue is what actually goes out on the wire needs to be though through. First note that the connection between the identity used to ensure EXTEND cells go over canonical connections and the keys actually presented by two OR's that have formed a connection can be pretty much arbitrary: it isn't necessary for the client to know what it is. So we could have each OR have an identity key that stays 1024 bit RSA for old ORs while newer ORs trust some snazzy new elliptic curve key, while using the same 1024 bits to form the identity. Note that if we use elliptic curves to secure the endpoints,(and don't mind incompatibility with old clients) the RSA key doesn't even need to be an RSA key. Also note that the Tor directory spec permits new types of lines. In particular we could have a curve-ident-key line and a curve-onionkey line each containing base-64 encoded keys, and a curve-sig line that's a signature of the rest of the entry, except for the RSA signature. The RSA signature would be as normal. To an old client this looks exactly like an old style directory entry. To a new client this looks like the elliptic curve key is the root of trust. This is OK: fiddling with an RSA signature doesn't let you fool a new client into thinking things about identities, because the identity is derived from the RSA key which is signed with the curve-ident-key. The onion-key is trusted by both the curve-ident-key and the RSA identity key. It is still possible to selectively invalidate one signature, but that signature is the RSA signature: the curve-ident-signature is also covered by the RSA signature. This would have the effect of ensuring that only new clients can connect to the OR: we could require that new clients still check the RSA signature to prevent this. Lastly comes the problem of EXTEND cells. All the OR before the new extension has to do is copy what is given to it without caring about the version. To signal versions we can just use length: 64 bytes vs. 128 bytes. Sadly this signals what version a client is, but an OR can guess anyway by how it was connected to if it lists both descriptors. One thing I have not taken on is the use of the new keys in the TLS negotiations.We could extend the CERTS and AUTH cells to include them as possible types, and this is possibly the best solution. I also haven't addressed the problem of UDP transport: TLS has issues where instead of sending another packet to be processed by the next router it resends a dropped packet, holding up the queue. I've probably missed a lot of issues here, but hopefully this moves the conversation forward. Sincerely, Watson Ladd

2 2

Extending deadline for small features in 0.2.3.x by one week (to the 13th)
by Nick Mathewson 11 Jan '12

11 Jan '12

Hi, all! Previously, I had set the deadline for merging small features into 0.2.3.x as Jan 6. Due to work that had piled up or suddenly appeared in the new year, I wasn't able to get patches reviewed this week as much as I wanted, so I'm going to push the small-feature merge window back to Jan 13. This is the deadline for me to merge stuff, not for stuff to get submitted: I probably will not consider any patches where the first version is submitted after Monday, unless they are surprisingly tiny and obviously correct. Barring exceptional circumstances, any large features must wait for 0.2.4.x, as must any features that don't get merged by Friday. Once this window closes, only bugfixes will be okay for 0.2.3.x. As before, I'm going to leave the definitions of "exceptional", "large", and "feature" a little vague, and err on the side of getting a good 0.2.3.x release candidate done soon. happy hacking, -- Nick

3 5

A way to block chinese active probe
by Fabio Pietrosanti (naif) 09 Jan '12

09 Jan '12

Hi all, here's a second chinese-probe discrimination behavior that should allow to detect them, and block it. http://pastebin.com/RNcNDYcw Like the TCP SYN one, this blocking tricks is based on the fact that the OS & software they run on their server pool to make active-tor-probing have to be highly optimized, as they need to manage a huge amount of outbound connections. Does anyone would like to re-test this behaviour (also for Windows/OSX) and in case make a small patch for tor. Now i made testing with iptables && -j TARPIT . It would be nice to have in Tor a set of configurable Timeout? As any active probe present and future could have some timing issue, not being able to perfectly emulate the same conditions of a client, as active probes run on servers (and server get optimized if need to do high traffic). -naif

1 0

Re: [tor-dev] Browser-based proxies for circumvention
by Kevin Dyer 08 Jan '12

08 Jan '12

>>> A sample session goes like this: >>> 1. The user starts a connector and a Tor client. The connector sends its >>> address to the facilitator, so that a proxy will know where to >>> connect to. (We call this step "rendezvous.") >>> 2. A flash proxy appears in a browser and asks the facilitator for an >>> address. >>> 3. The facilitator sends a remembered client address to the proxy. >>> 4. The proxy connects to the client address. The client's connector >>> receives the connection. >>> 5. The proxy connects to a Tor relay, then begins copying data between >>> its two sockets. >> >> Where is the list of all facilitators? > > There is only one (not that there couldn't be more), and its address is > hardcoded into the proxy badge. I think I am confused about something: Why is it difficult for the censor to enumerate, and then block, the facilitators? -Kevin

2 1

Using a conf.d instead of a monolithic config file
by warms0x 07 Jan '12

07 Jan '12

I'm looking to start developing a Tor module for Puppet, one of the primary difficulties in making things work together "nicely" is the monolithic configuration file. Has there ever been plans or discussion about using a conf.d-style directory to store configuration file fragments? It would be useful to be able to drop fragments for hidden service configurations, etc into a directory to be picked up by the Tor daemon. If I provided the patches to make this possible, would it be useful? Cheers, -warms0x

2 1

DuckDuckGo, iOS and other stuff.
by caine tighe 03 Jan '12

03 Jan '12

tor-devers, So we are currently developing v2 of DDG applications and I'm personally interested in getting you guys involved. I think that there is serious value in ensuring Tor is an option for both Android and iOS. Currently we support Tor via Orbot on Android via the HTTP/S proxy method since the SOCKS method is known to have DNS leaks. Since the applications will be distributed via the respective stores, and specifically in the case of iOS, we cannot rely on the whole rooted / jailbroken methods. I understand that there is an application Covert Browser that claims to properly leverage Tor; however, since the source is closed, I remain unconvinced. This application stands to be both an interface to DuckDuckGo for quick and secure searching as well as a Tor enabled browser. We are always looking for other ways we can help, so let us know. I'd also like to discuss donation and a few other administration things off-list. respectfully, caine

2 1

OpenSSL v1.0.1-beta1 OK with Tor v0.2.2.35
by Steve Snyder 03 Jan '12

03 Jan '12

FYI, OpenSSL v1.0.1-beta1 seems to work fine when building and running Tor v0.2.2.35 (Linux/i686). Too early to say anything about performance (critical as the crypto is the performance bottleneck in Tor) but it definitely works as a drop-in replacement for OpenSSL v1.0.0e. http://marc.info/?l=openssl-announce&m=132338836402522&w=2

1 0