- tor-dev - lists.torproject.org

Re: [tor-dev] Help hacking Mumble
by Matt 02 Feb '14

02 Feb '14

On Fri, 31 Jan 2014 22:17:54 +0000 Andrew F <andrewfriedman101(a)gmail.com> wrote: > Matt, have you gotten any response? > On IRC, Yawning provided me some useful recommendations for further investigation. Any progress I make on this issue will be slow-going though, and getting a fresh set of eyes on this issue would helpful indeed.

1 0

New GPG key for Runa A. Sandvik
by Runa A. Sandvik 02 Feb '14

02 Feb '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi everyone, Tomorrow is my first day as a staff technologist at the Center for Democracy and Technology in Washington, D.C. I will continue to contribute to the Tor Project in one way or another. This new key will be used to sign email from me going forward. The new key is attached and is also available on the keyservers (with a signature from my old key) at: http://pgp.mit.edu/pks/lookup?op=get&search=0x094D46E2898DB6D5 Here's the fingerprint and current subkey information for reference: pub 4096R/898DB6D5 2014-02-02 Key fingerprint = BEBA DB46 6778 5EF9 B00E D141 094D 46E2 898D B6D5 uid Runa A. Sandvik (offline long term identity key) <runa.sandvik(a)gmail.com> uid Runa A. Sandvik (offline long term identity key) <runa(a)cdt.org> uid Runa A. Sandvik (offline long term identity key) <runa(a)torproject.org> sub 3072R/AC8C6CF6 2014-02-02 [expires: 2015-02-02] sub 3072R/FC71640D 2014-02-02 [expires: 2015-02-02] - -- Runa A. Sandvik -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJS7qvsAAoJECgKOvb8cWQNT1UL/joI4P1++EIUPmudw179o+j3 4FxEV32snfYNwW9NTaQNwGODglu7EMZRQ4V1UhytXUb9P7taT0eDgiJxPIvC8Okw xZ7jmk5UnV+R37rMLuhcX1Ifwg3Z+tG0qAwJAbFhO/zZX3yTx+ZJoQBjZ4pX5SFQ qE5G7IeLUrWEAIZfm6mLp3M/kh/+8+e5MPsxrdywo9iLi3Y2IB9mO5VVb94qA5Ul l0ETWilusa9PNRD70jtWhQL6EjPS1tkKVbMFk04naDLr+74gwFAta38tJcnZtPId jZXhqpfqcxD0muaEwyvGtV2qfAxbDuDPDxVJofMeK5S5GESOe4AqLyrkMf4MPz4Z ifKFguKpYAiA4Hz9+v4AoZPhX1Zu33AV/4gfE/Q4ZHq3DtqzEkcyzvvEw9kL0pk+ lJC7+R58dJiJ7pGedG9ZCyJugyp6pujiD34RppPL90JxnP5s3V11VkBiv5ZEnB+k kvBq94TkyFD8bUncFhmh4ilkloPDOrqMcfYGl1VjGg== =KZvl -----END PGP SIGNATURE-----

1 0

Pluggable transports meeting tomorrow (Friday 31st of January 2014)
by George Kadianakis 30 Jan '14

30 Jan '14

Greetings humans, this is an email to remind you that the regular biweekly pluggable transports meeting is going to happen tomorrow. Place is the #tor-dev IRC channel in OFTC. Time is 17:00 UTC. Cheers!

1 0

Damian's Status Report - January 2014
by Damian Johnson 30 Jan '14

30 Jan '14

