tor-dev

tor-dev@lists.torproject.org

1 participants
3590 discussions

Alternatives to Tor Exit Enclaves
by Arturo Filastò 19 Apr '12

19 Apr '12

The purpose of Exit Enclaves was to allow people running a website to make Tor users access it without ever leaving the Tor network. This leads to the clients having end-to-end encryption with the target destination. Even in previous version this had some issues, one of which was the fact that at the first connection the user would not be accessing the destination over a Tor circuit if the destination was provided in a hostname format (and not IP). The current stable version of Tor (0.2.2.x) still supports Exit enclaves. The new versions of Tor (> 0.2.3.x) use a new descriptor format (microdescriptors) allow relays to specify an Exit Enclave policy, but clients will not use it, therefore voiding the purpose of exit enclaving. I believe there is the need for something similar to Tor Exit Enclaving and the closest thing I see fit these requirements are Tor Encrypted Services (https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-en…). Encrypted Services (EC), are basically regular Tor Hidden Services, that do not provide anonymity for the server and gain a better performance because of this (they have a one-hop circuit to the RV and IP). The problem with making Encrypted services work to replace Exit Enclaves is that the client needs to have a way to understand that their destination is running also as an Encrypted Service. In this very high level overview I don't go into very much detail of how this system will actually work, but I hope it will prompt some discussion on the matter. I think this can be achieved mainly in 3 ways. 1) The client already knows all of the EC's 2) The client looks up if a destination is an EC when trying to connect to it 3) The final hop looks up if the destination is an EC These all have some drawbacks: In 1) the client needs to download the full list of EC's, therefore if the number of EC's get's very large it will take clients much more to bootstrap and they will need to store more data. The good thing of this though is that the speed of connections would be as fast as they are at the moment as it does not require any extra connections. In 2) the clients needs to complete an extra round-trip for every connection. I don't think this is a valid solution as it would degrade the quality of connections for every user. In 3) the final hop would do along side a normal A lookup for hostnames a CNAME lookup ( or another special field). If it finds that such a lookup returns a .onion address instead of returning a RELAY_CONNECTED cell it will return a ENCRYPTED_SERVICE cell containing the .onion address of the target ES. The client will then cache this address and connect to it. This approach adds a little bit of overhead (since two DNS lookups need to be made), but it is still faster than 2). It suffers from the issue of the exit node could spoof the .onion address and redirect the user to a malicious .onion address. This is quite a tough problem that I am still unsure how it could be solved. If we have support for DNSSec this issue could be mitigated. I would love some feedback on this topic. - Art.

4 6

brdgrd: Protecting bridges from the GFC
by Philipp Winter 15 Apr '12

15 Apr '12

Hi, I've been working on a small tool whose purpose is to protect bridges from the Chinese firewall. The tool runs independently of Tor and analyzes/rewrites SYNs and SYN/ACKs which it gets with the help of libnetfilter_queue. It is quick and easy to set up and can be run by bridge operators. Basically, the tool achieves two things: - Evading the Chinese DPI engine by rewriting the TCP window size during the TCP handshake. This leads to a fragmented cipher list which does not seem to be recognized by the GFC. - Blocking scanners with two dirty hacks. I did not have a lot of time to test it yet but I've found the window size rewriting to be particularly effective (yet ugly). It worked with Windows {XP, 7} and recent Linux boxes. The scanner blocking strategies are not that effective since they imply many false positives, i.e., legitimate users being locked out. Before showing this to a broader audience, I need some people looking at the code, though. The code, just 600 lines of C, is available at: https://github.com/NullHypothesis/brdgrd/ Cheers, Philipp

1 1

WebSocket pluggable transport
by David Fifield 15 Apr '12

15 Apr '12

