tor-dev August 2018

tor-dev@lists.torproject.org

22 participants
23 discussions

Tor Browser for arm64/v8 on RPi3
by procmem 06 Aug '18

06 Aug '18

We at Whonix are currently porting to (non-VM) physical builds on arm64 - specifically RPi3. While this is great for headless applications we are interested in GUI user adoption. Without Tor Browser for arm64 this won't be as safe as it can be. Can you please consider releasing builds for this hardware platform?

2 1

Tor Relay Guide Disagreements
by nusenu 03 Aug '18

03 Aug '18

Hi Vinícius, (moving this discussion to the tor-dev mailing list since this isn't limited to the OpenBSD ticket scope https://trac.torproject.org/projects/tor/ticket/26619#comment:14 ) Vinícius wrote: > you [nusenu] took over /FreeBSD, /BSDUpdates, and /OpenBSD and enabled the 'read- > only' mode all by yourself without even consulting the original author or > anyone else [...] > is there any particular reason why you enabled the read-only mode on > /FreeBSD, /BSDUpdates, and /OpenBSD? I think this a pretty odd behavior. > I'm sorry. if you do want to own all these pages (and many other more), > please tell us. The Tor Relay Guide wiki page [1] has been 'read-only' pretty much since we launched it, it has been decided a few months ago in [0]. Anyway read-only mode shouldn't affect you personally. Since you are listed on the tor people page I assume you can simply ask for the permissions to edit 'read-only' pages. I'd still ask you to open tickets for changes like your change to the FreeBSD page instead of applying them directly so we can discuss them before applying and to avoid the necessary efforts. On 2018-07-10 I split out the OS specific instructions into their subpages: /DebianUbuntu /FreeBSD ... because of this move content that was previously read-only until then became writable but that wasn't an intentional step. On 2018-08-02 you changed the FreeBSD page [4], here are two lines (examples) of your replacements: my text: change the nickname "myNiceRelay" to a name that you like Change the email address bellow and be aware that it will be published got replaced with: CHANGE THE NICKNAME WRITE YOUR EMAIL ADDRESS I'm not sure I would consider these replacements an improvement since they remove information without giving any reasoning for removing it in the comment. Besides the removal of information this also introduces inconsistency in the torrc file we used so far in the guide. I reverted your change and addressed the issue you brought up (net.inet.ip.random_id ordering, /etc/pkg/FreeBSD.conf modification) and made the content read-only again (like it was until 2018-07-10). > ggus is that page's [/OpenBSD] author and he allowed me to edit the contents of that > page (the same is also applied to the /FreeBSD page; There has been no comment by ggus on #26619 (/OpenBSD) for a month so I went ahead and assigned it to me, but I'll pull out of that ticket now. https://trac.torproject.org/projects/tor/ticket/26619 ggus didn't create /FreeBSD [3]. > should we always open tickets with suggestions? - sadly it > also sounds extra odd, because when I did open tickets (#27006 and > #27007), a few minutes later you changed contents all by yourself #27006 is about /DragonFlyBSD I've never touched that page? https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/DragonFlyBSD?ac… #27007 was about creating /NetBSD - which you did. I didn't consider my change - where I replaced the ORPort to use 443 (because we used that port everytime that works out of the box on a platform) to be part of the "create the /NetBSD page": https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/NetBSD?action=d… Going forward I'd propose the following to minimize the fraction and overhead: I assume you maintain: /TorRelayGuide-ptbr /TorRelayGuide/OpenBSD /TorRelayGuide/NetBSD /TorRelayGuide/DragonFlyBSD I'll keep maintaining: /TorRelayGuide /TorRelayGuide/DebianUbuntu /TorRelayGuide/CentOSRHEL /TorRelayGuide/Fedora /TorRelayGuide/FreeBSD /TorRelayGuide/openSUSE All pages should be read-only and writable to authorized users/maintainer, but feel free to have the pages you maintain world writable. All non-maintainer changes are expected to go through a ticket. After a timeout of 7 days with no maintainer response the ticket opener might proceed with applying the proposed change. I'll propose a list of requirements for a platform to be listed on the main page. kind regards, nusenu [0] https://trac.torproject.org/projects/tor/ticket/24497 [1] https://trac.torproject.org/projects/tor/wiki/TorRelayGuide [2] https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/FreeBSD [3] https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/FreeBSD?action=… [4] https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/FreeBSD?sfp_ema… -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

2 2

WTF-PAD and the future
by George Kadianakis 03 Aug '18

03 Aug '18

Hello Mike, I had a talk with Marc and Mohsen today about WTF-PAD. I now understand much more about WTF-PAD and how it works with regards to histograms. I think I might even understand enough to start some sort of conversation about it: Here are some takeaways: 1) Marc and Mohsen think that WTF-PAD might not be the way forward because of its various drawbacks and its complexity. Apparently there are various attacks on WTF-PAD that Roger has discovered (SENDME cells side-channels?) and also the deep learning crowd has done some pretty good damage to the WTF-PAD padding (90%-60% accuracy?). They also told me that achieving needed precision on the timings might be a PITA. 2) From what I understand you are also hoping to use WTF-PAD to protect against circuit fingerprinting and not just website fingerprinting. They told me that while this might be plausible, there is no current research on how well it can achieve that. Are we hoping to do that? And what research remains here? How can I help? Which parts of the Tor circuit protocol are we hoping to hide? 3) Marc and Mohsen suggested using application-layer defences because the application-layer has much better view of the actual structures that are sent on the wire, instead of the black box view that the network layer has. In particular they were mainly concerned about onion services fingerprinting because they are part of a restricted closed world, whereas they were less concerned about the entire internet because of its vast size. They suggested that we could investigate using the service-side "alpaca" library for onion services (e.g. as part of securedrop?) which should resolve the most pressing concern of HS identification. 4) They also told me of research by Tobias Pulls which eliminates the needs for histograms in WTF-PAD and instead it samples from the probability distribution directly. They think that this can simplify things somewhat. Any thoughts on this? Let me know what you think. I still don't understand the entire space completely yet, so please be gentle. ;) Cheers! :)

5 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev August 2018