March 2015 - tor-dev - lists.torproject.org

Wide block cipher experiment.
by Yawning Angel 19 Mar '15

19 Mar '15

Hello, Nickm mentioned to me that he was curious as to how LIONESS performs these days (See #5460) with modern cryptographic primitives. I've conveyed the results to several people, but I'm also sending them here for posterity. Code used: https://github.com/yawning/lioness (May be incorrect, don't use for anything other than benchmarking. Numbers taken with a previous version of the code without the initial memcpy, that was added later so that the code in git could be used by the extremely brave for other things.) All measurements taked on an i5-4250U, so the usual caveats about turboboost and hyperthreading apply. Baseline (from tests/bench, AES-NI enabled): ===== cell_ops ===== Inbound cells: 231.33 ns per cell. (0.45 ns per byte of payload) Outbound cells: 224.39 ns per cell. (0.44 ns per byte of payload) (Note: Outbound with AES-NI disabled is ~3.0 ns per byte) LIONESS (BLAKE2b/ChaCha, 509 byte block size): * ChaCha20: * Ted Krovetz's AVX2-ed ChaCha20/Ref AVX BLAKE2b: ~6.6 ns/byte (~143 MiB/s) * AVX2ed-ed ChaCha20, Andrew Moon's AVX2-ed Blake2b: ~5.0 ns/byte (~190 MiB/s) * ChaCha12: * Ted Krovetz's AVX2-ed ChaCha12/Ref AVX BLAKE2b: ~6.1 ns/byte (~156 MiB/s) * AVX2ed-ed ChaCha12, Andrew Moon's AVX2-ed Blake2b: ~4.4 ns/byte (~213 MiB/s) * ChaCha8: (Yolo swag 420 blaze it) * Ted Krovetz's AVX2-ed ChaCha8/Ref AVX BLAKE2b: ~5.8 ns/byte (~164 MiB/s) * AVX2ed-ed ChaCha12, Andrew Moon's AVX2-ed Blake2b: ~4.1 ns/byte (~232 MiB/s) NB: Using Andrew Moon's Blake2b isn't in git, because the way I tested it was kind of kludgey. Profiler output: 64.04% lioness_test_av lioness_test_avx2 [.] blake2b_compress 22.43% lioness_test_av lioness_test_avx2 [.] chacha_stream_xor 6.60% lioness_test_av lioness_test_avx2 [.] blake2b_init_key 2.72% lioness_test_av lioness_test_avx2 [.] blake2b 2.41% lioness_test_av libc-2.21.so [.] __memcpy_avx_unaligned 1.07% lioness_test_av lioness_test_avx2 [.] lioness_encrypt_block Ted Krovetz's ChaCha implementation isn't quite the fastest out there, but it doesn't lag massively behind Andrew Moon's. Benchmarks on the same hardware from Andrew Moon's chacha-opt/blake2b-opt are: BLAKE2b: 576 byte(s): avx2, 1468.00 cycles per call, 2.5486 cycles/byte avx, 1674.00 cycles per call, 2.9062 cycles/byte x86, 2020.00 cycles per call, 3.5069 cycles/byte generic/64, 2638.00 cycles per call, 4.5799 cycles/byte ChaCha20: 576 byte(s): avx2, 694.00 cycles per call, 1.2049 cycles/byte avx, 1104.00 cycles per call, 1.9167 cycles/byte ssse3, 1112.00 cycles per call, 1.9306 cycles/byte sse2, 1376.00 cycles per call, 2.3889 cycles/byte x86, 2528.00 cycles per call, 4.3889 cycles/byte generic, 3200.00 cycles per call, 5.5556 cycles/byte I don't think using CTR-AES (with AES-NI) in a LIONESS construct is going to be that big of a win, at least on my hardware, and the sort of performance I'm seeing feels too much of a performance hit to me. Regards, -- Yawning Angel

1 0

Fwd: Intent to Ship: 3rd Party Install Tracking
by Nathan Freitas 18 Mar '15

18 Mar '15

Another thing to remove/disable from Tor Browser "Mini" (aka Orfox)... ----- Original message ----- From: Mark Finkle <mfinkle(a)mozilla.com> To: "mobile-firefox-dev(a)mozilla.org" <mobile-firefox-dev(a)mozilla.org>, "dev-platform" <dev-platform(a)lists.mozilla.org> Subject: Intent to Ship: 3rd Party Install Tracking Date: Wed, 18 Mar 2015 14:28:57 -0400 We wanted to start some transparency around a new integration coming to Firefox on Mobile [1]. We are planning to integrate a 3rd party install tracking SDK from a company called Adjust [2] which will send data, possibly device identity data [3], to a 3rd party server. We don't do this very much at Mozilla so we wanted to be proactive about messaging. There are good reasons for wanting to collect the data. Our marketing and growth goals for 2015 will require spending non-trivial amounts of money. The data will help us spend the money responsibly and efficiently. Advertising metrics on Mobile is not as simple as some Desktop systems. On Desktop, we can do most of this using the download links on our web pages. Mobile installs come from App Stores, and it's harder to integrate into those system. This is Mozilla, so we are worried about integrating the SDK from a privacy and tracking concern. The goal is to limit the data to non-PII sensitive information and we'll only allow the data to be pushed once, on an INSTALL_REFERRER intent [4] sent when Firefox for Android is first run after being installed from the Play Store, and only when the install is coming from an advertising campaign. No other data will be sent at any other time. Normal installs from the Play Store would not have any data collected. We still need to audit the open source SDK to see exactly what data is sent and how it's collected. We also have started doing a security/privacy/legal audit of the vendor and their collection/storage practices. Just a note, this is not the first attempt to add such 3rd party data collection to Firefox on Mobile. The other attempts did not happen because we found flaws in the systems or the system failed to meet our concerns about privacy. The proposed system seems to have a decent chance of passing our audits around privacy and security, so it's time to open the discussion to a wider audience. Here are some other notes about the Adjust system: * This is an open source SDK, fully transparent, based in Germany, widely adopted and regarded, beholden to the strictest EU privacy standards. * We will collect the absolute minimum data, once, to measure for install. We’ll know exactly what data is being passed. * We’re paying for the SDK and service, which is good because the vendor's model is not based on monetizing our data in aggregate to develop behavioral segments for other advertisers. * This will allow real-time optimization of marketing dollars, much like virtually all major mobile apps do, and much like we have already been able to do on paid marketing desktop for quite some time * We likely use this system until we can figure out how to do it by ourselves, in house. Until then, we need to be pragmatic. This is just a heads up email. We want the effort to be open and transparent. Questions and comments welcome. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1143888 [2] https://github.com/adjust/android_sdk [3] The SDK requires the use of the Google Advertising ID to uniquely track the device [4] https://github.com/adjust/android_sdk/blob/master/doc/referrer.md _______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev(a)mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev -- Nathan of Guardian nathan(a)guardianproject.info

1 0

What's the explanation for weekly cycles in user graphs?
by David Fifield 18 Mar '15

18 Mar '15

When you look at the user graphs, many of them show a weekly cycle. What's our explanation for why this occurs? I notice it strongly when I look at the graphs for the meek pluggable transport, where usage is high on weekdays and lower on weekends. The same thing happens in some per-country graphs. (In all these graphs, the light white vertical lines are Mondays.) https://metrics.torproject.org/userstats-bridge-transport.html?graph=userst… https://metrics.torproject.org/userstats-relay-country.html?graph=userstats… https://metrics.torproject.org/userstats-relay-country.html?graph=userstats… You can eyeball more examples in the omni-graph: https://people.torproject.org/~dcf/graphs/relays-all.pdf But it doesn't look like that everywhere. Here are graphs for obfs3 and the United States: https://metrics.torproject.org/userstats-bridge-transport.html?graph=userst… https://metrics.torproject.org/userstats-relay-country.html?graph=userstats… And there is perhaps even the opposite pattern, where there are small peaks on the weekends, like in Germany: https://metrics.torproject.org/userstats-relay-country.html?graph=userstats… Is there a usual story we tell to explain what's happening? A few hypotheses: * People use Tor at work to get their job done (work firewall blocks sites they need). * People use Tor at work to goof off. * People are relaxing and partying on the weekends, not sitting in front of a computer. * People don't have good Internet at home, so they use it more at work (and Tor use just correlates with Internet use). George Danezis's tech report on discovering censorship events describes the weekly patterns but doesn't offer a cause. https://research.torproject.org/techreports/detector-2011-09-09.pdf "The deployed model considers a time interval of seven (7) days to model connection rates... The key reason for a weekly model is our observation that some jurisdictions exhibit weekly patterns. A 'previous day' model would then raise alarms every time weekly patterns emerge" David Fifield

2 2

#15349 Symbol "str_tools" not defined "Tortoise and the Hare" tutorial's script.
by Lluís 18 Mar '15

18 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi everyone, I opened the ticket #15349 about a bug in the "Tortoise and the Hare" stem tutorial's script. I think I've found the solution to it and I attached the corrected script to the ticket. I hope it helps. May I expect some kind of feedback about the ticket ? Lluís -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVCWEbAAoJEJOS0D3m/rNlQoIQAJUVd68wbcZ54BgFaDrI3/oc Bq2WsTTjaXfu1eoCQV445UEVgcSVGySZUjygAKaJ+i+QBQNIk+Nz7Xh/OLyvyHGq 38p5WCJHOBwT2bGjojdmEAF1g/wX3M0WZPAs3mErOTTUdVq6Iari7GSProVhBWeh KME4rZ9NqWIlaxE3jn/53bnAHdXqb8OWagPasei8KtMop3i3vlkmjuG/xdU2QGPJ bHFi2oGGVMPp10/v8t4vVVusH2JQYCxypxg1aXDOGFioFWgFEzzgXOg08XNsCK4J jy5t00yb5BjzaJEkjyowd1AxdqLEbwy7XhiHYb23DFurHezMaYjBxTj8jSllDeT7 cz+4Hpo0yAcozqENAwKYd7QQdO2XhvlWHq0Xg3YbfymKW23a3nu85u1+Y0kbiPJE pc3ZhOPxAFujmj6ob06AJsw6efDjm5kH9yPYRh02mDZtsuetttCXil/NSftFdh2i yOoJo4EO9mrWMoacoF4vFWiiBBD6zlybWTAVWJiFKaZu1/1TRHZwjX8E3jV5xXUd IMpLmuzviTYBfpWSm+llkKCGCrNdy1Uk2qa8uFBfOsXniOwMPKk6YDnAN6gcuTWy pxqsOzGvTNjpsYrXeGCa+aep3yesGDPSY5sLgOF3V1Nj9gtnyUq9s3WQsIr2rzbn a4VSB7j8RPjSlMc+nkXc =5Ebl -----END PGP SIGNATURE-----

1 0

#14995: adding multi-instance support to debian packages (patch)
by Nusenu 17 Mar '15

17 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Weasel, many relay operators run multiple tor instances to overcome certain limitations. Currently the official deb packages do not come with an easy configurable way to run multiple tor instances. I created a ticket [1] and wrote a patch [2] to add such a functionality to the debian package while preserving the current behavior. A similar enhancement got submited to the RPM packages and is now shipped in RPMs since tor 0.2.6.4-rc [3]. It would be great if you could find some time to review and comment on #14995 - before tor 0.2.6.x gets released. thanks! Nusenu [1] https://trac.torproject.org/projects/tor/ticket/14995 [2] https://github.com/nusenu/tor-multi-instance-initscripts/blob/master/debian… [3] https://trac.torproject.org/projects/tor/ticket/14996 https://lists.torproject.org/pipermail/tor-relays/2015-March/006605.html -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVBuQFAAoJEFv7XvVCELh0hHcQAKmAHfmu4zlA3lwg+4IJCMgr cu77F8PkGTS4j9I5Sg3WjTg3xSPTwK3KOmWz3a5SOlQNLfo/LnzEB4owGg9Q7Q95 AdCMuh7zipsrZuENjv0gbbVRsv+hopimFQOypPj7pbi6+3tL/x0T4cStiUcx43No 7RnvIKpm1QDBNGhwwCWrQglH+T+h+XKb0JjaAS9zuP9FEAt2/JkEwmUAGScxnhF1 xFYR2i3EkKx7eX7Z4TE0wIDx+Q2UDr4/KcK3ZYbFEg24aKn75Iqs6HUOMOZB/JSY viJ2Y6q/M5j8zNcwSQ9herZDb0D6s0TYmvWf0XZnJAKeoKR7WgFuUvZuY35Ka/Y7 oHalTFgCTx5mw4CIvvMe0ybMQHTYdkb8CWOyWcC+F+LaH9TQ1yqlDi9zgZ5VWk29 nOwXQoiZNW1w3mJJzdqKuhsNAQytCcWMkWnBrDK+lCfN0WWWFxGlO75rTO7q9VuC 3VbmXcZJLhQquvfnHtqJOFheyIiWhuw+f+czJMvkmgdiQ4D346OlkBkePdpY9Ebs gI7W0Q5SAUiKWvRQKlvNav961ciYGWGckFsXL0lNxxHT2pN1Yz4+2EF32yBQ38hu aErK9Ouy973Qzy+ZhyDveOEoNvgGA2VyEXPK8ipfEFxP/ckdlcS3tw7AlcU78VT0 8zutjeDy+AoiazIrUCYj =OeBF -----END PGP SIGNATURE-----

2 4

0.2.7 triage meeting
by isabela 17 Mar '15

17 Mar '15

Hello people! As you might have noticed at our roadmap [0] we have the following task: * Initial ticket triage + schedule for 0.2.7(due by March 20th) At the last Core Tor weekly IRC meeting we asked people to add the label 0.2.7 to the work they want to see done for the release. The only guideline so far is to also look at other's roadmap and keep their needs in mind as you decide what should go on the next release. We plan to start triaging this at the end of the next weekly meeting (Wed 3/18) and will probably need another meeting to finish this initial ticket triage. I am trying to figure out when is a good time to have the 'second round' of triage and that is why I am sending this note. Please look at the poll and let us know when is a good time for you: http://doodle.com/3e9223rb3q7uffd9 Thanks, Isabela [0] https://trac.torproject.org/projects/tor/wiki/org/roadmaps/CoreTor

2 2

Pluggable transports meeting tomorrow (16:00 UTC Wednesday 18th of March 2015)
by Yawning Angel 17 Mar '15

17 Mar '15

(Trying to get these back onto a regular schedule now that dev-meeting madness is over.) Just wanted to remind you that the regular biweekly pluggable transports meeting is going to occur tomorrow at 16:00 UTC. Place is the #tor-dev IRC channel in the OFTC network. https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports#Plugg… -- Yawning Angel ps: UTC does not do daylight savings. Those of you that have had clocks change, please double check the time and let me know if we need to change the time.

1 0

tor not starting with NoNewPrivileges = yes (systemd)
by Nusenu 17 Mar '15

17 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I'm currently preparing/testing a systemd unit file (#14995) for debian (wheezy-backports/systemd 204) based on the one shipped by tor [1]. It does not work yet, and although the 'fix' would be easy - simply remove: NoNewPrivileges = yes I'd like to hear from you before removing such a security feature. Does tor require new privileges to work? It actually fails in two instances: 1) before actually starting the tor daemon (--verify-config): Process: 2844 ExecStartPre=/usr/bin/tor -f /etc/tor/torrc - --verify-config (code=exited, status=227/NO_NEW_PRIVILEGES) 2) and when actually starting the daemon thanks, Nusenu I'm testing with 0.2.5.10-1~d70.wheezy minimal test torrc used: User debian-tor DataDirectory /var/lib/tor Log debug file /var/log/tor/log [1] https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in#n25 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVCE4hAAoJEFv7XvVCELh0AsMP/2DhEt+oLcSyN0w5pN6iyy2B O3WI+k4ZpC+OVKtRdQPcdmiCodo4So70ZGN3qEJKDTVLHW1YFn2p7z0a57OvYvkA SfQEy6yilQ1cUUMYUNj34WOdsq/tKDSmWQnJRvSUkdt1G2/WUJ14t0NRdR0KIzy0 bFQUYSkp2mnal8GpAldhx5q8P7zRlnf/fJC2gsQMJEEtPFwTGAl++cZ1mvuf00zk TsLo0L4BJ4EkAA4txJ8aihbYVZI0mJn2rWSc9OHVElNNiSYN2+d1k3bhCZHY/K2N yFnYY1lqoBcpmHakSOs2NqJx7arSMZY59oFR4Z9qBK+bpFQohzwOmV47Qfj8vahV CkDEIlh9OAYn59MahsBGJFMl/lSEVSAD60ZcTb3tveJEDSFtBJx9ey0P21MTlukh b+JUjc28UmNxLwHz/2bpe4+RZ0qKY2g+NnlbupNU+FUZGH9aiAxvpVKzFcxwvh6n wFiiRnQ8wWMZSMB5iOvltjt8jtxy2cvLrDypbsyEI28CdTuqAD+V0DrAn91Qyd2G aQwW+XkplwgiX8lVS8pno8P+EpAEoN1av8R2IVayN4zsp/IkgTff2W6GzTm4jQIB eL3vJz5OaK8q32wABNIMq7kaKs2O8VLbuxilZMDb0dmSozTQwNztpUsJFTiOZpbG yJllYQDwN3VuDBO9QXGY =osrb -----END PGP SIGNATURE-----

