- tor-dev - lists.torproject.org

Fwd: ECC curves that are safe safecurves.cr.yp.to
by grarpamp 10 Jan '14

10 Jan '14

---------- Forwarded message ---------- From: gwen hastings <gwen(a)cypherpunks.to> Date: Fri, Jan 10, 2014 at 9:54 AM Subject: ECC curves that are safe safecurves.cr.yp.to To: "cypherpunks(a)cpunks.org" <cypherpunks(a)cpunks.org> DJ Bernstein and Tanja Lange did a study on which ECC curves are safe to implement and use, found at http://safecurves.cr.yp.to/ YMMV as per the snowden releases but for now curve p25514 appears to be safe AND accessible in at least 2 cli type implementations. To be avoided at present is SECCURE-0.4 and below(no safe curves as per the bernstein document) GH -- Tentacle #99 ecc public key curve p25519(pcp 0.15) 1l0$WoM5C8z=yeZG7?$]f^Uu8.g>4rf#t^6mfW9(rr910 Governments are instituted among men, deriving their just powers from the consent of the governed, that whenever any form of government becomes destructive of these ends, it is the right of the people to alter or abolish it, and to institute new government, laying its foundation on such principles, and organizing its powers in such form, as to them shall seem most likely to effect their safety and happiness.’ https://github.com/TLINDEN/pcp.git to get pcp(curve25519 cli)

1 0

On the security of a commit-and-reveal solution for #8244
by George Kadianakis 10 Jan '14

10 Jan '14

