- tor-dev - lists.torproject.org

Directory Server Consensus Status Flag
by Matthew Finkel 21 Mar '15

21 Mar '15

Hi all, I'd like some opinions. Currently authorities give relays the V2Dir if they are useful directory servers. Clients don't actually care about this flag in any way, but it's a useful visual indicator. With proposal 237 (All relays are directory servers) and #12538 as its implementation, the current plan is to continue using the V2Dir flag, but now clients will actually care if a relay has the V2Dir flag and choose directory servers based on it. Tickets #11103 and #1338 actually wanted to get rid of the V2Dir flag, for good reasons. If we're going to rename the flag, we should do it before #12538 is merged, and probably make the change in the same branch. The V2Dir flag needlessly specifies an unuseful protocol version. #1338 suggested switching to a V3Dir flag, but it was decided this was not such a good idea. Proposal 185 chose a "DirCache" Consensus flag. I think either "DirServer" or "DirCache" are good choices for this, but DirServer is more in line with the wording used in Prop 237. Are there any objections to changing the name of the flag? (There will be another email in a few minutes with an updated version of prop 237.) Thanks! Matt

1 0

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

21 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 19 Mar '15

19 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 19 Mar '15

19 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