2 4

RAPTOR: Routing Attacks on Privacy in Tor
by Prateek Mittal 17 Mar '15

17 Mar '15

All, Our team at Princeton has been working on "Raptor: routing attacks on privacy in Tor". These attacks can be launched by Autonomous System (AS)-level adversaries, and exploit the dynamics of inter-domain routing. We show that by exploiting routing asymmetry, routing churn, and routing vulnerabilities (such as BGP hijacks and BGP interceptions), user anonymity can be compromised much more effectively than previously thought. We evaluated these attacks using historical BGP and Traceroute data, as well as by performing real-world attacks on the live-Tor network, without harming real Tor users. Our technical report is available at: http://arxiv.org/abs/1503.03940, feedback is most welcome. While all of our attacks have consequences for user anonymity, attacks based on BGP interceptions are particularly dangerous for the Tor network. These attacks allow an adversary to intercept Tor traffic "on demand", regardless of the adversary's network location. Our work demonstrates such an attack -- with success, on the live Tor network. We find that 90% of the Tor relays have a BGP prefix shorter than /24, enabling an adversary to advertise a more specific prefix for them, which is propagated *globally*. Countermeasures against interception attacks are challenging: we outline a number of ideas including advertising Tor relays with /24 prefixes, building frameworks to monitor the control plane and dataplane of Tor relays to detect such attacks (we have started to build such monitoring frameworks at Princeton), and in the long term -- aiming to speed up the deployment of secure inter-domain routing protocols in the Internet. Thanks, Prateek -- Prateek Mittal Assistant Professor Princeton University http://www.princeton.edu/~pmittal/

