On Mon, Mar 27, 2017 at 9:17 PM, Krishna Shukla <karatekrishna@hotmail.com> wrote:

Hey,

I'm Krishna Shukla, I'm studying a bachelors of computer science at the University of Queensland. I guess the relevant subjects I've studied so far covers C and Unix programming, Computer Networks, Algorithms and Data Structures, and Programming in the large. (got a high distinction in all the above)

My most important question is if I could work on a project but not actually be apart of GSoC? - I am unfortunately ineligible as my brother works as a Security Engineer at Google Sydney. And if the above is okay would it also be okay to not have to strictly abide by their timeline as I don't actually have holidays during this time in Australia but I'd like to contribute in my free time nonetheless!

Sure; we are always happy to accept volunteers! You might want to try something simpler than this for your first patch or two -- it's generally better to get practice with smaller things before you move to something big and complex. The documents in doc/HACKING inside the Tor git repository might be a good place to find good starting advice.

As for projects themselves I'm really interested in the relay crypto parallelism and the hidden service crypto parallelism. And I have a couple of questions regarding them.

For the relay crypto parallelism I wanted to know what is there left to be done? When I looked at the tickey #1749 someone called towelenee made a few patches that already made it multi threaded, were these changes just not accepted?

So, those patches just can't work as they're written now. To begin with, they launch a new thread for every hop in an outgoing circuit, and then they wait for every such thread to finish. They also have a pretty serious race condition in their handling of the payload they're supposed to be encrypting. And finally, they only handle client-side circuit crypto -- not relay-side crypto at all. A better approach, and the approach we were hoping for, would be to parallelize crypto by circuit, not by hop: and to use long-lived worker threads, and not using one thread per circuit or (worse) one thread per cell per hop.

Also wanted to know if specific knowledge about circuit cryptography was required? As I know of it, but I certainly cannot make my own fully homomorphic cryptosystem, is it more in the steps of the system has already been made, it just needs to be parallelised correctly?

Right; all our crypto is implemented in Tor right now. I'm not sure why you're mentioning homomorphic cryptosystems; we don't need one of those here.

It also states the code is written to expect immediate responses, I'm not sure what you mean by that, after all there is always a slight delay, and if it becomes multi threaded we can never know what is running what when, so is it more someone is waiting at the other end of a socket and needs it ASAP, or is it internally things want the answer quickly (in which case I don't know how to solve it other than uses mutexes which is probably not so okay)?

Maybe have a look how we use the function relay_crypt() to see what we mean here? A more precise thing to say would have been that the calls to relay_crypt() are written to block until relay_crypt() is finished. But instead, if the work of relay_crypt() is to be done in another thread, then the functions that call it today need to queue the work to be done by another thread ... and then continue safely.

I am interested in the hidden service crypto parallelism in its own right, but I was also thinking weather it would be a feasible idea to combine the two projects and create a multi-threaded decryption library that could be linked to both the tor relay and the hidden services (could release it as a cryptosystem library, all the fully homorphic cryptosystem libraries I found used GPL licenses and thus not compatible with tors), or are their requirements too far apart?

So, the "hidden service" crypto in question here is a set of public key operations. But having a separate library for this probably isn't the right design, IMO. The idea is not to split _each operation_ across multiple CPU cores, but rather to handle _multiple operations_ by doing them on multiple cores. The code for each individual operation could remain single-threaded. If you'd like to see an example of how we do this in Tor today for our server-side circuit extension handshakes, have a look at workqueue.c and onion.c in the Tor source code, to get a sense of how they work together. You'll notice that the crypto operations themselves are handled in regular single-threaded code (eg in onion_ntor.c), and that the parallelism happens on a higher level than a single crypto operation.

Also I was wondering how the Ahmia automated blacklisting was planned to work?

This isn't something I've been working on; maybe somebody else can answer this question. (Ahmia folks?) best wishes, -- Nick