Hi all. This month I decided to switch from a depth-first to breadth-first approach for overhauling arm. Changes included... * Made arm PEP8 compliant. This took around a week during which sed and I were close friends. Like Stem, both pyflakes and pep8 checks are now included in arm's test runs. * Completely dropped tor_tools from the codebase. This is a neat milestone as tor_tools was a 2,700 line wrapper around TorCtl providing a friendlier API, thread safety, caching, etc. Stem provides all of these capabilities. Initially migration was simply switching tor_tools from TorCtl to Stem, but now arm works directly with a Stem controller allowing us to drop the tor_tools module completely. * Finished arm's new tracker module which provides tor resource usage, connections, and application names. It's not just much nicer code, but now has unit tests! Why am I sinking all this effort into arm? After all, it presently does pretty much what we want, right? Well, yes. And I suspect user's won't see many obvious changes in the next arm release. Rather, my present focus on arm is partly for code quality but more importantly to make sure Stem is ready for prime time. Arm and Vidalia are our two most complicated and demanding controller applications, and making a Stem-based arm release is a surprisingly good way of making sure Stem has all the pieces we need for tasks like a next-gen Tor GUI or a localhost status panel for relay operators. As I've rewritten arm Stem has improved as well. Stem changes this month included... * Added a port_usage() function for getting a description of a port's common usage. This nicely complements our other connection utils... >>> from stem.util.connection import port_usage >>> port_usage(80) 'HTTP' >>> port_usage(22) 'SSH' >>> port_usage(9418) 'Git' * Couple new Controller methods to help with NEWNYM handling: is_newnym_available() and get_newnym_wait(). * Pyflakes and pep8 are python modules so why shell out to them? We now use their APIs instead reduced the runtime of Stem's static checks by 60%. * Greatly reduced the verbosity of stem's test output. You can still get the previous, more detailed results with the '--verbose' argument. Last but not least, non-development tasks from this month included... * Finally moved doctor to its new home on cappadocicum. (#10413) * Submitted my Tor Ecosystem talk to LinuxFest Northwest... http://linuxfestnorthwest.org/2014/sessions/tor-ecosystem-developers-guide-… * Tickets for Iceland. Looking forward to seeing everyone there! Cheers! -Damian

1 0

Am I looking at the right spec for pluggable transports?
by Ox Cart 30 Jan '14

30 Jan '14

I'm interested in writing a pluggable transport for Tor. Is this spec a good place to start? https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/180-pluggabl… Cheers, Ox ----------------------------------------------------------------------------------------- "I love people who harness themselves, an ox to a heavy cart, who pull like water buffalo, with massive patience, who strain in the mud and the muck to move things forward, who do what has to be done, again and again." - Marge Piercy

4 5

Key revocation in Next Generation Hidden Services
by George Kadianakis 29 Jan '14

29 Jan '14

To achieve offline key storage in the new HS design, hidden service are using three layers of keys: (Skip the next three paragraphs if you know this stuff) Each hidden service has a "long-term master identity key". This is the key that is encoded in its onion address. Using the long-term identity key, the hidden service generates "ephemeral blinded signing" keys according to #8106. This key lasts for a short period of time (probably for a day or so; not decided yet). When the hidden service needs to make a new HS descriptor, it generates a "descriptor signing keypair" and signs it with the blinded signing key. It then includes in the descriptor the public part of the descriptor signing key as well as its signature by the blinded signing key. It finally signs the descriptor with the private part of the descriptor signing key. As described in the spec [0] this allows the HS to generate offline a bunch of blinded signing keys and descriptor signing keys, copy them to the online HS host, and let the host use those keys for the next few days or so. As a result, an attacker that owns the online HS host only gets access to the keys for a few days ahead. The attacker doesn't get access to the long-term identity keys. Of course, this doesn't solve the problem of how Hidden Services can revoke compromised keys. Having the attacker impersonate the HS even for a few days is not acceptable. Unfortunately, PKI revocation solutions are always messy and don't work really well (look at SSL's OCSP and CRLs). The question becomes how the legitimate Hidden Service can inform a client that its keys got compromised. A client that connects to a Hidden Service first fetches the consensus from the directory system, then fetches the HS descriptor from the HSDirs and finally connects to the HS. This probably means that the client should be informed of the compromise either by the directory system or by the HSDirs. If we wanted to use the directory system, we could imagine some sort of CRL scheme where hidden services notify the authorities about compromised keys, then the authorities pass the CRL to the directory servers, and the directory servers finally give the CRL to HS clients. This system might be possible theoretically, but it poses many engineering and security questions: * Are users supposed to fetch the CRL everytime they connect to a HS? This might be dangerous identifying behavior. * What happens if the CRL gets too big because the adversary fills it with fake revocations? The directory system can't handle big documents so there will need to be some sort of size limit (and old entries will need to be resetted frequently). * The list of compromised keys suddenly becomes public information. This might not be a good idea. On the other hand, if we wanted to use the HSDirs, we could imagine the HS sending some sort of revocation message to the responsible HSDirs so that they stop serving descriptors with compromised keys. Unfortunately, this scheme treats HSDirs as trusted parties, since they can simply ignore the revocation and continue passing the evil descriptor to clients. We could decrease the chance of this happening by implementing #8244 and also having the clients use multiple HSDirs to fetch descriptors. This will force the attacker to corrupt multiple HSDirs for the attack to succeed. Still the solution is not very elegant. What else should we consider? For example (crazy ideas ahead) could we solve this problem more elegantly by adding more layers of keys? Or maybe by adding yet another network entity which handles revocations [like in Dan Boneh et al. "A Method for Fast Revocation of Public Key Certificates and Security Capabilities." paper (be aware of crazy crypto)]? Or maybe we could look into certificate transparency; although transparency for centralized PKIs (like SSL-CA) sounds like a good idea, transparency for decentralized PKI systems with complex privacy threat models might not be a good idea. [0]: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/224-rend-spe…