1 0

Syncing the Tor+TBB release schedules?
by Mike Perry 16 Mar '15

16 Mar '15

On #tor-dev on IRC, I noticed Nick and Mark discussing trying to sync the release schedules of Tor and TBB. I replied to Nick there with more info, but it may be lost in scrollback. So I'm restarting the discussion here. This email should give everyone on the tor-core side more info than they ever wanted to know about the Tor Browser release schedule. For Tor Browser, we are rather tightly bound to Mozilla's release schedule on two timescales: a 6 week point release cycle, as well as a 42 week Extended Support Release cycle. You can see this release schedule here: https://wiki.mozilla.org/RapidRelease/Calendar#Future_branch_dates. Note that schedule only lists the Rapid Releases, but there are Firefox 31-ESR point releases (with security fixes) on the same day as all Rapid Releases. This is where our 6 week cycle comes from for Tor Browser, and it is why we will always have a release on the same day as those Rapid Release dates. In terms of merge deadlines for our releases, Mozilla tags the all releases one week prior to the actual release date. This means we typically code freeze both TBB stable and alpha one week prior to release, and begin building off of their new tags at that point. This also means that the deadline for Tor Browser picking up a new Tor or PT version is also roughly 1 week prior to those release dates. The 42 week cycle comes from the Extended Support Release switch-over. Every 7 Rapid Releases, Mozilla creates a new Extended Support Release (ESR) series. We are currently on Firefox 31-ESR. The next ESR is 38-ESR. Note that the release calendar page lists Firefox 38 beta as due on March 31st, and Firefox 38 as due on May 12th. We then have 2 more rapid release cycles until Firefox 31-ESR is officially end of life. This means we have until August 11th to rebase all of our patches, audit and review Firefox 38, and write more patches for any issues we discover. So, how do these releases map to our upcoming TBB releases in terms of our versioning and stabilization? Well, our plan for 4.5-alpha is to freeze on March 26th, and then release TBB 4.5a5 on March 31st. We hope to declare 4.5 stable soon after that (~2 weeks). It seems by coincidence, Tor 0.2.6.x should be stable roughly around that time as well. The reason why we are releasing 4.5-stable out-of-cycle is to provide a 1 month grace period for people to still be able to run TBB 4.0 in case there are any catastrophes hiding in 4.5. After that (in mid-April), we will branch a new alpha series (5.0-alpha), which will target the next Firefox ESR release, based on Firefox 38. This means that from April until Aug 11th, the TBB team will be mostly focused on the switch to FF38-ESR (reviewing changes, updating patches, fixing tests, notifying Mozilla of patches they might like, etc). On https://trac.torproject.org/projects/tor/wiki/org/roadmaps/CoreTor, I notice that we currently have Tor 0.2.7 scheduled to be stable by mid-Sept, which is slightly out of sync with a goal of shipping the FF38ESR-based Tor browser and Tor 0.2.7.x-stable together on August 11th. This may place us in the weird position of shipping a TBB 5.0-alpha with 0.2.7 and FF38 for most of the FF38ESR stabilization period (April-Aug 11), and then having to decide if we want to just roll the dice on 0.2.7, or roll back to 0.2.6. Obviously both options will carry some risk of instability. As fair warning, I am very likely to decide that it will be better to ship 0.2.7.x in TBB 5.0-stable on Aug 11th, as I suspect that the risk from things like PT compatibility and control port compatibility issues will actually make a rollback to 0.2.6 more risky on balance than sticking with 0.2.7.x. -- Mike Perry

3 7