- tor-dev - lists.torproject.org

Prop224 oppurtunity: keygen, crypt, sign, encoding tools
by grarpamp 17 Feb '17

17 Feb '17

Tor could ship with a tool to offline generate all the various keys, encrypt and sign with them, for debug, test, and use with other apps that tie to tor. And a tool to translate strings between different encodings in use. Or at least provide howto and links in the docs to third party tools that users could use for key ops and translation. Since those howto topics appear on the lists now and then. We here might code up openssl, python functions, etc on the fly. However beginning users are typically looking for simple purpose dedicated tools, or example docs using prebuilt tools off the net. This tends to apply to budding application development in onionland, developing things that look at and use tor, etc.

5 4

GSoC 2017 - my name is Marcin
by Marcin Czarnecki 13 Feb '17

13 Feb '17

Hello all, tl;dr can go on about Tor and anonymity and privacy related things for hours, give me a chance I am studying Computer Science at the University of Brighton (in the UK). I am interested in participating in Google Summer of Code 2017 with the Tor project. I am a web security and anonymity enthusiast, tried to work with the Tor Project for GSoC 2016 but it did not work out. I have not contributed to the Tor's code base but have been an active, semi advanced user for past 3 years. Have been experimented with setting up exit-nodes (ended up with my box being considered the #1 most evil machine in the world :)), creating Tor-clearnet gateways, hosting own HS, trying to exploit other HSes, playing with encryption etc. I think that gave a me a lot of insight of how Tor works (still amazed and finding new things when reading docs). I am planning to base my proposal on the idea on a easier way of hosting HS so it would become more accessible to non tech savvy Tor users plus enforcing good security practices when hosting a HS (got some experience and cool ideas [citation needed]). My main skills are in Linux and back-end web development but I am also interested in scripting and automation as well as encryption. Can talk about Bitcoin for hours (security, anonymity, etc.), thinking about using that as my other project proposal as this should be the currency of Tor and more integrated into Tor (Tor Browser extension?). When it comes to programming I feel confident with PHP, Python and HTML, CSS, JS stuff, and know a bit of other languages but I am a fast learner! When it comes to tor related projects, two years ago I did this small crawler with web interface for searching (#2 most evil machine) in Python: https://github.com/marncz/torcrawler Cool feature on which I stopped working was HTTP headers fingerprinting which could led to grouping Hidden Services by hosts providers. Feel free to contact me: email: marnczarnecki[at]gmail.com IRC at OFTC: marncz Many thanks, Marcin

2 1

Issue regarding IRC channel
by Jaskaran Singh 12 Feb '17

12 Feb '17

Hi, As of writing this mail, I can't access the Tor-Dev channel on OFTC neither using my registered nick on desktop client nor through the web interface. Looks like the channel has turned invite only. Would be great if someone could look into this. Regards, Jaskaran Veer Singh

3 2