Here is a draft of a proposal for a pluggable transport using the WebSocket protocol. In short, WebSocket is a socket-like feature accessible to JavaScript in newer web browsers. Here are some links about it: https://tools.ietf.org/html/rfc6455 http://dev.w3.org/html5/websockets/ https://developer.mozilla.org/en/WebSockets WebSocket is the transport used by flash proxies (which now use JavaScript instead of Flash). This pluggable transport is a necessary part of the flash proxy system as it stands, because something needs stand between a Tor client and a web browser proxy, and again between the proxy and a Tor relay. This proposal is mainly describing what is already implemented in https://gitweb.torproject.org/flashproxy.git The program connector.py is the client transport plugin, and for the server transport plugin I'm using a program called websockify. (websockify isn't completely satisfactory though, and replacing it is ticket #5575.) What's implemented works well enough that I have been using IRC over Tor over a WebSocket transport for about a week. I want to emphasize that this proposal is not the entirety of the flash proxy architecture, but only a part of it. I'm posting it here because 1) I want your help in getting it right, and 2) it may be useful beyond just flash proxies. Anyone interested in reading the proposal, I'd like to call your attention to a few points for comment. One is that there are different, partially incompatible, version of the WebSocket protocol. I have made the most recent version (RFC 6455) a MUST and any earlier versions a MAY. However it may be that in a little while browser support will be such that there is no reason to support old versions. The other is the base64 subprotocol used to send binary data over a text-only channel. WebSocket has a fully binary messages, but they are not supported in Firefox 10. This may be another thing that is changing rapidly enough to drop, as Firefox 11 and Chrome 16 do support binary messages. David Fifield

1 0

IRC meeting to discuss sponsor F July milestone on Thu Apr 12, 16:00--18:00 UTC in #tor-dev
by Karsten Loesing 14 Apr '12

14 Apr '12

Hi everyone, we have an upcoming sponsor F milestone on July 1. Here's the list of deliverables: https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorF/Year2#P… We need a ticket owner for all tickets in the July 1 milestone. We also need a schedule for each of those tickets with the next substep ideally being due in the next 4--6 weeks. I suggest we have an IRC meeting on Thu Apr 12, 16:00--18:00 UTC in #tor-dev. Here's the time and date for people not living in UTC land: http://www.timeanddate.com/worldclock/fixedtime.html?iso=20120412T16 People who should attend are: George, Erinn, Nick, Steven, Roger, Aaron, Jake, Linus, Sebastian, and anyone else who wants to attend. If you have any input on the project tickets before next Thursday, please feel free to comment on them. The more questions we solve before the meeting, the better. Thanks, Karsten

1 1

ampislay: anonymous connection trough IP spoofing
by Fabio Pietrosanti (naif) 12 Apr '12

12 Apr '12

Vecna [1], today published ampislay [2], an 8 years old project to implement anonymous communication trough IP spoofing. It's a not-so-conventional techniques, that have it's advantage and weakness, but that maybe considered within the Tor community for some particular use-case. It was a gift for my 2004 birthday (thanks!!!) :-) -naif [1] http://www.delirandom.net [2] https://github.com/vecna/apmislay

1 0

SkypeMorph
by Hooman 09 Apr '12

09 Apr '12

Greetings, A while ago the Tor project rolled out Obfsproxy as a Browser Bundle [1], for users behind firewalls filtering SSL or detecting other characteristics of a Tor connection, to help them access bridges. In our recent work, SkypeMorph [2], we have tried to use Skype video communications as our target protocol for protocol obfuscation. SkypeMorph functionality is similar to Obfsproxy, but the connection between the bridge and the client looks like a Skype video call (the details of how we do this is discussed in the technical report). We also have an open-source proof-of-concept impelmenation of the SkypeMorph available at: [3] Notes: 1- At the moment our code relies on SkypeKit SDK [4] (a paid Skype SDK which you can get for around US$ 5) for Skype functionalities (the README file in the package explains how one can obtain SkypeKit). However, it can be easily ported to Skype public API [5], so users would not have to pay for it. 2- SkypeMorph and pluggable transports: Although our code can potentially be used as a pluggable transport, there is a minor difficulty with the pluggable transport framework that needs to be addressed before it can host our code. As mentioned above, our code uses Skype network for basic login stuff, so it takes a little bit more time than what Tor expect from a typical transport (like Obfsproxy), so the Tor client gives up building circuits after a while. We are aware of ORControllers tricks to solve the problem, but it does not seem to be the right way to do it and it would be awesome if the pluggable transport were able to tell Tor that it's working on setting up the connection, and that Tor shouldn't give up on it until it says it's ready. I am sure other transports could also benefit from this. Hooman [1]:https://blog.torproject.org/blog/obfsproxy-next-step-censorship-arms-race [2]:http://cacr.uwaterloo.ca/techreports/2012/cacr2012-08.pdf [3]:http://crysp.uwaterloo.ca/software/ [4]:http://developer.skype.com/public/skypekit [5]:http://developer.skype.com/public-api-reference

3 8

Self Introduction for GSoC 2012
by junior 06 Apr '12

06 Apr '12

