- tor-dev - lists.torproject.org

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

Fwd: Fennec now builds with clang instead of gcc
by Nathan Freitas 29 Oct '17

29 Oct '17

For those working on Tor Browser for Android... ----- Original message ----- From: Nathan Froyd <nfroyd(a)mozilla.com> To: "dev-platform" <dev-platform(a)lists.mozilla.org>, mobile-firefox-dev(a)mozilla.org Subject: Fennec now builds with clang instead of gcc Date: Sun, 29 Oct 2017 19:15:50 -0400 Hi all, Bug 1163171 has been merged to mozilla-central, moving our Android builds over to using clang instead of GCC. Google has indicated that the next major NDK release will render GCC unsupported (no bugfixes will be provided), and that it will be removed entirely in the near future. Switching to clang now makes future NDK upgrades easier, provides for better integration with the Android development tools, and brings improvements in performance/code size/standards support. For non-Android platforms, the good news here is that compiling Fennec with clang was the last major blocker for turning on C++14 support. Using clang on Android also opens up the possibility of running our static analyses on Android. If you run into issues, please file bugs blocking bug 1163171. Thanks, -Nathan _______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev(a)mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev

1 0

[release] CollecTor 1.4.1, Onionoo 4.2-1.6.1
by iwakeh 27 Oct '17

27 Oct '17

Hi there! three new releases are available: https://dist.torproject.org/collector/1.4.1/ https://dist.torproject.org/onionoo/4.2-1.6.1/ These releases enable CollecTor and Onionoo to handle unusually structured (but valid) descriptors (cf. change-logs [0], [1]). For Onionoo this prevented updates, which are running again now as all instances use the new version now. So, all clients like Atlas receive fresh data again. The CollecTor fix was deployed first on all tp.o instances and no data was lost. Thanks to all who waited patiently for Atlas to receive new data! And, to all who kindly reported the problems they noticed! Please direct comments and questions to the metrics-team mailing list [3]. Cheers, iwakeh [0] https://gitweb.torproject.org/collector.git/tree/CHANGELOG.md?h=collector-1… [1] https://gitweb.torproject.org/onionoo.git/tree/CHANGELOG.md?h=onionoo-4.2-1… [2] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0

onionoo.tpo stuck at 2017-06-12 12:00?
by nusenu 26 Oct '17

26 Oct '17

Hi, just wanted to let you know that the delta between relays_published and current time is unusually high. https://onionoo.torproject.org/details?limit=0 {"version":"4.0", "relays_published":"2017-06-12 12:00:00", -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

2 4

Re: [tor-dev] https://gitlab.com/torproject
by Hans-Christoph Steiner 25 Oct '17

25 Oct '17

Hans-Christoph Steiner: > > > Nick Mathewson: >> On Wed, Aug 10, 2016 at 5:01 AM, Hans-Christoph Steiner >> <hans(a)guardianproject.info> wrote: >>> >>> FYI I registered https://gitlab.com/torproject to claim the name in the >>> gitlab namespace. I'm happy to hand it over to a more official Tor >>> person if anyone wants. Or just let me know if anyone ever wants to >>> actually use it. >>> >>> I've been using gitlab for a while now with F-Droid, and its quite nice. >>> Guardian Project is going to move our stuff there too. >>> >>> .hc >> >> Sure, I'd be happy to take it. >> >> We've been using gitlab's code review feature a fair bit, and though >> we don't plan to stop self-hosting our repositories, we do rather like >> having a better way to review big branches. > > Hey Nick, > > Sorry I was on vacation when I received this, and it got lost in the > fray. Send me your gitlab username, and I'll turn this over to you. > > .hc > I granted nickm_tor full ownership to https://gitlab.com/torproject I'm happy to answer questions about gitlab, especially gitlab-ci. I use it a lot with https://gitlab.com/fdroid. gitlab-ci is really great. .hc -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556

1 0

Request for resource requirement
by Ankit Rathore 24 Oct '17

24 Oct '17

Hello, I am currently working on a project where I require the resource which was originally present at this link https://trac.torproject.org/projects/tor/wiki/sponsors/SponsorD/June2011 The contents of this page are no longer available. It would be really helpful if someone could help me get the original contents of this page Thank you

2 1

Do Tor relays rely on ICMP type 11 (time exceeded / timeout in transit)?
by Igor Mitrofanov 23 Oct '17

23 Oct '17

Hi, On my relays I am dropping any traffic that Tor itself does not rely on. I wonder if I should allow or block incoming and/outgoing ICMP type 11 (time exceeded / timeout in transit)? My host does receive some ICMP type 11 packets, and does seem to send some out, but I am not sure if Tor is the source or destination. Do Tor relays use some 'traceroute'-like mechanism to detect unreachable relays? "netstat -s: ... ICMP input histogram: ... timeout in transit: 1923 ... ICMP output histogram: ... timeout in transit: 1277 " I remember seeing outgoing TCP packets with TTL set to 1 - those were the ones triggering incoming ICMP type 11 packets. Thanks, - Igor

2 2