2 1

Fwd: [OpenITP Dev] Python & Javascript volunteer?
by Griffin Boyce 29 Jan '14

29 Jan '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenITP & TA3M have had a python dev ask if STEM or txtorcon need assistance =) For more details, talk to Sandy (SandraOrdonez(a)openitp.org) ~Griffin - -------- Original Message -------- Subject: [OpenITP Dev] Do u needa Python & Javascript volunteer? Date: Wed, 29 Jan 2014 10:45:46 -0500 From: Sandra <SandraOrdonez(a)openitp.org> Organization: OpenITP To: dev(a)lists.openitp.org I've started asking at TA3M if people are interested in volunteering to shot me an email with qualifications. Do any of your projects need someone like this "....You said I should shoot you an email since I was one of the women in New York and also to get involved volunteering. I would like to help with development for one of the projects - I am currently programming in Python and JavaScript - I do Django development, and I have some background in security. I saw on the site that stem and txtorcon are in Python - do either of those groups need assistance? Also feel free to ask if you guys need help with set up or organizing local events. Let me know, I'll make intros :) _______________________________________________ Dev mailing list Dev(a)lists.openitp.org https://lists.openitp.org/mailman/listinfo/dev -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJS6SLCAAoJEAPPSgqzx5pjUUEH/1ybIOkHrUxnkBs0Sjmu4TP9 O/zsPLFFnGFOvDFrQCsv8nErNTgeSivpTT9I2+4FeIpDu4VEEdwnyCOe7qpAZE63 sef/zX2oZaMPAlM8Fbyjz1jUCUXgo1SsSFGpEGK35WiQi1O3Xa5kbBRn05oc7jvU Qspjd9wf/C6A23usK2Jq3XA7/sJf8oCXl+f6zBXTb+yhXJX+ZqunwYb6Xks2De3U pzTaOuVChcmlfFGTwPKND1io4Bhx/coi3+ANg2fNvHkyTLZRLHly7TkjRhc34lPs 9hCeMsfjoPHqFNu1zUSZ+qTmcmMtSiY/SaG8Kmkpz5UeCgkCWJR23VksTiXAiP4= =PWtb -----END PGP SIGNATURE-----

2 1

Tor-Weather-Rewrite Progress
by Abhiram Chintangal 29 Jan '14

29 Jan '14

Hello Guys, Here is the progress from my side. I have written a simple python helper module for Onionoo communication, mostly inspired by "stemUtil" module from the current weather implementation. For now, it checks for new documents with Onionoo and exposes the data through some simple functions. I guess once it done, I should be able to test it with the django app. Let me know if you have any questions. Thanks! -- Abhiram Chintangal

2 1

Making microdescriptor tarballs available on metrics.tpo
by Karsten Loesing 29 Jan '14

29 Jan '14

Hi Damian, hi devs, I'm planning to make microdescriptor tarballs available on the metrics website that contain both microdescriptor consensuses and microdescriptors. Some background: Recent Tor clients don't download the network status consensus and full server descriptors anymore, but instead download the microdescriptor consensus and the microdescriptors referenced from it. We didn't provide these formats on the metrics website yet, because they are derived from the formats we already provide and don't contain anything novel. But having the new formats will, for example, make it easier for developers to analyze the directory protocol and for researchers to understand what information is available to clients to make path selection decisions. If you need more background, see #2785 and search for "microdesc" in dir-spec.txt. Here's a sample tarball: https://people.torproject.org/~karsten/microdescs-2014-01.tar.bz2 Damian, can you try to parse these descriptors using stem, to see if the descriptor annotations are correct and if stem can parse them without issues? If all goes well, microdescriptor tarballs will start to be available on the metrics website before the end of the month. All the best, Karsten

2 3

unable to decode onionoo's details document
by Abhiram Chintangal 28 Jan '14

28 Jan '14

Hello Karsten, Since the last once hour, I am seeing "No Json object to be decoded" with the Onionoo's details document. However, the remaining documents ( summary and bandwidth) seem fine. Any Ideas? -- Abhiram Chintangal

2 1