Re: [tor-dev] On the security of a commit-and-reveal solution for #8244
On Fri, Nov 22, 2013 at 9:55 AM, George Kadianakis wrote: > (This message has been sitting in my drafts for a week or so, because > I fear that it might make no sense. Today I cleaned it up and decided > to post it.) > > Hello Nick and Elly, > > we were recently discussing various commit-and-reveal schemes to > accomplish the unpredictability of HSDir positions in the hash ring. > > This is a thread to better coordinate on this subject. The > corresponding trac ticket number is 8244. > > I left our IRC discussion with two conclusions in mind: > > a) The simple approach of a commit-and-reveal protocol can not be >entirely secure since an adversary could choose not to reveal his >value (abort) which would allow him to influence the final result. > > b) Proper protocols that achieve this goal are ugly, both in elegance >and in the number of rounds. This is basically the Byzantine >agreement problem which has ugly solutions and funny impossibility >results. > > We started thinking of how disastrous a commit-and-reveal scheme could > be for our specific use case, and we decided that it's worth thinkihng > more about before moving to other heavyweight protocols. (re-posting this reply to tor-dev at George's request) Your analysis looks correct to me. But what's wrong with using threshold crypto or secret sharing? Since you're already assuming some sort of bounded delay synchronization, I think we can eliminate any advantage in influencing the randomness with one extra round, using e.g. threshold Elgamal: 0. (Periodically, like once per month): authorities derive a shared Elgamal key pair (x, X = xB) for the group G. (with prime order p) 1. each authority publishes a randomly chosen encrypted group element P_i: (r_iB, r_iX+P_i) along with a proof of knowledge of r_i. (an easy proof to implement) 2. After COMMIT_TIMEOUT: each authority takes all published ciphertexts (with valid proofs), and publishes a list of ciphertexts it received. 3. After AGREE_TIMEOUT: each authority takes all published, valid ciphertexts that appear in over half of the previous set of documents, and adds them componentwise to get an encryption of the sum of the group elements (sB, sX+Q). Each authority publishes this ciphertext plus its decryption share of this ciphertext with a proof of correct decryption. (this is also a pretty straightforward proof to implement) [ here s is the sum of the scalars r_i, Q is the sum of the group elements P_i ] 4. After REVEAL_TIMEOUT: each authority combines the valid decryption shares to get a random group element Q, and publishes a signed document containing the decryption shares and Q. -- Nicholas Hopper Associate Professor, Computer Science & Engineering, University of Minnesota Visiting Research Director, The Tor Project ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] (Draft) Proposal 224: Next-Generation Hidden Services in Tor
On Fri, Nov 29, 2013 at 7:27 PM, Nick Mathewson wrote: > Appendix A. Signature scheme with key blinding [KEYBLIND] > ... > See [KEYBLIND-REFS] for an extensive discussion on this scheme and > possible alternatives. I've transcribed this from a description by > Tanja Lange at the end of the thread. [TODO: We'll want a proof for > this.] A security proof for this scheme is available at: https://www-users.cs.umn.edu/~hopper/basic-proof.pdf (LaTeX sources at https://www-users.cs.umn.edu/~hopper/hs-identity-proof.git) It would be fantastic to get comments/discussion from the tor-dev community ahead of publishing this as a Tor Project tech report. -- Nicholas Hopper Associate Professor, Computer Science & Engineering, University of Minnesota Visiting Research Director, The Tor Project ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Slight obfsproxy API change (#10342)
On 12/12/13 23:40, George Kadianakis wrote: > David Stainton writes: > >> Excellent! I was thinking of making this change but lately I haven't had >> much time. >> Merging that patch specified in the 1st ticket comment? That looks good. >> >> I'd be happy to update the bananaphone transport to use the new api! >> >> Cheers, >> >> David >> > > The change is now merged and pushed :) When updating your transport, don't forget to - call super(YourTransport, self).__init__() in your own __init__ - rename handshake() -> circuitConnected() as well as renaming the local "circuit" params. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Slight obfsproxy API change (#10342)
David Stainton writes: > Excellent! I was thinking of making this change but lately I haven't had > much time. > Merging that patch specified in the 1st ticket comment? That looks good. > > I'd be happy to update the bananaphone transport to use the new api! > > Cheers, > > David > The change is now merged and pushed :) ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Gitian Build Failure (pt branch only?)
Hi Mike/dcf1, Building the pt branch [1] of tor-browser-bundle on Ubuntu 13.04, 64-bit resulted in the following error: <<< ./bin/gbuild:21:in `system!': failed to run on-target setarch i386 bash -x < var/build-script > var/build.log 2>&1 (RuntimeError) from ./bin/gbuild:121:in `build_one_configuration' from ./bin/gbuild:223 from ./bin/gbuild:218:in `each' from ./bin/gbuild:218 from ./bin/gbuild:216:in `each' from ./bin/gbuild:216 make: *** [build] Error 1 >>> dcf1 suggested that I downgrade to the 3.2.0 kernel. This wasn't (obviously) supported in 13.04, so I decided to downgrade my system to 12.04. On a clean 12.04, 64-bit, install I got the same issue. Then, the following resolved the problem for me: <<< $ sudo apt-get remove linux-image-3.8.0-29-generic linux-image-generic-lts-quantal linux-image-generic-lts-raring $ sudo apt-get --reinstall install linux-image-generic >>> I did not encounter this problem when building [2] last week. When the failure occurs, var/build.log contains the "invalid instruction suffix" errors as reported in [3]. -Kevin [1] https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git [2] https://gitweb.torproject.org/builders/tor-browser-bundle.git [3] https://github.com/cloudmatrix/myppy/issues/7 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] InjectSOCKS: 2nd try
Hi again, Sorry for the delay to respond! On 10 Dec (20:27:14), t...@herr-der-mails.de wrote: > Hello David, > > thank you for your reaction. I've read some information about > "Torsocks" now and yes, it seems to be similar. Unfortunately the > information on Torsocks's homepage is rather short. So I can't tell > you if the internal technology is similar. Currently, an effort is still ongoing on rewriting torsocks and in code review process right now. Thus, the webpage is probably out of date big time. > It tells that it explicitly rejects UDP traffic. It would be possible > to block UDP traffic in InjectSOCKS as well. By the way, why does Tor > not support UDP via SOCKS? Yes, UDP is simply not supported by Tor thus it will be rejected when opening the socket. Actually, it's not only UDP that should be blocked but *every* other protocol except TCP. For instance, there is no way to send icmp request through Tor thus we don't want that to leak. > The Torsocks documents also say that it blocks local traffic as well. > While implementing InjectsSOCKS I saw that some Windows software > needs local traffic in order to work for internal inter process > communication (maybe Internet Explorer - not sure anymore). So I've > explicitly prevented using the SOCKS server for local traffic > (wouldn't make sense) and don't reject it - otherwise this software > wouldn't work anymore. This is dangerous and the reason why it's denied is that the application could easily make a DNS request for instance to a local server that will then resolve it on a remote one thus leaking. You should really reconsider that, going locally can be fine but also really dangerous. > > > Do you think you can put your code into a git repository (github, > > gitourious, ...). That would be *very* helpful to review/contribute > > and track changes. > > Unfortunately I'm not familiar with git. However, the source code is > rather small. The most important parts are in InjectSOCKS_DLL.c > The sources are already commented a little bit, but I think that I'll > add Visual C++ XML or doxygen style documentation. This way it's > easier to understand and review/analyze the code. For the moment I'd > like to suggest sending me any change suggestions or questions via > e-mail. If we detect that this is not manageable, we can still switch > to a different solution. Maybe you can use one you are familiar with? SVN, bazaar ... ? It's just that for an open source project, having it easily browsable on a public server that *anyone* can clone the latest, it helps a great deal. Maybe it's a good time to get familiar with the most awesome tool you'll ever play with, git! :P > > By the way, I've released V1.1 of InjectSOCKS now. This adds the BSD > license text and a dialog for creating a Windows shortcut file to > call InjectSOCKS correctly. The dialog pops up when you start > InjectSOCKS without any parameter. This helps users not familiar with > the command line. > Known bug: There is a small possible memory leak in the function > "CreateLink" of that dialog; it will be fixed in the next release :-) I'll take a look at it and if I can find a Windows, test it. From that point on, I'll check how feasible it is to integrate what you did in the new torsocks code so we can have *nix and Windows support in the same tool, that would be quite awesome. Cheers and thanks for this! David > > Regards, > ghostmaker > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor project automation work
Nicolas Vigier: > In addition to this, an other thing that we could do automatically is > rebasing the tor-browser patches onto the unreleased next mozilla esr > from http://hg.mozilla.org/releases/mozilla-esr24/ in the default branch. > This allows to see in advance if rebasing the patches on the next ESR > release will require some work, and if some new Mozilla patches break > the build or some tests. That is definitely a thing high on my wishlist for a while now. If we could get this going again (there was a time Mike rebased everything for a new Firefox release) I am all for it. While I am pretty sure rebasing the patches against the next ESR will require some work (provided we don't get a substantial portion of them merged upstream meanhwile) having more time fixing new Firefox issues alone is worth the effort IMO. Georg signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor project automation work
On Tue, 10 Dec 2013, Nicolas Vigier wrote: > > > In order to help me doing that, I'm very interested to receive from > > > developers of any tor components : > > > > > > - a description or ticket number of bugs that you wish could have been > > > detected earlier with automated tests > > > > https://trac.torproject.org/projects/tor/ticket/8143 comes to mind here. > > Ok. We should soon be able to push tor browser to Mozilla's Try servers, > which will run all the unit tests, so we should be able to detect bugs > like #8143. Regarding this, we will be testing the version that is in tor-browser.git, when a branch receive new commits. In addition to this, an other thing that we could do automatically is rebasing the tor-browser patches onto the unreleased next mozilla esr from http://hg.mozilla.org/releases/mozilla-esr24/ in the default branch. This allows to see in advance if rebasing the patches on the next ESR release will require some work, and if some new Mozilla patches break the build or some tests. pgpy7URxUEvrC.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Slight obfsproxy API change (#10342)
Excellent! I was thinking of making this change but lately I haven't had much time. Merging that patch specified in the 1st ticket comment? That looks good. I'd be happy to update the bananaphone transport to use the new api! Cheers, David On Wed, Dec 11, 2013 at 10:33 PM, George Kadianakis wrote: > Hello Philipp and David, > > I'm sending you an email because you are the people who are currently > developing obfsproxy modules. > > We are thinking of slightly changing the API of obfsproxy, so that it > becomes more friendly to transport authors (or at least we hope so). > > Specifically, we are thinking of having the circuit be an element of > the transport class, instead of being passed as an argument in the > receivedDownstream and receivedUpstream methods. I think David and > Leif were also thinking of this change. Furthermore, we are also > thinking of renaming the 'handshake' method to 'circuitConnected'. > (More details can be found in #10342.) > > Do you agree with the changes? If yes, I will merge Ximin's patch for > #10342, and you will have to update your transport codebase > appropriately. Please let me know. > > Thanks! > ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