Hi Tor Community, My name is Tengey Junior Patrick, a 4th year student of the University of Ghana, in Ghana of course. I am offering computer science and Mathematics and am a programmer mainly in java who is very interested in participating in GSoC 2012 with Tor. I have read that Tor is participating in GSoC 2012. I am very enthused about what Tor does and I can’t wait to be a part of this campaign of improving Internet privacy and security. Especially because I have been a victim of Internet Surveillance where my password was tempered with so I am well motivated for this. I have been observing your community interactions for some time now. I have already subscribed to the tor-announce mailing list and the tor-dev list. I have also been idling on the #tor-dev on the OFTC IRC channel. I have gone through the proposed students’ projects [2] and some documentations on "Running Tor" [1] . I have downloaded and installed the stable version of the Vidalia bundle and I am acquainting myself with its usage. I want to know if I am doing the right things since I am new to Tor. Also I want to know if the project on "Tor Controller Status Event Interface for Vidalia" is still available to work on. I particularly program in Java and have done some work on UI developements. Also I am quite proficient in the english language and can play around with photoshop as well. But I don’t really program in c++ though I have learnt the basics in skul, so does that disqualify me from working on the project. If not, what else must I know prior to the application in order to get acquainted with your practices and better understand your organizational set up. I will be very glad if help is given me in this regard. Thanks a lot. [1]https://www.torproject.org/docs/documentation.html.en [2]https://www.torproject.org/getinvolved/volunteer.html.en#Projects

2 3

Analysis of the Relative Severity of Tagging Attacks
by The23rd Raccoon 04 Apr '12

04 Apr '12