Re: [tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses
by Vi Grey 08 Feb '17

08 Feb '17

> Here is the suggested scheme: > > onion_address = base32(version + pubkey + checksum) > checksum = SHA3(".onion checksum" + version + pubkey) Wouldn't SHA3 be computational overkill if we're just worrying about the checksum making sure the .onion address wasn't mistyped? My suggestion would be to use something like this for the checksum: checksum = HMAC-CRC32(".onion checksum", version + pubkey)[2:] (with the HMAC key as its first argument) HMAC-CRC16 could be used as well instead of a truncated HMAC-CRC32, but CRC16 is a lot less standard than CRC32. Also, should we consider including a Version option eventually in the ADD_ONION control port command when using a KeyBlob? It wouldn't matter much for this new version and probably wouldn't matter much for a while, but it might be good to keep this in mind for the future.

4 3

archive.is and archive.fo are using CloudFlare. Is the TorBrowser add-on cfc useless now?
by Christian Pietsch 07 Feb '17

07 Feb '17

Hi Yawning, hi all, sorry if this is old news, but I just noticed that archive.is not only redirects me to archive.fo (which I noticed before), but archive.fo now greets me with a CloudFlare captcha. Considering that cfc was created in order to evade the CloudFlare captcha, this is quite a disappointment. Is cfc useless now? Can it be fixed? David F suggested using Memento which I think is an interesting idea, having participated in one of their hackathons. One caveat: Memento would point to to various archives not all of which might be suitable. What is the reason why archive.org is not used? I hear they are almost done setting up an onion service for the Internet Archive. Cheers, C: On Mon, Apr 18, 2016 at 10:16:31PM +0000, Yawning Angel wrote: > Source: https://git.schwanenlied.me/yawning/cfc -- Christian Pietsch, volunteering for Digitalcourage e.V., Bielefeld, Germany Nominations sought for the German Big Brother Awards: https://bigbrotherawards.de Verfassungsbeschwerde gegen Vorratsdatenspeicherung: https://digitalcourage.de/weg-mit-vds Appell gegen den geplanten Datenschutz-Abbau: https://digitalcourage.de/rettet-den-datenschutz Umfrage zum Datenschutztag 2017: https://datenschutztag.org/survey/

2 2

generate relay fingerprint without tor given the datadir/keys folder?
by nusenu 04 Feb '17

04 Feb '17

Hi, given the files within the datadir/keys folder (without the datadir/fingerprint file), is there an easy way to generate the relay fingerprint? (using openssl?) According to the spec [1] the fingerprint is the SHA1 hash of the public key. (I assume RSA pubkey) According to the tor man page [2] the RSA public key should be in keys/secret_id_key. openssl rsa -in secret_id_key -pubout| ..? |sha1sum thanks, nusenu [1] > "fingerprint" fingerprint NL > > [At most once] > > A fingerprint (a HASH_LEN-byte of asn1 encoded public key, encoded in > hex, with a single space after every 4 characters) for this router's > identity key. A descriptor is considered invalid (and MUST be > rejected) if the fingerprint line does not match the public key. [2] > DataDirectory/keys/secret_id_key > A relay’s RSA1024 permanent identity key, including private and > public components. Used to sign router descriptors, and to sign > other keys.

2 4

onionoo: understanding 'exit_policy_v6_summary'
by nusenu 01 Feb '17

01 Feb '17

Hi Karsten, given this torrc configuration and exit policy: https://lists.torproject.org/pipermail/tor-relays/2017-January/011806.html would you expect onionoo's 'exit_policy_v6_summary' to be not set? [1] https://onionoo.torproject.org/protocol.html#details writes: > Missing if the relay rejects all connections to IPv6 addresses. thanks, nusenu [1] https://atlas.torproject.org/#details/5E762A58B1F7FF92E791A1EA4F18695CAC667… {"nickname":"sorrentini","fingerprint":"5E762A58B1F7FF92E791A1EA4F18695CAC6677CE","or_addresses":["128.199.76.145:443","[2400:6180:0:d0::18a7:d001]:443"],"last_seen":"2017-01-27 13:00:00","last_changed_address_or_port":"2017-01-11 09:00:00","first_seen":"2016-11-30 03:00:00","running":true,"flags":["Exit","Fast","Running","Stable","Valid"],"country":"sg","country_name":"Singapore","region_name":"Central Singapore Community Development Council","city_name":"Singapore","latitude":1.2855,"longitude":103.8565,"as_number":"AS133165","as_name":"Digital Ocean, Inc.","consensus_weight":420,"host_name":"128.199.76.145","last_restarted":"2017-01-21 03:29:31","bandwidth_rate":1073741824,"bandwidth_burst":1073741824,"observed_bandwidth":1225379,"advertised_bandwidth":1225379,"exit_policy":["reject 0.0.0.0/8:*","reject 169.254.0.0/16:*","reject 127.0.0.0/8:*","reject 192.168.0.0/16:*","reject 10.0.0.0/8:*","reject 172.16.0.0/12:*","reject 128.199.76.145:*","accept *:53","accept *:80","accept *:110","accept *:143","accept *:220","accept *:443","accept *:873","accept *:989-990","accept *:991","accept *:992","accept *:993","accept *:995","accept *:1194","accept *:1293","accept *:3690","accept *:4321","accept *:5222-5223","accept *:5228","accept *:9418","accept *:11371","accept *:64738","reject *:*"],"exit_policy_summary":{"accept":["53","80","110","143","220","443","873","989-993","995","1194","1293","3690","4321","5222-5223","5228","9418","11371","64738"]},"contact":"0x44BB1BA79F6C6333 <tor-admin AT zumbi dot com dot ar>","platform":"Tor 0.2.9.8 on Linux","effective_family":["$82C92FBAF2196EC346670D12BB9650FE9FF55741","$EFD2EEB91E5C5D8CB999B1EC68D89E51F8776AC7"],"consensus_weight_fraction":8.568019E-6,"guard_probability":0.0,"middle_probability":0.0,"exit_probability":3.799685E-5,"recommended_version":true,"measured":true}

3 5

[RFC] Directory structure of prop224 onion services
by George Kadianakis 01 Feb '17

01 Feb '17

Hey list, with service-side prop224 implementation moving forward, we need to pin down the directory structure of prop224 onion services. This will be very similar to the current directory structure, but with some mods to facilitate assymetric client authorization keys and offline keys. As people have pointed out, the HS directory structure matters less after the introduction of ephemeral ADD_ONION onion services, but still it's an important part of onion service sysadmin UX. So the HiddenServiceDir directory will contain the following items: - "./hostname" [FILE] This is a file containing the onion address of the onion service. As you can see it's the same filename as in v2. Should we suffix it with v3 to make it clear that it's v3 onion? Would we ever have v2 and v3 onions living in the same directory? - "./private_key_ed25519" [FILE] This is the file containing the private master ed25519 key of the onion service. If offline keys are _enabled_, then this file doesn't exist and instead a directory is made containing blinded keys for every day [TODO: The directory format here will be specified in the future]. - "./client_authorized_pubkeys" [FILE] If client authorization is _enabled_, this is a newline-separated file of "<client name> <pubkey>" entries for authorized clients. You can think of it as the ~/.ssh/authorized_keys of onion services. - "./client_authorized_privkeys/" [DIRECTORY] "./client_authorized_privkeys/alice" [FILE] "./client_authorized_privkeys/bob" [FILE] "./client_authorized_privkeys/charlie" [FILE] If client authorization is _enabled_ _AND_ if the hidden service is responsible for generating and distributing private keys for its clients, then this directory contains files with client's private keys. The idea is that these files can be shredded and deleted after the private key has been passed to the client. For more context here, please read the client authorization thread in [tor-dev] and see 'Appendix F' of prop224 for more details on how this works. So this is it. The above should handle most uses of onion services + client authorization. The directory format of offline keys will be specified as we move forward with implementation. Hope things here are not too controversial. Looking forward to your feedback. In a few days, I will add a small Appendix section to prop224 with the above, and also fix the parts of 'Appendix F' that got outdated since then. Cheers!

6 12

Re: [tor-dev] GAEuploader
by Katherine Li 01 Feb '17

01 Feb '17

Hi Tim, Thank you for your insightful questions! My responses are below: *> Is this the cheapest zone/region for computation or bandwidth? If I am not in the US, would it be faster or cheaper for me to use a local google data center?* Yes, it would be faster for you to use a local google data center <https://cloud.google.com/appengine/docs/locations>. I have added a variable "REGION" in the script of the uploader. You can now change the region by replacing "us-central" with another region. I have also added an explanation of how to do this in the README. Below is a list of all the regions: REGION SUPPORTS STANDARD SUPPORTS FLEXIBLE asia-northeast1 YES YES europe-west YES NO us-central YES YES us-east1 YES YES You can also obtain this list via the following terminal command <https://cloud.google.com/sdk/gcloud/reference/app/regions/list>(with GAEuploader as your current directory): ./google-cloud-sdk/bin/gcloud app regions list As you pointed out, I have set the zone to zone3 in my original code. However, it turned out that zone is relevant only when working with Google Compute Engine <https://cloud.google.com/compute/>, which is not the case for GAEuploader. So I have removed the line "subprocess.check_call([" ./google-cloud-sdk/bin/gcloud", "beta", "config", "set", "compute/zone", " zone3"]) *> Which tor bridge does the traffic for these instances go through? (Or does this set up a tor bridge as well?)* The bridge uses https://meek.bamsoftware.com/, which is on the same host as the meek-azure bridge, but not rate-limited like meek-azure is. You can find more information on Tor relays at its Atlas page: https://atlas.torproject.org/#details/C20658946DD706A7A2181159A1A04C D838570D04 If you want to use a different bridge, you can edit the file appengine/reflect.go before running uploader: forwardURL = "https://meek.bamsoftware.com/" Thanks again for your input! Please let me know if you have any more questions/feedback. Best, Katherine Li

2 1

git-update: transparently torified git pulls
by carlo von lynX 31 Jan '17

31 Jan '17

Hi, here it is. Style may be crude as I usually write perl. #!/bin/sh # # A variant of git pull which operates over Tor and # - figures out when 'torify' needs to be used # - shows the changes that were made to the repository # - before attempting to merge # --lynX & heldensaga, 2017 # # I recommend piping the output into # vim -R "+set syntax=diff" # but since that isn't everybody's choice of editor # I won't work it into this script... # would be more elegant to tell you how to # configure this in your .git/config? gitdiff="git diff -b -M77% --minimal" # 'resolve' has served me well as default strategy gitmerge="git merge -s resolve" branch="$*" if test x"$*" = x; then branch="origin" fi # echo $branch url=`git remote get-url $branch` if test x"$url" = x; then exit fi # echo $url case $url in http*) torify="" echo "*** Fetching from $url via web proxy" ;; *) torify="torsocks" echo "*** Fetching from $url via torsocks" esac # echo $torify $torify git fetch $branch \ && $gitdiff master..$branch/master \ && exec $gitmerge $branch/master

2 2