(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. Today, I thought a bit about it. The goal of such a scheme would be to have all authorities collectively generate and agree on a nonce. Adversaries who control a subset of the authorities should not be able to influence the result (except if they control a majority of the authorities; in which case Tor is screwed anyway). So we consider adversaries that can control multiple authorities. Adversarial authorities can either be Byzantine (can lie, malfunction, etc.) or abort unpredictably (because of random failures). To make this more concrete, let's also consider a simple commit-and-reveal scheme for our use case. Every ONCE_IN_A_WHILE: 1. Each authority publishes a signed document with a commitment value. 2. Authorities collect commitment documents from the other authorities. 3. After COMMIT_TIMEOUT minutes each authority publishes a signed document that reveals the cleartext value of their previous commitment. 4. Authorities collect cleartext values from other authorities and check that they match the received commitments. 5. After REVEAL_TIMEOUT minutes each authority publishes a signed document containing: * a list of the received commitments and cleartext values that the authority used in its nonce calculation * the resulting nonce 6. Authorites collect the nonce documents from the other authorities, and check that all authorities had the same commitment/cleartext list and calculated the same nonce. The final nonce derivation function should be unpredictable given at least one honest contribution to the derivation function. For example, if the inputs to the derivation function are big enough (e.g. each authority publishes 32 random bytes), stuffing them into a hash function should do the trick. Also, assuming big enough COMMIT_TIMEOUT and REVEAL_TIMEOUT values, honest authorities should not have trouble casting their vote in time. Maybe we can even allow multi-hour timeout intervals, since we are not in a particular hurry if ONCE_IN_A_WHILE is every 24 hours or more. For the rest of this analysis, the response of authorities towards node failure is to ignore it: keep calm and and carry on. That is, if a node doesn't send a message during COMMIT_TIMEOUT or REVEAL_TIMEOUT, other nodes simply ignore the node for the rest of the protocol. There might be other responses here (like restarting the protocol), but this one is the simplest to reason about and probably the most secure. I argue that the response of restarting the protocol in case of node failure might be much worse than simply proceeding, but it depends on the number of restarts we allow (and especially what happens in the last round of the protocol if the maximum number of restarts is reached). Now, let's consider some adversarial tactics: * (trivial case) If adversaries perform the protocol normally, the resulting nonce should be unpredictable assuming that there is at least one other honest authority. * (stupid case) An adversary can abort during the COMMIT_TIMEOUT phase but she doesn't gain much. The calculation contains without her contributions. * (interesting case) An adversary can abort during the REVEAL_TIMEOUT phase. At this stage, she has seen the cleartext values of the honest authorities and can pre-calculate the final nonce value using her own cleartext values. If the adversary doesn't like the resulting final nonce, she can abort a subset of her authorities, so that she gets different final nonces (since the nonce calculation would continue without considering the aborting authorities). Specifically, if an adversary controls 'a' authorities, she can choose between 2^a possible final nonce values, by aborting different subsets of her authorities. The next question is how this attack influences the probability of an attacker that wants to inject his own HSDirs as the responsible HSDirs of a Hidden Service. I should note that the final nonce is still unpredictable (the adversary can just choose between multiple unpredictable final nonces), so the best strategy of an attacker is to add HSDirs in the hash ring (probably in strategically chosen positions) and choose whichever of the possible 2^a nonce values (if any) makes his HSDirs responsible for the target HS. We can analyze this situation by modeling it as a game and calculating the probability of the adversary winning. I tried to do this in the appendix of this post. If my logic is not flawed (could as well be) and my assumptions are not ridiculous, an attacker has probability '1 - (1 - k/r)^d' of getting his HSDir as the first responsible HSDir of a Hidden Service. In the above formula, k is the number of adversarial HSDirs in the hash ring, r is the total number of HSDirs, and d is d=2^a that is the number of possible final nonce values he can choose from by aborting some of his authorities. On the other hand, the probability of an attacker succeding without the commit-and-reveal scheme is simply k/r. All in all, it seems that the commit-and-reveal protocol is not too bad (if the adversary controls one or two authorities), but it's not very good either. It's worth bearing in mind that footnote [0] might change the probabilities for the worse. It's also important that we look deeper into #8243. If I get persuaded that my assumptions, models and math are correct, I might make some graphs to demonstrate how the attacker probability changes for different values of k, r and d. --- APPENDIX: Badness of commit-and-reveal scheme: (Here be dragons, bad math and plenty of mental masturbation. Proceed with caution.) The problem with the commit-and-reveal scheme is that an adversary who is not happy with the position of the Hidden Service in the hash ring, has the option of choosing any subset of her a adversarial authorities to abort the commit-and-reveal protocol during the REVEAL_TIMEOUT phase, which lets her choose between 2^a positions for the Hidden Service. To evaluate how bad this is, we can model our problem as a game and calculate the probability of the adversary winning. In the game, we model the HSDir positions in the hash ring as random integers from 0 to N. [0] Similarly, we model the position of a Hidden Service in the hash ring as another random integer from 0 to N. We say that an adversary wins, if any of her HSDirs are the closest (in a clockwise fashion) to the position of the Hidden Service. Defining the game formally: Game_1: """ Step 1: Each player p_i picks a number x_i uniformly in [0, N] {This corresponds to HSDir positions in the hash ring} Step 2: A random value phi is chosen uniformly in [0, N] {This corresponds to the position of the Hidden Service in the hash ring} Step 3: Winner is the player whose x_i is the closest to phi. We define the distance of a player i as d_i = x_i - phi (mod N). {This emulates the algorithm that Hidden Services use to pick their responsible HSDirs} """ (For computing ease, we will assume that x_i and phi values are distinct from each other. This should be true in real life too, otherwise some key collision happened.) Looking at the above game, and based on our assumptions, it is easy to see that d_i values are actually random values in [0, N]. This can be seen informally, since the players during step 1 don't know the value of phi. It can also be seen formally by calculating P[d_i == 0], P[d_i == 1], ..., P[d_i == N]: all of those probabilities should be 1/N. This means that we can reduce the above game to a new game that is easier to analyze: Game_2: """ Step 1: Each player p_i picks a number d_i uniformly in [0, N]. {This corresponds to each player getting assigned a distance value d_i} Step 2: Winner is the player with the smallest d_i value. {The winner is the player with the smallest distance from the Hidden Service.} """ Now let's analyze Game_2: Informally again, since the game is fair and symmetric, all players have the same probability of winning. That is, P[p_1 wins] == P[p_2 wins] == ... == P[p_r wins] (1) where r is the total number of players. {in our equivalent real life problem, r is the number of HSDirs } Furthermore, since one player has to win, we have: P[p_1 wins] + P[p_2 wins] + ... + P[p_r wins] == 1 (2) Combining (1) and (2) we get that P[p_i wins] == 1/r (for 0 < i < r) which means that all players have probability 1/r of winning. This is intuitive and what we expected. Now let's calculate the probability of an adversary winning the game, assuming that he controls multiple players. {or that he controls multiple HSDirs in our equivalent real life problem} It's easy to see that the probablity of k players winning is k/r. This means that: P[adversary that controls k out of r players wins] = k/r (3) with k <= r. Now that we have these probabilities in place, we can calculate how bad the commit-and-reveal scheme is for us. It's important to notice, that an adversary who controls a authorities can choose between d = 2^a values of phi in Game_1, but she doesn't get a chance to redistribute her x_i values accordingly (since relays require a certain uptime till they get the HSDir flag). Informally again, I argue that choosing between d values of phi in Game_1, is the same as restarting Game_2 d times (so that all players get completely different d_i values). Hence, I believe that the probability of an adversary winning if he has d choices of phi, is the same as the adversary winning in at least one instance of Game_2 if Game_2 is restarted d times. That is, P[winning in at least one instance of Game_2 if you play d times] == P[*not* loosing all d instances of Game_2] == 1 - (P[loosing all d instances of Game_2] == 1 - (P[loosing on Game_2])^d == 1 - (1 - P[winning on Game_2])^d, and using (3) we get: == 1 - (1 - k/r)^d (4) where we assume that the adversary controls k out of r players of Game_2. Now that we have (4), let's plug some real life Tor network data into it to see what kind of probabilities we get: If we assume that we have r=2000 HSDirs in total [1], and an adversary controls k=100 HSDirs, the probability of him winning Game_2 is: P[adversary wins] = k/r == 100/2000 == 0.05 Now, let's also assume that we are using the commit-and-reveal scheme and the adversary controls 1 authority, hence d = 2^a == 2. Now we have: P[adversary wins] = 1 - (1 - k/r)^d == 1 - (1 - 100/2000)^2 == 0.0975 If he controls 2 authorities, we have d == 4, and: P[adversary wins] = 1 - (1 - k/r)^d == 1 - (1 - 100/2000)^4 == 0.1854 If he controls 3 authorities, we have d == 8, and: P[adversary wins] = 1 - (1 - k/r)^d == 1 - (1 - 100/2000)^8 == 0.3697 And the numbers go on... [2] It's worth noting here that this attacker only cares to get the first position after the HS. An attacker who wants to do so probably plans to squat *all* responsible HSDirs of a HS, and he can achieve it by placing multiple clusters of HSDirs in different parts of the hash ring. This is a different strategy from the attacker who only cares about having a single responsible HSDir for an HS; the probabilities for such an attacker would be better than the ones above. [0]: This is a very *important* assumption, since adversarial HSDirs can pretty much pick their position in the hash ring by brute forcing their keys till they find one that puts them in a good position. A good position would be a place where there is a big gap between the adversarial HSDir and the previous honest HSDirs. We will not consider this adversarial strategy since it makes the math harder. [1]: $ grep -i HSDir cached-microdesc-consensus | wc -l 2015 [2]: http://www.wolframalpha.com/input/?i=1+-+%281+-+k%2Fr%29%5Ed%2C+for+k%3D100…

3 3

GSoC project idea: pluggable transport that hides data in TCP SEQ numbers / UDP SRC ports
by Jacek Wielemborek 10 Jan '14

10 Jan '14

Hi, I recently had an opportunity to watch David Fifield's lightning talk on pluggable transports that he gave on 30C3. I find the topic fascinating and I'm considering an application to your project for the upcoming Google Summer of Code. My idea is a bit complicated - I'd like to create a pluggable transport that hides data in TCP sequence number gaps or UDP source port numbers. I don't yet have all details thought over, but the way I imagine it right now, the user would have to establish a TCP or UDP connection to the relay. The connection could be completely bogus, though it'd be useful if a lot of data was sent over it. After connecting, the client sends to the server a message with a random RSA key steganographically hidden in the TCP sequence numbers. If the server replies the same way with an RSA-encrypted AES key, the rest of the hidden transmission goes encrypted with it. Since the SEQ number gaps are meant to be random anyway, I believe that this could be very hard to detect. Obviously, this is a very difficult project. I'd like to point out that I already have some experience in both GSoC (worked for Nmap Project last summer, David Fifield was my mentor) and C programming. I imagine that I'd need to create some kernel-to-userspace interface that would let me do the packet manipulation - I'd probably start my research by looking at how OpenVPN implements this kind of stuff as it supports all major platforms. The main question is - would you be interested in mentoring such a project during the upcoming summer? Yours, Jacek Wielemborek

5 4

"Sniper attack" paper by Rob Jansen, Florian Tschorsch, Aaron Johnson, and Björn Scheuermann
by Nick Mathewson 09 Jan '14

09 Jan '14

Hi, all! I see that the NDSS programme is now online: http://www.internetsociety.org/ndss2014/programme One of the papers describes a neat set of attacks described in this paper where an adversary can try to track users by DoSing nodes by running those nodes out of memory. The memory DoS attack from this paper are fixed, thanks to advice from the paper's authors, in Tor 0.2.4.x and later, and we're working on improvements to the rest of our memory management as well. Rob Jansen tells me he's working on a blog post to explain the paper and its results in more detail. You can read it online at: http://www-users.cs.umn.edu/~jansen/papers/sniper-ndss2014.pdf And since there's always somebody too hasty to read past the title, I'll quote the footnote on the first page: "We disclosed our attack to The Tor Project [6] in February 2013. We have worked with them to develop and deploy a short term defense [17], and continue to work with them in developing long term solutions [32]. As a result, Tor is no longer vulnerable since version 0.2.4.14-alpha." best wishes, -- Nick

1 0

Another helping hand
by David Murray 08 Jan '14

08 Jan '14

Hi All, I'd like to volunteer time to the tor project. I can program in C and python with a modest to reasonable degree of competence. I'm not hugely familiar with the Tor codebase, so I thought that writing tests would be a good place to start. Is there any C or Python sub-project that would like someone to write some tests? David

2 2

Re: [tor-dev] [tor-reports] boklm's report for December 2013
by Karsten Loesing 07 Jan '14

07 Jan '14

[Replying on tor-dev@, because I think tor-reports@ is not meant for discussions.] On 1/7/14 12:43 AM, Nicolas Vigier wrote: > - continued to review current status of automation in tor project, and > needs: > https://people.torproject.org/~boklm/automation/tor-automation-review.html > > [...] > > - wrote some proposals for things to do in automation in coming months: > https://people.torproject.org/~boklm/automation/tor-automation-proposals.ht… Hi Nicolas, these two documents look like something you have put a lot of work into and that you're still working on. Putting them on people.tpo has a few (major, IMHO) disadvantages: nobody will learn about these documents unless they know the exact URL, nobody will be notified when they change (and therefore see that you're working hard on them), there's no history, and when you delete them (by mistake) they're gone forever. How about moving these two documents to the wiki? Possible URLs could be https://trac.torproject.org/projects/tor/wiki/doc/automation/review and https://trac.torproject.org/projects/tor/wiki/doc/automation/proposals. You could mention at the beginning that people should talk to you before editing these pages. All the best, Karsten

2 1

fuzzer for tor as a masters project
by Pietro Bempos 07 Jan '14

07 Jan '14

Hello, I was browsing the tor site in order to find an idea for my masters project in security and I came across the following: ---------------------------------------------------------------------- In your project ideas page https://www.torproject.org/getinvolved/volunteer.html.en#torCleanup You have the following : Write a fuzzer for Tor to discover security vulnerabilities. Determine if there are good fuzzing frameworks out there for what we want. Win fame by getting credit when we put out a new release because of you! ------------------------------------------------------------------------------------ I have no experience in fuzzers but I think it would be a very nice topic to learn and on the same time contribute. I see that it is possible to create a private tor network for testing https://www.torproject.org/docs/faq#PrivateTorNetwork And maybe use the command line options to have as one point of input https://www.torproject.org/docs/tor-manual.html.en Bassically I send this email for 2 reasons: 1) To see if there are ways that you guys can help me with this on the future and 2) To give me any starting tips mostly related to what type of data that would be good for testing, any other input places from where data can be fed and generally any kind of usefull info related to this. Thanks a lot and have a nice day Pietro.

2 1

Small FTE question
by George Kadianakis 04 Jan '14

04 Jan '14

Hello Kevin, I saw your recent changes to the FTE codebase. The code looks nice! I then tried to test it, but I got a bit confused by the CLI. I wanted to try the good ol' ncat test, where I put FTE in the middle, an ncat listener on the server side, and an ncat client on the client side, and throw bytes around. How would I do that with the FTE CLI? I looked at https://fteproxy.org/docs/0.2/fteproxy.html but I'm not sure how to use the server_port and client_port switches properly. Can I configure the client-side to push data to a specific destination, or is it always a SOCKS listener? Also, is there a way to make fteproxy increase its logging verbosity? Thank you!

2 3

CellStatistics circuit distribution scale could perhaps use adjustment
by starlight＠binnacle.cx 04 Jan '14

04 Jan '14

Have been running a guard for a couple of months with 'CellStatistics' and noticed that the distribution looks out of whack: cell-stats-end 2013-12-20 18:13:10 (86400 s) cell-processed-cells 1409,9,6,6,6,5,4,3,2,1 cell-queued-cells 0.44,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00 cell-time-in-queue 98,1,1,1,0,13,2,1,1,0 cell-circuits-per-decile 15199 Seems like most of the circuits with significant traffic end up in the first bucket and the remaining nine buckets are of little significance. I'm fairly certain that a relative handful of circuits account for 99.9% of the cell traffic with cell-counts in the tens-to-hundreds of thousands. Most of that bot traffic I suppose. Perhaps a log-scaled "loudness" breakdown would make sense? Nothing pressing here, just an observation and a thought.

2 1

TBB 3.5 build failure
by Steve Snyder 02 Jan '14

02 Jan '14

Attempting to build tbb-3.5.1-build1, and failing. See below for failure. I am building on a fully-updated Ubuntu v12.04LTS/x86_64 system. I am using the USE_LXC method because KVM won't work in this VMware VM. On my first attempt I did a "make all". That didn't work, so I tried "./mkbundle-linux.sh" (all I really care about is a Linux/x86_64 build) and got the same error at what seems the same point in the build process. This problem isn't listed in the "Known Issues and Quirks" section of the doc. Can anyone advise me on how to fix this problem? Thanks. ----------------------- 2013-12-28 20:08:35,138 INFO : Searching for GRUB installation directory ... found: /boot/grub 2013-12-28 20:08:35,164 INFO : Calling hook: install_kernel 2013-12-28 20:08:59,860 INFO : Done. 2013-12-28 20:09:01,503 INFO : Running depmod. 2013-12-28 20:09:01,595 INFO : update-initramfs: Generating /boot/initrd.img-2.6.32-54-server 2013-12-28 20:09:06,598 INFO : Running postinst hook script /usr/sbin/update-grub. 2013-12-28 20:09:06,735 INFO : Searching for GRUB installation directory ... found: /boot/grub 2013-12-28 20:09:06,835 INFO : Searching for default file ... found: /boot/grub/default 2013-12-28 20:09:06,842 INFO : Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst 2013-12-28 20:09:07,159 INFO : Searching for splash image ... none found, skipping ... 2013-12-28 20:09:07,261 INFO : Found kernel: /boot/vmlinuz-2.6.32-54-server 2013-12-28 20:09:07,536 INFO : Replacing config file /var/run/grub/menu.lst with new version 2013-12-28 20:09:07,605 INFO : Updating /boot/grub/menu.lst ... done 2013-12-28 20:09:07,611 INFO : 2013-12-28 20:09:07,723 INFO : Calling hook: post_install 2013-12-28 20:09:07,753 INFO : Calling hook: unmount_partitions 2013-12-28 20:09:07,754 INFO : Unmounting target filesystem 2013-12-28 20:09:11,171 INFO : Calling hook: convert 2013-12-28 20:09:11,172 INFO : Converting /tmp/tmptolHOn to qcow2, format base-lucid-amd64/tmptolHOn.qcow2 2013-12-28 20:09:27,192 INFO : Calling hook: fix_ownership 2013-12-28 20:09:27,207 INFO : Calling hook: deploy 2013-12-28 20:09:27,208 INFO : Calling hook: fix_ownership Extracting partition for lxc [sudo] password for steve: lxc-start: No such file or directory - failed to get real path for '/home/steve/buildtbb/gitian-builder/target--' lxc-start: failed to pin the container's rootfs lxc-start: failed to spawn 'gitian' lxc-start: No such file or directory - failed to remove cgroup '/sys/fs/cgroup/cpuset//lxc/gitian' amd64 lucid VM creation failed

2 1