Re: [tor-dev] [RFC] Directory structure of prop224 onion services

2017-01-30 Thread s7r
Hi, David Goulet wrote: > On 30 Jan (16:16:07), George Kadianakis wrote: >> David Goulet writes: >> >>> On 26 Jan (15:05:26), George Kadianakis wrote: Hey list, >>> >>> Hi! >>> >>> First, big thanks for this write up! >>> with service-side prop224 implementation

Re: [tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses

2017-01-30 Thread s7r
Hello, George Kadianakis wrote: > grarpamp writes: > >> Skimming thread... >> >> Version or not is fine, provided if you want versions you >> know you must store the bits somewhere, or ensure regex >> parser rules to recognize and match an intrinsic version >> represented by

Re: [tor-dev] [RFC] Directory structure of prop224 onion services

2017-01-30 Thread meejah
David Goulet writes: > I don't believe we should suffix here because for almost 10 years, users/apps > have been exposed to "hostname" and it does make sense that it's the goto file > for that. I'm +1 on keeping the filename as "hostname". txtorcon doesn't do processing on

Re: [tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses

2017-01-30 Thread Ivan Markin
On Tue, Jan 24, 2017 at 02:27:43PM +0200, George Kadianakis wrote: > And given the above, here is the new microproposal: > > onion_address = base32(pubkey || checksum || version) > checksum = SHA3(".onion checksum" || pubkey || version) > > where: >pubkey is 32 bytes ed25519 pubkey

Re: [tor-dev] [RFC] Directory structure of prop224 onion services

2017-01-30 Thread Ivan Markin
On Tue, Jan 31, 2017 at 09:02:35AM +1100, teor wrote: > How does an application tell the difference between a v2 and v3 > directory? > > What's the supported method, that we will continue to support in > future, regardless of key or algorithm changes? I guess by looking at the address and

Re: [tor-dev] [RFC] Directory structure of prop224 onion services

2017-01-30 Thread teor
> On 27 Jan 2017, at 01:58, David Goulet wrote: > >> - "./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

Re: [tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses

2017-01-30 Thread Ivan Markin
Hi, George Kadianakis wrote: > I made a torspec branch that alters prop224 accordingly: > > https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=prop224-onion-address=50ffab9903880acf55fe387f4d509ecb2aa17f95 It seems that SHA3 digest length is missing for onion address generation. I

Re: [tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses

2017-01-30 Thread David Goulet
On 28 Jan (00:25:04), chelsea komlo wrote: > Hey! > > > Here is some extra pressure for you ;). > > :) thanks, I will try! > > Before starting, someone today very kindly pointed me to Prop 271, the > naming system API for Tor Onion services. Overall, my larger concern is > whether adding the

Re: [tor-dev] [RFC] Directory structure of prop224 onion services

2017-01-30 Thread David Goulet
On 30 Jan (16:16:07), George Kadianakis wrote: > David Goulet writes: > > > On 26 Jan (15:05:26), George Kadianakis wrote: > >> Hey list, > > > > Hi! > > > > First, big thanks for this write up! > > > >> > >> with service-side prop224 implementation moving forward, we need to

Re: [tor-dev] [RFC] Directory structure of prop224 onion services

2017-01-30 Thread George Kadianakis
David Goulet writes: > On 26 Jan (15:05:26), George Kadianakis wrote: >> Hey list, > > Hi! > > First, big thanks for this write up! > >> >> with service-side prop224 implementation moving forward, we need to pin down >> the directory structure of prop224 onion services. This

Re: [tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses

2017-01-30 Thread George Kadianakis
chelsea komlo writes: > Hey! > >> Here is some extra pressure for you ;). > > :) thanks, I will try! > > Before starting, someone today very kindly pointed me to Prop 271, the > naming system API for Tor Onion services. Overall, my larger concern is > whether adding the

Re: [tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses

2017-01-30 Thread George Kadianakis
grarpamp writes: > Skimming thread... > > Version or not is fine, provided if you want versions you > know you must store the bits somewhere, or ensure regex > parser rules to recognize and match an intrinsic version > represented by entire address format specification

Re: [tor-dev] ExitPortStatistics interpretation

2017-01-30 Thread Karsten Loesing
On 29/01/17 17:54, nusenu wrote: > > > Karsten Loesing: >>> Oh thanks, so it is not possible to find out which is the most frequent >>> exit port by number of streams opened, that's a pity. >> Well, that one is easy: port 80. :) > > Ok, maybe I should have said that differently: > > "so it is

[tor-dev] git-update: transparently torified git pulls

2017-01-30 Thread carlo von lynX
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

[tor-dev] [release] Onionoo 3.2-1.1.0

2017-01-30 Thread iwakeh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi there! Another release of Onionoo is now available here: https://dist.torproject.org/onionoo/3.2-1.1.0/ Besides some technical improvements that are listed in the changelog [0] this release contains a protocol extensions [1]: * Extended