November 2017 - tor-dev - lists.torproject.org

Proposal 284: Hidden Service v3 Control Port
by David Goulet 09 Nov '17

09 Nov '17

Hi everyone, Attached is the proposal draft for the hidden service v3 contro port specification. The idea with this proposal is to _only_ extend the current commands and events to v3. Nothing new is added. We can think of more things to add after but for now, I wanted a baseline to start with that is only extending what exists. Any kind of feedbacks is welcome! :) Cheers! David -- Zu3IyL4LcdnKNkQIZqEqaTNUapUEJFdEcN02dPwo5FQ=

7 20

A ContactInfo specification
by nusenu 09 Nov '17

09 Nov '17

Hello, an earlier version of this has been send to tor-relays [1] and I got some feedback from irl and relay operators via ML and github issues. Now I'd like to hear from the tor developer community. Please send your feedback until 2017-10-27. example ContactInfo: https://atlas.torproject.org/#details/1EBFC733CCD952F7F7616EBBA7BC6B8E6F2F0… Overview --------- Tor's ContactInfo descriptor field was primarily intended to contain an email address and PGP key fingerprint but since this field accepts an arbitrary string it has been used for multiple other other purposes (website urls, donation information, bitcoin addresses, ...). Making use of provided information in an automated way is hard since there is no specification on how this string should look like. This is an specification to formalize the ContactInfo string. Motivation (excerpt) ----------- - collect additional (self-reported) relay metrics (for things like atlas and https://nusenu.github.io/OrNetStats ) - exmples: How many use tor's Sandbox/OfflineMasterKey/KIST feature? - This data could provide tor developers with information on how well tested/how much used new features (like Sandboxes) are before changing defaults. The entire document can be found here: https://github.com/nusenu/ContactInfo-Information-Shareing-Specification regards, nusenu [1] https://lists.torproject.org/pipermail/tor-relays/2017-October/013274.html -- https://mastodon.social/@nusenu twitter: @nusenu_

2 6

Re: [tor-dev] tor-dev Digest, Vol 82, Issue 8
by Nathan Kettle 07 Nov '17

07 Nov '17

unsubscribe On Tue, Nov 7, 2017 at 11:12 AM, <tor-dev-request(a)lists.torproject.org> wrote: > Send tor-dev mailing list submissions to > tor-dev(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > or, via email, send a message with subject or body 'help' to > tor-dev-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-dev-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-dev digest..." > > > Today's Topics: > > 1. Proposal 284: Hidden Service v3 Control Port (David Goulet) > 2. Re: Proposal 284: Hidden Service v3 Control Port (AntiTree) > 3. Re: Proposal 284: Hidden Service v3 Control Port (Damian Johnson) > 4. Re: Proposal 284: Hidden Service v3 Control Port (meejah) > 5. Fwd: Nyx 2.0 Release (Damian Johnson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 6 Nov 2017 09:59:07 -0500 > From: David Goulet <dgoulet(a)ev0ke.net> > To: tor-dev <tor-dev(a)lists.torproject.org> > Subject: [tor-dev] Proposal 284: Hidden Service v3 Control Port > Message-ID: <20171106145907.p7dm7dmqpnzlqsmj@raoul> > Content-Type: text/plain; charset="utf-8" > > Hi everyone, > > Attached is the proposal draft for the hidden service v3 contro port > specification. > > The idea with this proposal is to _only_ extend the current commands and > events to v3. Nothing new is added. We can think of more things to add > after > but for now, I wanted a baseline to start with that is only extending what > exists. > > Any kind of feedbacks is welcome! :) > > Cheers! > David > > -- > Zu3IyL4LcdnKNkQIZqEqaTNUapUEJFdEcN02dPwo5FQ= >

1 0

Fwd: Nyx 2.0 Release
by Damian Johnson 07 Nov '17

07 Nov '17

Hi tor-dev. Sorry for the cross post but while tor-relays@ is the perfect spot to announce Nyx, tor-dev@ is the traditional place to unveil Stem. I'm pleased to announce Stem 1.6, the accumulation of a full year of improvements for our controller library... https://stem.torproject.org/change_log.html#version-1-6 Besides features such as descriptor creation and ed25519 support the main highlight for this release is performance tuning. Descriptor parsing is ~25% faster and low-level control socket handling got some special attention. Cheers! -Damian ---------- Forwarded message ---------- From: Damian Johnson <atagar(a)torproject.org> Date: Mon, Nov 6, 2017 at 3:41 PM Subject: Nyx 2.0 Release To: tor-relays(a)lists.torproject.org Hi all, after years of being in the works I'm pleased to announce Nyx! A long overdue modernization of arm. http://blog.atagar.com/nyx-release-2-0/ https://nyx.torproject.org/ Even more important for our controller space at large, Nyx is coming hand-in-hand with Stem 1.6. A full year of improvements that include descriptor creation support, ed25519 certificates, performance tuning, and much, much more... https://stem.torproject.org/change_log.html#version-1-6 Cheers! -Damian

1 0

anonbib
by ng0 06 Nov '17

06 Nov '17

Hi, our plan with the bibliography collection of GNUnet is to implement something similar to your/freehaven's anonbib. While running the build and cache update of it from current git HEAD on the anonbib.cfg I noticed a number of outdated and broken links. I'm currently playing with 2 options: re-use anonbib as it is and change the style + some of its content (for us at GNUnet) or write something similar to it. From my perspective option 1 would be the best as we could work on fixing links together, keep the content up-to-date and at the same time keep the duplicate efforts and work down to a minimum. What do you think? -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://dist.ng0.infotropique.org/dist/keys/ https://www.infotropique.org https://ng0.infotropique.org

6 12

Namecoin resolution for Tor Prop279
by Jeremy Rand 05 Nov '17

05 Nov '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Tor devs, I've written up some documentation on using Namecoin with Prop279. This can be used for human-meaningful onion service names, as well as standard Namecoin A/AAAA/CNAME records. In theory, this can also be used with arbitrary non-Namecoin naming systems that speak the DNS protocol, although I haven't attempted to do so. Documentation is here: https://www.namecoin.org/docs/tor-resolution/ You can test it with this URL: http://federalistpapers.bit/ Curious what you all think of it -- please feel free to give feedback. Cheers, - -- - -Jeremy Rand Lead Application Engineer at Namecoin Mobile email: jeremyrandmobile(a)airmail.cc Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C Send non-security-critical things to my Mobile with OpenPGP. Please don't send me unencrypted messages. My business email jeremy(a)veclabs.net is having technical issues at the moment. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZ/5k5AAoJELPy0WV4bWVwlSEQAIeF5fiZUBsaiCGyxaDAz97b l4KVyEKAcPOKCvjryKMqGjxHJPfw9uJJY4x0hD4taXYHszfAMBayOs8EkWHd/eFq 3FDAGW2VaS29k9+y+URiIa9gI3H2et+HgwTOxwCk1O/B2l/2TmWWdGnyh8UCr1a1 yibzBRcamaaMyWwDg7gK0ZvN0WPGwCXiFxVC3fT37dKW2Ve9PwvqZEfsZ/i7eVN1 1Vb+o1Q11qe70yx7XQv3KUFpccU1UsIlR/C0hp0ISxAjV5CpMnN8Lu3/E8s0ViFL Z3PKL/cpbRltaPPdv8U0mMLy3KY+/u4yRtl2lmHejsNnCwA9gBrZ3XY9A81ZX/wD QKVBvHf7tO1FlbwKnz0Vb4aY2Ls09vRlXKAQ3zEWtXAT9pofH/dadfI3LYKykeAd +vuDjDOfsGrIVarn0vWqoVwf43P9iDuaDmk0hNDkbBieEcjIOYbuy3xXiMFxMjpF Na0StOMYsI1xSlyUqq6+MT5MRrGmh7zk5d8/PYAEdQM8mPJ6wOzgN98sEoGfZLE+ s1rbeZdMiJqne18G9ulUCh4DPOTyZ4K36oJoUAtr/JSt5IO9vGIrTElbw3BjYm6T 7bTeawoWoX+Lx+BJW+dDq57J2r91wwFZdHAqlbQhWvUi8IynVOVqsZUJbw+g9ioP BAzC5zPauEzD2/awtx/5 =0kqw -----END PGP SIGNATURE-----

1 0

v3 hidden services: inconsistencies between spec and implementation
by inkylatenoth 03 Nov '17

03 Nov '17

Whilst implementing v3 hidden services myself I found some inconsistencies between the specs and the current implementation. I wanted to share these in case someone from the Tor organization wants to update the specs and/or the implementation. # rend-spec-v3.txt ## 2.4 * after decrypting the `superencrypted' object from a descriptor, the resulting document does not end with the NL character. This means that it does not strictly conform to the document meta-format described in section 1.2 of dir-spec.txt. ## A.2 * the blinded key param is defined as H(BLIND_STRING | A | s | B | N). In practice I found that I had to add a null byte after BLIND_STRING in order to reach the same value as the C implementation: param = H(BLIND_STRING | INT_1(\x00) | A | s | B | N) In all other cases where a string constant is used like this (e.g. computing the nonce N above), I found that the trailing null byte is not required. * when clamping the blinding factor, the second bitwise operation is `param[31] &= 127' in the spec but `param[31] &= 63' in the C implementation. These are equivalent in practice when followed by the third operation (`param[31] |= 64'), but it might be nice to use a consistent representation for the benefit of human readers. # 220-ecc-ids-keys.txt # 2.1 * 'The signature is formed by signing the first N-64 bytes of the certificate prefixed with the string "Tor node signing key certificate v1".' I found this to be false; the signatures only validate without the string prefix. ## A.1 * I realized that the certificate types here are outdated. The signing-key extension is listed as type [04], when in rend-spec-v3.txt and the C implementation it is type [08].

3 3

Reporting Relay Bandwidth Less Often
by teor 01 Nov '17

01 Nov '17

Hi all, We would like to make Tor relays report their bandwidth statistics every 24 hours, rather than every 4 hours. We believe that this is a safer interval for clients. It makes it harder to discover the guards of clients that use a lot of bandwidth, particularly onion services. Here's how this kind of guard discovery can happen: * a client repeatedly downloads a large file, or an onion service becomes very popular, or is repeatedly asked for a large file * the traffic statistics for the client's guard increase dramatically in the next 4 hours * an adversary watches the traffic statistics across the whole network, and finds the ones with dramatic increases Increasing the bandwidth statistics interval slows down this attack: * it requires more bandwidth to produce a 24 hour spike * each statistics interval is longer, so it takes more time to be sure of the guard One of the impacts of this change is that relay bandwidth graphs are less detailed. We will encourage relay operators to view detailed graphs using local tools like Nyx or Munin or similar, because this is safer for clients. We are tracking this work in this trac ticket: https://trac.torproject.org/projects/tor/ticket/23856 Tim -- Tim / teor PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------

2 3