Analysis of the Relative Severity of Tagging Attacks: Hey hey, ho ho! AES-CTR mode has got to go! A cypherpunk riot brought to you by: The 23 Raccoons Abstract Gather round the dumpster, humans. It's time for your Raccoon overlords to take you to school again. Watch your step though: You don't want to catch any brain parasites[0]. Introduction For those of you who do not remember me from last time, about 4 years ago I demonstrated the effect that the Base Rate Fallacy has on timing attacks[1]. While no one has disputed the math, the applicability of my analysis to modern classifiers was questioned by George Danezis [2] and others. However, a close look at figure 5(a) of [3] shows it to be empirically correct[4]. Recently, Paul Syverson and I got into a disagreement over the effectiveness of crypto-tagging attacks such as [5]. He asked me to demonstrate that they were more powerful than active timing attacks (which I've done in [6]), and to measure just how much more powerful they were (which is shown in this work). At least I think that's what he was asking. His paragraphs were very looooooong... Anyway, out of the goodness of my little Raccoon heart, I asked my brethren to help me complete this proof ahead of schedule. We're worried about you guys. You be gettin sloppy with da attack analysis, yo (brain parasites??). And when ya get sloppy, the Raccoons pick up the scraps and multiply. And, as you'll see below, you're not gonna like it when we multiply. It means more work for you. (But you probably should have realized that in the first place). The Amplification Potential of Tagging Crypto-tagging attacks like [5] provide for an amplification attack that automatically boosts attack resource utilization by causing any uncorrelated activity to immediately fail, so the attacker doesn't have to worry about devoting resources to uncompromised traffic. Those of you who are already familiar with [5], stay with me. The authors of [5] apparently did not realize the amplification power of their attack, either. Despite my teasing above, I can see why you dismissed them initially. The crypto-tagger achieves amplification by being destructive to a circuit if the tagged cell is not untagged by them at the exit of the network, and also by being destructive when a non-tagged cell is "untagged" on a circuit coming from a non-tagging entry. It transforms all non-colluding entrances and exits into a "half-duplex global" adversary that works for the tagger to ensure that all traffic that he carries goes only through his colluding nodes. Imitating a Tagging Attack with Timing Attacks The crux of the argument against fixing crypto-tagging attacks is that they can be imitated by an active adversary using timing attacks. To imitate a tagging attack, the attacker attempts to achieve circuit killing amplification by using timing to try to determine which circuits are not flowing to colluding nodes, and kill them. The imitated tagging attack has two steps. First, the two colluding endpoints correlate all candidate matches together and kill all other circuits off. Then, they embed a more thorough active timing signature into the remaining circuits to determine the sure matches. We contend that this first step has very little timing information available due to the need to close circuits before streams are opened (which happens after just a couple cells). Certainly not enough to establish 0-error across a large sample size. Even so, in the analysis we'll be generous and concede a very low false positive rate could still be possible. It turns out not to matter that much, as long as it's non-zero. So let's analyze each step of the imitating attack in turn. Imitating Tagging: Circuit Killing Step In the first pass of the imitating attack, the adversary performs an initial correlation of new circuits, and then kills the ones that don't correlate. So let's do the base rate analysis[1] for the correlation, shall we? The probability that an arbitrary pair of circuit endpoints seen through the c/n colluding nodes belongs to the same circuit is equal to (c/n)^2 times the probability of picking an arbitrary matching pair of circuit endpoints out the network's 's' streams (1/s^2). Pk(M) = (c/n)^2 * (1/s)^2 >From my previous work in [1], we have the effect of the base rate on this attack: Pk(M|C) = Pk(C|M)*Pk(M)/(Pk(M)*Pk(C|M) + Pk(~M)*Pk(C|~M)) For every actual match, the adversary can expect to have 1/Pk(M|C) additional matches predicted by the correlater. If you churn through some more analysis, you can see that the probability Pk(~M|~C) of correctly killing non-matching circuits is pretty high (but is still a function of c/n). In other words, the adversary is pretty sure that the circuits he does kill are irrelevant. Since everyone around here likes to assume the correlating adversary is all-powerful, we doubt we need to show their strength in this avenue. Let's just assume Pk(~M|~C) = 1, and no true matches are killed early. Now for the numbers. Being a Raccoon, I am limited by the precision of my trusty rusty squirrel-skull abacus[7], so I'll give the imitating adversary several benefits of the doubt here to keep the math more simple. You can re-calculate at home on a high precision calculator without these assumptions if you like. First, let's just assume for the ease of analysis that the imitating adversary gets to behave globally in the first step and set c=n for it (relax Paul, this assumption is in your favor). After all, maybe the NSA has some tricks up their sleeve with respect to global timing analysis that we don't know about. If we don't give the imitating adversary this bonus, the base rate just gets too small to manage and crypto-tagging wins by a landslide because of its free "half-duplex global" property. It would take all of the excitement right out of our proof! Pk(M) = (n/n)^2 * (1/s)^2 = 1/s^2 To toss the imitating adversary another bone (since they keep falling off of my abacus anyway), and because a 0.0006 false positive rate "is just a non-issue"[8], we'll give those chumps an extra 0. They deserve it, they need it, and we're feeling generous. Hey, maybe they even can successfully encode some timing information between the first two cells on a circuit. Pk(C|~M) = 0.00006 Pk(C|M) = 0.99994 = 99.994% As if that weren't enough, we'll *still* use only s=5000 concurrent streams, even though over the past 4 years of network growth, that is now an absurdly low number. Pk(M) = (1/5000)^2 = 4*10^-8 Plugging everything in: Pk(M|C) = 0.99994*4*10^-8/(0.99994*4*10^-8 + (1-4*10^-8)*0.00006)) Pk(M|C) = 0.000666 1/Pk(M|C) => 1501 extra circuits survive for every true match. The imitating adversary sure seems to be carrying a lot of extra traffic at this point (roughly 1501 times as much as he wants), even though we made three seriously large (to the point of being erroneous) assumptions in his favor. Stay tuned for the exciting conclusion to see what he'll do with it. Imitating Tagging: Active Timing Attack Step (at 100% accuracy) After filtering, the imitating adversary then moves on to use an active timing attack to determine the true matches. Let's walk through the base rate analysis to see what they will look like. The probability of picking an arbitrary, random endpoint match is proportional to the number of remaining endpoints, which should trend towards the fraction of the colluding capacity times the number of total endpoints: Pi(M) ~= O((c/n) * (1/s^2)) Technically, there is a correction we need to do for the increased prior probability of matches being present due to the filtering step above, but we're going to ignore that for now, because we'll just give the adversary 100% accuracy for this stage. We do not believe a 0-error active timing attack would survive analysis (see the Future Work section), but Paul was quite insistent, and it also simplifies analysis. So here you go, Paul: Pi(C|M) = 1 Pi(C|~M) = 0 Pi(M|C) = 1*Pi(M)/(Pi(M) + 0*(1-Pi(M)) Pi(M|c) = 1 With this level of accuracy, Pi(M) is irrelevant. The base rate loses this one (but only because the error rate is contrived). Now, how many of the network's total circuits does the adversary actually compromise? Well, the adversary is carrying c/n of the network traffic, but only Pk(M|C) of those circuits are actually valid candidates for matching. Of those, Pi(M|C) are discovered by the active timing attack (all of them). Pi(compromise) = c/n * Pk(M|C) * Pi(M|C) Pi(compromise) = c/n * 0.000666 Ok, not bad. The imitating adversary seems to beat the expected O((c/n)^2) for end to end 0-error attacks for some values of c. So it might be a good idea. Sometimes. Let's check in with our crypto-tagger and see how he's doing. Full Analysis of the Crypto-Tagging Attack The most direct and intuitive route to calculate the base rate Pc(M) for the crypto-tagger is through the observation that the "half-duplex global" adversary is killing all traffic such that the all of the 's' streams that flow through the adversary's nodes are fully compromised. Pc(M) = (1 / ((c/n)*s))^2 Pc(M) = (n/c)^2 * (1/s)^2 Ugly looking base rate, but it doesn't matter, because the crypto-tagger can in fact encode arbitrary bit strings in his tags without even resorting to timing. Bit string encoding was not actually discussed in [5], but our crack research team of 23 Raccoons doesn't see why it isn't possible. Therefore, the crypto-tagger's Pc(M|C) ends up 1.0. But unlike the imitating tagger, the crypto-tagger doesn't need any gifts from Raccoons to achieve his success rate. Pc(C|M) = 1 Pc(C|~M) = 0 Pc(M|C) = 1*Pc(M)/(1*Pc(M) + 0*(1-Pc(M)) Pc(M|C) = 1 To calculate the probability of compromise of an arbitrary circuit chosen from the entire network, we need to get a measure on the number of circuits that flow through the adversary's nodes. The most direct and intuitive way to calculate this probability is to realize that the "half-duplex global" adversary created by the crypto-tag ensures that all of the c/n network capacity deployed by the attacker carries only fully compromised circuits. Therefore, the attacker can expect to compromise c/n of the circuits on the network. The probability of compromise network-wide is then: Pc(compromise) = Pc(M|C) * c/n Pc(compromise) = c/n In other words, the attack expects to compromise (c/n)*s of the network's total concurrent streams. So much for O((c/n)^2). If even just one of the major exit relays became compromised or coerced to implement a crypto-tagging attack (or hey, just did it for the lullz!), the consequences would be devastating, and invisible to users. Crypto-Tagger vs Imitating Tagger Let's compare the two probabilities of compromise: Pi(compromise) = Pc(compromise)*Pk(M|C) Pc(compromise) = Pi(compromise)/Pk(M|C) Pc(compromise) = Pi(compromise)*1501 So even with a 100% accurate active timing attack and several very liberal assumptions in favor of the imitating adversary, the crypto-tagger compromises 1501 *times* as many circuits with the same attack capacity. That's some nice amplification. Moreover, the crypto-tagger has a compromise rate of c/n, which obliterates the O((c/n)^2) expected compromise rate that c/n-carrying adversaries are supposed to be capable of compromising. Sounds like it's time to swap out AES-CTR in favor of a self-authenticating cipher[9] amirite??. OCB mode, anyone? Future work We can further elaborate the above analysis to take in more realistic error rates for active timing attacks. Such an exercise might be instructive, but we believe it is not necessary to properly evaluate imitating tagging versus crypto-tagging. It will only make the imitating tagger look worse, and everybody should realize by now he's just a poser anyway. ----------------------------- 0. https://en.wikipedia.org/wiki/Baylisascaris_procyonis 1. http://archives.seul.org/or/dev/Sep-2008/msg00016.html 2. https://conspicuouschatter.wordpress.com/2008/09/30/the-base-rate-fallacy-a… 3. http://www.cl.cam.ac.uk/~sjm217/papers/pet07ixanalysis.pdf 4. https://lists.torproject.org/pipermail/tor-talk/2012-March/023592.html 5. http://www.cs.uml.edu/~xinwenfu/paper/ICC08_Fu.pdf 6. https://www.eff.org/pages/tor-and-https 7. http://www.youtube.com/watch?v=ERwqbdAIY04 8. https://blog.torproject.org/blog/one-cell-enough 9. https://en.wikipedia.org/wiki/Authenticated_encryption 10. Look, I used more citations this time!

6 12

Gsoc 2012 Project Proposal.. Feedback please!!
by drake01 04 Apr '12

04 Apr '12

Hi guys, This is the initial proposal for "Integrating Tor with user-space transport protocol libraries" during GSOC 2012. Proposal: After initial shortlisting of transport protocols to be integrated with tor, I am left with sctp and udp. Initially I was willing to go with sctp but after getting suggestions on irc, I propose to integrate the udp library for datagram transport to tor (modified tor) as my gsoc 2012 project. I am leaving sctp (for now) and choosing UDP because: 1) I learn that testing has been done for libutp (utp) and results seem good. so risk of failure is minimized. 2) The libutp has faced the test of time and seen wide usage (u-torrent) 3) The library is already available. Although modifications will need to be done to make it work with tor.. So work from very beginning need not be done. Other stacks are also available. But It seems to be closest to what we need(based on what I know so far. Also Ref: Mentioned in the paper too: Comparison of Tor Datagram Designs.) 4) The sctp kernel space implementation has been heavily tested (as told by jmurdoch) but because of security issues mentioned in the paper of its use, sctp does not seem to be first choice to bet upon. Based on Datagram Testing Plan paper,march,2012, I would most likely fit to work on utp and hop-by-hop transport beginning in may. (I'd have no other commitment by that time.) Circuits are constructed preemptively using tcp in tor. Also since different transports are to be tested in future (possibly), So changes to be done in the tor should help it by providing a clean interface to change the protocol (sort of plugin interface.. Although the protocols are already layered to accomplish it, but reusability factor need to be taken care of as much as possible) As the hop by hop reliability is easier to implement (less changes to tor) and project of new transport protocol is new to tor, so not much experience is available. Thus as an experiment, the hop by hop reliablity seems to be the best selection right now (obviously with the scope of making changes in future) Also if the modified tor is tested on the live tor network, hop by hop reliability'll help in addressing the issue of deanonymization of nodes because major population of nodes'll be using tcp during the migration period. As mentioned in "Improving Tor using a TCP over DTLS" paper by Reardon, the implementation of DTLS (TLS for Datagram) is already there in OpenSSL. TLS and DTLS apis are unified too, i.e. same OpenSSL calls'll be able to handle sending and receiving data with minimum changes which'll have to be made to tor. I'd be extremely careful about the overall implementation so that changes done in tor don't just emerge out as a separate new branch and act as blockage for other transports and future changes. Instead, changes should be made to complement the future development. Goals to keep in mind for taking decisions while implementing: To achieve Low latency and scalability are two goals that I see to keep in mind while implementing/integrating the protocol to tor. Thorough testing is only viable option for ensuring these though. But as mentioned in the Datagram Testing Plan paper, simulation is also fine..(Please make additions here) In the end, As integrating new transport is not an individual's task to complete, its being done by a team and a plan is already there (Murdoch's march paper). So this proposal is for me to be of value to the team and not be limited to the libutp. So if time permits, I intend to help by contributing to other parts of this project too especially Experimentor. By the way, where can I find the md5 or sha digests for the Experimentor? Timeline: Google summer of code 2012 will be a 12 week (3 months) programme: I would like to report my progress twice each week preferably wednesday night (utc+0) and saturday night (again utc+0). I will submit the detailed timeline after making the proposal almost final.. I've planned to maintain a blog or github pages to provide the details about the project's progress..I would be available on irc for all of my working time though. Currently github repository for my torprojectgsoc12: https://github.com/drake01/torprojectgsoc2012 (its empty, I'll fill it soon:) ) Test code: I am planning to submit a socket based small server/client app through above repository which I wrote in initial days while learning( needs some changes to distribute though).. Also would try to write something utilising raw sockets to show my understanding of Internet Protocol stack. Comments! Current status: I have cloned the git repository of tor and a few related softwares including libutp and have it working on my machine. Also started to dissect the libutp code. I have gone through the papers, Comparison of Tor Datagram Designs and Datagram Testing Plan by Murdoch. I have overviewed the tor-design paper by Nickand Roger. Github account: https://github.com/drake01 #vim-7.3 Comments, Criticism, suggestions are most welcome.. :) -- Online pseudonym: drake01, drakeo1 or drakeoone Blog: http://goo.gl/uMnRp Github: https://github.com/drake01

3 4

Google Summer of Code Proposal - PathSupport counterpart for Stem
by Ravi Chandra Padmala 02 Apr '12

02 Apr '12

Hello I'm Ravi Chandra Padmala, a 20 year old computer programmer from India. I want to apply to the Tor Project/EFF for Google's Summer of Code program this summer. I would like to spend the summer building the PathSupport counter part for Stem. I have submitted a work in progress proposal at http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/neena/1 I've submitted a WIP proposal primarily because I need feedback on the direction my API design is taking. I have only answered question (a) from https://www.torproject.org/about/gsoc.html.en#Template . I will be updating the proposal with the rest soon. Any feedback will be greatly appreciated. -- neena

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev