- tor-dev - lists.torproject.org

Call for a big fast bridge (to be the meek backend)
by David Fifield 22 Mar '15

22 Mar '15

The meek pluggable transport is currently running on the bridge I run, which also happens to be the backend bridge for flash proxy. I'd like to move it to a fast relay run by an experienced operator. I want to do this both to diffuse trust, so that I don't run all the infrastructure, and because my bridge is not especially fast and I'm not especially adept at performance tuning. All you will need to do is run the meek-server program, add some lines to your torrc, and update the software when I ask you to. The more CPU, memory, and bandwidth you have, the better, though at this point usage is low enough that you won't even notice it if you are already running a fast relay. I think it will help if your bridge is located in the U.S., because that reduces latency from Google App Engine. The meek-server plugin is basically just a little web server: https://gitweb.torproject.org/pluggable-transports/meek.git/tree/HEAD:/meek… Since meek works differently than obfs3, for example, it doesn't help us to have hundreds of medium-fast bridges. We need one (or maybe two or three) big fat fast relays, because all the traffic that is bounced through App Engine or Amazon will be pointed at it. My PGP key is at https://www.bamsoftware.com/david/david.asc if you want to talk about it. David Fifield

6 11

Re: [tor-dev] Fwd: [guardian-dev] Orbot v15 alpha 5 is out: MeekObfs4VPNQRCodez!
by Nathan Freitas 20 Mar '15

20 Mar '15

On Fri, Mar 20, 2015, at 04:05 AM, isis wrote: > Nathan Freitas transcribed 0.8K bytes: > > On Thu, Mar 19, 2015, at 06:58 PM, David Fifield wrote: > > > What would it take to get some screenshots that show how to turn on > > > pluggable transports? I would like to add a guide to > > > https://trac.torproject.org/projects/tor/wiki/doc/meek#Quickstart and > > > instructions to > > > https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports#Howto… > > > . > > > > > > Or do you have such a guide I can just link to? > > > > > > > We're still finalizing the UI for the new features (QR code scanning, > > meek bridge type selection, etc) so once that is completed, we'll do a > > round of screenshots, guide updates, etc. This will most likely happen > > in early April. > > Wow, this is awesome! Great work, to all of you! > > Let me know if there's anything more I can do to help. In thinking about how users on phones/tablets will actually get obfs3/4/scramblesuit bridges, I realized that going to https://bridges.torproject.org on their mobile device will not be a great experience. The QR code scanning if they or a friend also has a PC, but in a pure mobile environment, it doesn't help so much. I can create a ticket for this, but just to lay out the idea, I think we need to have the bridge:// (or the improved proposed obfs4:// obfs3:// type specific scheme URLs) as a clickable link in both the bridges.tp.o site and the gettor email response messages. +n

2 1

Remove "*" from pluggable transports spec?
by David Fifield 20 Mar '15

20 Mar '15

I was going to write an email advocating for the removal of the wildcard '*' transport specification in pt-spec.txt. But then I saw that the current version of the spec doesn't mention the wildcard anymore; it was replace with a TODO in https://gitweb.torproject.org/torspec.git/commit/pt-spec.txt?id=4dcd7e94f17… "TODO: Document '*' transport" So how about we remove the TODO and just act like it never existed? Normally tor tells the transport plugin what transports to activate by giving it a string like "obfs3,obfs4"; but you're supposed to also be able to pass "*", which means "activate all transports you are capable of." Apparently this feature, though pyptlib and goptlib support it, has never been implemented in tor itself: Implement the wildcard "*" protocol in {Client,Server}TransportPlugin lines https://trac.torproject.org/projects/tor/ticket/3725 A wildcard specification doesn't really make sense, anyway. For one example, flashproxy-client knows two transport names, "flashproxy" and "websocket", which are synonyms. But if tor asks for "*", flashproxy-client shouldn't open up two listeners. Another case is fog (a dynamic transport combiner), which constructs a chain of transports from a transport name like "obfs3_websocket". The transports can be combined in infinite ways; it doesn't make sense to say, "activate all of them." https://lists.torproject.org/pipermail/tor-dev/2013-December/005966.html Let's just drop this part of the spec, and delete some underspecified and unused code? David Fifield

2 1

Re: [tor-dev] Fwd: [guardian-dev] Orbot v15 alpha 5 is out: MeekObfs4VPNQRCodez!
by Nathan Freitas 20 Mar '15

20 Mar '15

On Thu, Mar 19, 2015, at 06:58 PM, David Fifield wrote: > What would it take to get some screenshots that show how to turn on > pluggable transports? I would like to add a guide to > https://trac.torproject.org/projects/tor/wiki/doc/meek#Quickstart and > instructions to > https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports#Howto… > . > > Or do you have such a guide I can just link to? > We're still finalizing the UI for the new features (QR code scanning, meek bridge type selection, etc) so once that is completed, we'll do a round of screenshots, guide updates, etc. This will most likely happen in early April.

2 1

thanks redditt
by Tyrano Sauro 20 Mar '15

20 Mar '15

2 1

Fwd: [guardian-dev] Orbot v15 alpha 5 is out: MeekObfs4VPNQRCodez!
by Nathan Freitas 20 Mar '15

20 Mar '15

----- Original message ----- From: Nathan of Guardian <nathan(a)guardianproject.info> To: guardian-dev(a)lists.mayfirst.org Subject: [guardian-dev] Orbot v15 alpha 5 is out: MeekObfs4VPNQRCodez! Date: Thu, 19 Mar 2015 11:12:59 -0400 Orbot v15 alpha work is nearly done... APK: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-5.apk SIG: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-5.apk.asc Highlights: * Updated to tor-0.2.6.4-RC * VPN / full device "Apps" mode is fully implemented and stable - no root needed to run all apps on your device through Tor * Meek and Obfs4 pluggable transports are now included and working quite well, even with the VPN mode * Easy scanning and sharing of bridge address QR codes from bridges.torproject.org * Removed integrated webview/webkit for now, since Android WebView is generally p0wn3d More at: https://gitweb.torproject.org/n8fr8/orbot.git/tree/CHANGELOG Thanks to nickm, isis, yawning, fifield, sandro, team psiphon and many others for all the various amazing pieces coming together to make Orbot v15 a very important and big release. +n -- Nathan of Guardian nathan(a)guardianproject.info _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscribe(a)lists.mayfirst.org

2 1

Performance and Security Improvements for Tor: A Survey
by Ian Goldberg 20 Mar '15

20 Mar '15

As I mentioned at the dev meeting, Mashael and I were just finishing up a survey paper on Tor performance and security research. The tech report version was just posted on eprint: https://eprint.iacr.org/2015/235 for your perusing pleasure. ;-) Thanks, - Ian

8 9

Producing automated screencasts for Tor Browser
by Karsten Loesing 19 Mar '15

19 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi devs, we're making some medium-term plans to produce automated screencasts that explain how to download, verify, and run Tor Browser on Windows, Mac OS X, and Linux, localized to at least half a dozen languages. The focus here is really on *automated*. Whenever there's a new Tor Browser version, we'd like to minimize manual steps for creating new screencasts to the absolute minimum. Here's our plan, and we'd appreciate your feedback on this: 1. Set up three systems (Windows, Mac OS X, and Linux) either as virtual machines, using VirtualBox or VMware Fusion, or on a dedicated triple-boot Mac Mini. 2. Install Sikuli (http://www.sikuli.org/; thanks for Lunar for the suggestion!) either directly on these machines or on the virtual machine host or on a separate host in the same network. 3. Write a Sikuli script for each operating system and language, probably re-using large parts, to make all the necessary steps to download, verify, and run Tor Browser. This script may include steps for preparing the system by changing its language and for cleaning up afterwards. Ideally, this script can easily be maintained whenever Tor Browser changes. 4. Record audio snippets in the various language that explain the steps that will later be performed in the screencast. Either include these as part of the Sikuli script, or put them together separately and add them to the recording later. 5. Start a screen recorder and run the Sikuli script for all three systems and all supported languages. 6. Post-process the recording by cutting the video, attaching the audio, and possibly adding text slides at beginning and end; hopefully using scripts. Again, the goal is to keep the overhead for recording a new set of screencasts as low as possible. If it takes days to do this, nobody will do it, and we'll soon have outdated videos. What do you think about this plan? And do you have specific suggestions for the single steps? Thanks! Cheers, Karsten and Sherief -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVCp9HAAoJEJD5dJfVqbCrfTEH/2oTPvEYIZDys42MeKXmQFA9 bmVMky5sCO6/sOAx8BIVdUXF1b1m8mxPev5X2SarYCyNaZOkbtCOLyLzrFjUii0e aH7cjc6QFm31TX5oJ10O7/7Of13q4l0jYY2j0KDmzbFrNndK9t9W+nh4/xSiTdEh a3IzVnOVu4c1nE4xwCSxwqaia2xi5N8fUuZPN4ttGGVctp4ucglUwTCZodfqNUMK Jiq4UO+ZeGvPaRGPLK8sxCfnR5DrZF5i3v4YhYy5d1g0yGDNFHv61zP1PQHx3BCG 47ne5o+FDsxLxDe1w4/l7i4HvdPHP7XovkR4yckYs/6e4462QUfBxVcwIm9p6rk= =E8Kf -----END PGP SIGNATURE-----

3 2

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