- tor-dev - lists.torproject.org

Proposal: Link Cryptographic Agility
by Yawning Angel 16 Nov '15

16 Nov '15

Hello, There's been talk of moving to a wide block construct for cell crypto (#5460), and for adding PQ Forward Secrecy to traffic (#17272). To facilitate this, there needs to be a method for negotiating which primitives a given relay supports. To that end, here's the begining of a proposal (tentatively #260) that adds a `CIPHERSUITES` cell to the version negotiation process which allows relays to advertise the link cryptography primitives that they are willing to accept. TODOs/TBD: * Should the new cell be variable length? Our development cycle and how often we switch handshakes/link crypto tells me "No", the existing "VERSIONS" cell format tells me "Yes". * We need to revise prop. 249 to add a cell crypto method specifier to CREATE2V/EXTEND. * Proposal 249 does not cover changing RELAY_EARLY behavior, which will potentially cause problems (Eg: Ring-LWE + ntor will require between 5 to 9 fragments depending on the exact primitives). * The actual hybrid construct is deliberately left unspecified. * With runtime negotiation of primitives on a per-circuit basis, we introduce the possibility of downgrade attacks. We do calculate the SHA256 digest of VERSIONS/CERTS/AUTH_CHALLENGE cells (which will become VERSIONS/CIPHERSUITES/CERTS/AUTH_CHALLENGE), so we could do something like: auth_input = verify | ID | B | Y | X | SLOG | PROTOID | "Server" Where SLOG is the digest without too much difficulty... The alternative to all of this would be something like including handshake methods/supported link crypto in the descriptors, but that seems silly. Regards, -- Yawning Angel

2 2

W3C Payment Groups
by Jeff Burdges 16 Nov '15

16 Nov '15

I've been talked into formally participating in the W3C Payment Interest/Working Group as part of working on GNU Taler, well my employer INRIA is a member. Drop me a line if there is anything I can do/say/watch to help keep that potential standard tor friendly. Best, Jeff p.s. There are related groups on privacy and credentials that might be of more interest to Tor Browser which I'm not involved in, btw. p.s.2 Just fyi, Taler is a transaction system based on RSA blind singing. We haven't finished the demo for Taler yet, probably by 32c3 though. Feel free to look at these if you want to know more : http://taler.net http://grothoff.org/christian/taler-draft.pdf

1 0

Upcoming Onionoo version 3.0 will support searches by space-separated fingerprint
by Karsten Loesing 15 Nov '15

15 Nov '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Onionoo client developers, the upcoming Onionoo version 3.0 will support searches by space-separated fingerprint. To give you an example, the following two searches will both return moria1 as result, using the new version 3.0: "9695DFC35FFEB861329B9F1AB04C46397020CE31" "9695 DFC3 5FFE B861 329B 9F1A B04C 4639 7020 CE31" (In the current version 2.6 that second search wouldn't return anything, because it would look for a fingerprint starting with 9695 *and* starting with DFC3 *and* starting with...) You can try out the new behavior by using the Onionoo/Atlas/Globe mirrors run on thecthulhu.com: https://atlas.thecthulhu.com/#details/9695DFC35FFEB861329B9F1AB04C46397020C… https://atlas.thecthulhu.com/#search/9695%20DFC3%205FFE%20B861%20329B%209F1… The corresponding service instances run on torproject.org have not been updated yet, so that only the first search will return a result: https://atlas.torproject.org/#details/9695DFC35FFEB861329B9F1AB04C46397020C… https://atlas.torproject.org/#search/9695%20DFC3%205FFE%20B861%20329B%209F1… (not expected to return anything until November 15, 2015!) The torproject.org instances will be updated in a month from now to give you the chance to update your clients. After all, your client might rely on the current behavior of the search parameter. (That's why this is a major protocol change, not because it's a major step towards world domination.) Please tell me if the new behavior doesn't work for you and you need me to make any changes/extensions. More details on the ticket: https://trac.torproject.org/projects/tor/ticket/17115 All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJWHjKCAAoJEJD5dJfVqbCr+o0H/3Q37+YVS1d2enBa+Z/aEZkx b21/vvIUHMjBWCh41MAEJrQNzczfrjhusjkSpY1amypE6R81mST8mizFvtKK5zVh P4QlB9L40tKRrASwK1Tz+qSRmx7A6fm4YSieAALuvcD8LeNfwzNlKRqNSoipwDWl 7NjITYhOeRmExbUjfqDbfs5woodsabHaXIrAOUeQvtljc36bj1OGtq15UroaqLdv MKjn7GgP3qR5NrPAZKYlAVW7Qxg6KIsPC9DXam7xh4CIyWja01WsKrUab80fUT0K N7wvq4oV7PZ84BomVG/Fte2Vk5hz2e53deshsxwjVB2BonHKpq+hzHsLX+pkCSU= =0cnD -----END PGP SIGNATURE-----

2 4

Re: [tor-dev] . tor-roster's geo diversity badge and self-ref relays
by Sean Saito 15 Nov '15

15 Nov '15

Hi nusenu, >Do you consider in-family diversity so important - even though all of >them are run by a single entity anyway? > How about having a badge for tor network wide diversity? > I'd consider the tor network's overall diversity far more important than > in-family diversity because clients won't use more than one relay of a > given family anyway. Entire-network diversity is obviously more important than within-operator diversity---no doubt about that. We are doing within-operator diversity simply because the it's easier to measure/understand. I agree that measuring a family's relay diversity with respect to the entire Tor network is would be supplementary, maybe even strictly better. I am already logging relevant data, namely the number of relays per country and total CW per country (as you suggested previously). The former stastic could be used for badges like "First relay in country X." >More than 4/5 of the family's CW is located in countries with a cw lower >than 2%* (currently means non-top 7 country) and ASes lower than 1.5%* >(currently means non-top 8 AS)? > >That implies some degree of in-family diversity since a big family would >have to spread across multiple countries/ASes Although there have been some interesting discussions about which ASes to prioritize in putting new relays, an actual concrete numerical measure is thus far an unsolved problem. Virgil and I have talked about using a new tool (http://labs.apnic.net/vizas/) to observe which ASes have more interconnections and award bonus points to new relays on them. When these measures become better established definitely in favor of making badges for them (perhaps even replacing the within-operator diversity badges?). >"No Self-Referencing Relays" >I'm not sure what exactly you mean by that but I assume it is a MyFamily >config where a relay includes his own fingerprint. Why does that hurt? >The unnecessary descriptor space/bw? This is something Virgil wanted because he thought self-connections were ugly. If the penalizing of self-connections is found to be uglier than the self-connections themselves, we're both fine with removing it. Hope this answers your questions. Thanks for the feedback! Best, Sean

7 6

Starting on an Easy Bug #16846
by Abhiram Chintangal 15 Nov '15

15 Nov '15

Hello, I have been planning on learning more about tors code base for sometime now. Luckily, I might have some freetime for the next two weeks and I am hoping to put it to good use. After digging through tickets labelled as "easy" on trac, #16846 seemed like a decent cadidate for to me. There was some discussion on trac about the security impact of adding the feature, but that was three months ago. I was wondering if anyone could shed more light on it. Thanks! -- Abhiram Chintangal

2 1

NO 1-1-1 task exhange meeting on Thursday, Nov 12
by Karsten Loesing 11 Nov '15

11 Nov '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello devs, I decided to stop the experiment of organizing 1-1-1 task exchange meetings for everyone in Tor, because there was too little interest in having these meetings. If you have no idea what I'm talking about, here's the wiki page: https://trac.torproject.org/projects/tor/wiki/doc/1-1-1-task-exchange We may resume having these meetings as part of the metrics team or do another experiment that involves everyone in Tor at a later time. All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJWQ0aFAAoJEJD5dJfVqbCrIToIAKYXdZ/ytZHHsaVUSkraE7TX g0AOwLEo1IfyS1ANixXXsmTedevoweCfzxYyEdTrfDjfca17Ur4WmcAp4ROPxmAk jD4GqAq2ACFPai9fvmcFdPDoJsC3yP8kj1Zq05DT94EwlxBwctNzWF5TPCr1tteJ H2esPObS1rA2Cu00Ta4N/2qqc5HD4BrOJVOu2FvW2ZrGGJO5WDf/jSxxoJiLHmqu lqBqbSbUEEWsFe9iTjxM+Tke/73dbInUrJqZt6MbmjpOS8W4Ibyma51i6v2C9OmN 42ixTg/31Q9MX5w8Z6+Ma8BlD9K1hJ8hF3xBdt5mYWtT2araNIqy5dAv2L19tNQ= =QzaF -----END PGP SIGNATURE-----

1 0

Changing Rendezvous Single Onion Service at Runtime
by teor 10 Nov '15

10 Nov '15

Hi all, Is there any reason an onion service would want to temporarily switch from 1-hop to 3-hop paths? Is it ok if we force operators to restart the tor instance when onion service path lengths change? The original proposal for rendezvous single onion services (RSOS) was silent on whether path lengths could change at runtime. (I honestly didn't think anyone would do that!) The existing proposal doesn't allow operators to run hidden services (HS) and RSOS on the same Tor instance at the same time. I'd like to strengthen this security feature, and ensure operators can't run HS and RSOS on the same instance sequentially. This would also mean that operators can't switch an onion service's flavour from HS to RSOS or vice versa at runtime. In detail, this means that after an onion service is launched, a Tor instance can only run all RSOS, or all HS, until Tor is restarted. This design change protects operators from inadvertent network address disclosure from running onion services with 1 and 3 hop paths on the same Tor instance. But it also supports an ephemeral RSOS use-case, where the operator launches Tor, sets (or unsets) RendezvousSingleOnionServiceNonAnonymousServer, then launches an onion service. To implement this change, Tor needs to check: if RendezvousSingleOnionServiceNonAnonymousServer is changed, and there are any onion services active (excluding deleted/inactive services, if this is a feature of (ephemeral) services), then reject the change and warn the user. (Tell them to restart if they really want to change it.) For what it's worth, the implementation is also much simpler if we force a restart when this parameter changes. If we start enforcing the recommended options, like disabling entry guards and pathbias, a restart will be even more important. I've been talking with asn about this on Trac ticket #17178. Please feel free to comment by email or on the ticket. I'll modify the proposal after I'm sure this covers all use cases. In summary: Is there any rendezvous single onion service use case that wouldn't be possible with this new restriction? I want to check we aren't breaking any neat onion service uses, if we force Tor to restart when changing path lengths. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

3 2

Proposal: Adding x-namespace to relay descriptor for key:value pairs
by Virgil Griffith 09 Nov '15

09 Nov '15

Filename: ExtraRelayDescriptorFields.txt Title: Adding x-namespace to relay descriptor for key:value pairs Author: Virgil Griffith Created: 2015-09-30 Status: Open 1. Motivation We wish to allow developers to build new applications atop relays. Towards this end, we wish to add the ability for users to specify arbitrary new key-value entries under the "X-" namespace to the router descriptor [1]. The canonical applications for this are adding a bitcoin donation address and networking of tor2web nodes. 2. Proposal Allow optional key-value lines in the relay's torrc file. These lines will be mirrored in the relay's descriptor which is then published in the directory consensus. The following would be added to section 2.1.2 of the dir-spec (Extra-info document format): ======================================================== "X-" CustomKey SP CustomValue NL CustomKeyChar = "a"-"z" / "0" - "9" / "-" / "_" CustomKey = 1*32 CustomKeyChar CustomValueChar = atext / specials CustomValue = 1*1024 CustomValueChar Custom fields can appear multiple times, for example... X-bitcoin 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8 X-gravatar https://s.gravatar.com/avatar/d27fce46c9ac41a41bb52455ae75701d X-favoritequote Be excellent to each other. Party on dudes! X-foo bar If the same CustomKey appearing more than once is disallowed. Possible values for CustomValueChar as specified per RFC 2822. The sum size accounting for all such custom fields is truncated to 5 kilobytes. ======================================================== To mitigate the chance of a malformed torrc file, I additionally propose that the relay descriptor be scanned and if it does not match the specification, that it exit with error telling her torrc file is a likely culprit. -V

3 5

Update of prop#250: Random Number Generation During Tor Voting
by David Goulet 09 Nov '15

09 Nov '15

Hello Tor-Dev! We've almost completed the implementation [1] for prop#250 so we've reviewed part of the proposal to correct part of it to reflect reality (because you know a proposal is just wishful thinking until you implement it :). Attached is the new version that we've been working on. We would like feedback from the community before at least calling it "ACCEPTED" and updated in tor-spec.git [2]. Here is a small summary of the big changes and also we need feedback on something that we are not fully in agreement. First, period have been changed from 12:00 -> 12:00 (24 hour) to 00:00 -> 24:00 so the protocol run is not over two days. Seemed more logical and less confusing :). Second, we've removed the need of having majority for a commit to be considered for the shared random computation. Yes this sounds intense!! so it needs your attention. We think that majority concept was only protecting us against was a partition attack during commit phase but it turns out that having a conflict detection mechanism (see COMMITCONFLICT section) already protect us of most of them during the commit phase except maybe one that is described in Section 5.3.1. With this proposal change, an authority only keeps commits that are authoritative that is a commit coming directly from an authority. We've added section 5.3 on Partition Attack. Choosing commit by majority was protecting us against a partition attack in the commit phase but not all so with or without it, we still need an external monitoring party that makes sure attack are not ongoing (or bugs). DocTor is the obvious candidate so we'll work on a partition attacks detection since all of them are noisy and detectable. A sub-section (4.1.7) has also been added which address the need of a shared random key that signs the commit values so they can be verified by other authorities [3]. Finally, we would like your opinion also on if we should keep the conflict mechanism or not?. Since those partition attacks are basically dumb, do not achive much result for an attacker and it's at a high cost of comprimising a directory authority, should we keep them? Keep in mind that it adds a layer of complexity in the code especially with shared random keys which rotates every 30 days and are only available in the vote of an authority. It gets difficult to validate a conflict of an authority if we haven't seen yet a vote from that authority. There are ways to fix that code wise but is this worth it considering that every partition attack will be detected anyway by DocTor? One argument to keep it is resilience of the protocol. With conflict line, if one dirauth does stupid things, it will get ignored for the rest of the protocol run so we can still compute a fresh random value in the end. Again, does it worth it? Don't hesitate to ask about sections that are not clear or could be incorrect or you do not understand fully. Also, a ACK is a valid reply :). Thanks to all! David [1] https://trac.torproject.org/projects/tor/ticket/16943 [2] https://gitweb.torproject.org/torspec.git/tree/proposals/250-commit-reveal-… [3] https://trac.torproject.org/projects/tor/ticket/17349

5 9

Hidden service patch workshop on #tor-dev IRC channel
by George Kadianakis 09 Nov '15

09 Nov '15

Dear tor-dev, Everyone who is working on any kind of improvement to hidden services or related applications and would like to give or receive assistance (code reviews, advice, etc.) is welcome on: Thursday November 12, 16:00 UTC @ #tor-dev OFTC channel This might become a regular biweekly thing, if it proves to be successful. Cheers!

2 1