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

On Sun, Mar 26, 2017 at 09:27:37PM +1100, teor wrote: > > On 26 Jan 2017, at 10:19, teor wrote: > > > >>> onion_address = base32(pubkey || checksum || version) > > > > Is the order in which the address is encoded once the checksum is > > calculated. checksum represents (the

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

> On 26 Mar 2017, at 21:41, Ian Goldberg wrote: > > On Sun, Mar 26, 2017 at 09:27:37PM +1100, teor wrote: >> >>> On 26 Jan 2017, at 10:19, teor wrote: >>> > onion_address = base32(pubkey || checksum || version) >>> >>> Is the order in which the

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

On Sun, Mar 26, 2017 at 09:27:37PM +1100, teor wrote: > > > On 26 Jan 2017, at 10:19, teor wrote: > > > >>> onion_address = base32(pubkey || checksum || version) > > > > Is the order in which the address is encoded once the checksum is > > calculated. checksum represents

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

> On 26 Jan 2017, at 10:19, teor wrote: > >>> onion_address = base32(pubkey || checksum || version) > > Is the order in which the address is encoded once the checksum is > calculated. checksum represents (the first two bytes of) the result of > the SHA3 hash. > > We put

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

> On 7 Feb 2017, at 21:33, Michael Rogers wrote: > > On 05/02/17 07:44, Taylor R Campbell wrote: >>> Date: Sat, 04 Feb 2017 20:14:00 -0600 >>> From: Vi Grey >>> Also, should we consider including a Version option eventually in the >>> ADD_ONION

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

On 05/02/17 07:44, Taylor R Campbell wrote: >> Date: Sat, 04 Feb 2017 20:14:00 -0600 >> From: Vi Grey >> 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

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

chelsea komlo: > 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 version in the onion address makes both using and > distributing onion addresses harder. If the long-term plan is

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

> Date: Sat, 04 Feb 2017 20:14:00 -0600 > From: Vi Grey > > 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: > >

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

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

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

On 31 Jan (14:26:52), Ivan Markin wrote: > On Tue, Jan 31, 2017 at 02:54:50PM +0200, George Kadianakis wrote: > > I merged my prop224 onion encoding patch to torspec just now, after > > fixing the bug that Ivan mentioned above. > > Thanks! > > btw it's not clear how H() output should be

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

On Tue, Jan 31, 2017 at 02:54:50PM +0200, George Kadianakis wrote: > I merged my prop224 onion encoding patch to torspec just now, after > fixing the bug that Ivan mentioned above. Thanks! btw it's not clear how H() output should be truncated to form a checksum. Should it be the first 2 bytes or

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

Ivan Markin writes: > 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

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

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] Proposal for the encoding of prop224 onion addresses

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] Proposal for the encoding of prop224 onion addresses

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

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] Proposal for the encoding of prop224 onion addresses

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

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] [RFC] Proposal for the encoding of prop224 onion addresses

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 itself. Note onion search spiders rely on such address

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

Hey, On 01/28/2017 10:16 AM, segfault wrote: > I share your concerns here. I think we could work around this by pulling > the version byte out of the base32 encoding, like this: > > onion_address = base32(pubkey + checksum) + "-" + version > > This would result in onion addresses like this: >

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

Hi, s7r: > I wouldn't go for the hypens, but even if we decide at a later point > that this was a good idea we can handle it at an upper layer, like with > a browser tool or something, it's outside the scope of this > microproposal. We all know only a naming system will really fix this > issue

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

Hi, chelsea komlo: > So if the plan is that onion addresses will not be used directly > by end users and there is an abstraction layer that hides things like > version upgrade from end users, then going ahead with the current plan > sounds good. > > However, if there is a chance that end users

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

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 version in the onion address makes both using and distributing

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

On 27 Jan (09:04:51), chelsea komlo wrote: > Hello! > > I have some more thoughts on versioning, specifically in regards to the > possibility of not including the version in the onion address and using > only the version field in the descriptor. > > I'm not able to write out these scenarios now

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

Hello! I have some more thoughts on versioning, specifically in regards to the possibility of not including the version in the onion address and using only the version field in the descriptor. I'm not able to write out these scenarios now but I will do this in the next day. Thanks for making

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

David Goulet writes: > On 24 Jan (14:27:43), George Kadianakis wrote: >> s7r writes: >> >> > > I like this quite a bit! Simple, easy, and trivial to understand. 56 > characters address, after that it will be the time to improve UX/UI with all > sorts of

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

> On 26 Jan 2017, at 09:59, Arlo Breault wrote: > > >> On Jan 24, 2017, at 4:27 AM, George Kadianakis wrote: >> >> onion_address = base32(pubkey || checksum || version) >> checksum = SHA3(".onion checksum" || pubkey || version) > > Any reason not

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

> On Jan 24, 2017, at 4:27 AM, George Kadianakis wrote: > > onion_address = base32(pubkey || checksum || version) > checksum = SHA3(".onion checksum" || pubkey || version) Any reason not to have the order of, pubkey || checksum || version be the same in both?

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

Hello, David Goulet wrote: > >> >> OK thanks for the useful discussion. I identified at least three feedback >> points: >> >> + Screw base58 it's not gonna work. We stick to base32. Usability will >> be "restored" with a proper name system. >> >> + Move version byte to the end of the address

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

On Tue, 24 Jan 2017 12:40:00 +, segfault wrote: ... > While the addresses are definitely too long to be fun to type, there are > still use cases where the addresses will be typed. For those cases you could print them with half-spaces or similar. You can even type them but need to remove them

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

On 2017-01-24 08:00, David Goulet wrote: On 24 Jan (14:27:43), George Kadianakis wrote: s7r writes: > Hello George, > > George Kadianakis wrote: >> Hello list, >> >> we've had discussions over the past years about how to encode prop224 onion >> addresses. Here is the latest

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

On Tue, Jan 24, 2017 at 12:40:00PM +, segfault wrote: > But maybe it would help to separate them into groups of 4 characters, > separated maybe by a dash, which would make them look like this: > > > tbi5-tdxb-osio-tpha-wjyu-7f5p-w5tl-nvbv-fjrj-7mes-kbsn-wr2b-qbu2-t4gg.onion Check out

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

Date: Tue, 24 Jan 2017 12:40:00 + From: segfault But maybe it would help to separate them into groups of 4 characters, separated maybe by a dash, which would make them look like this:

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

On 24 Jan (14:27:43), George Kadianakis wrote: > s7r writes: > > > Hello George, > > > > George Kadianakis wrote: > >> Hello list, > >> > >> we've had discussions over the past years about how to encode prop224 onion > >> addresses. Here is the latest thread: > >>

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

Hi George, George Kadianakis: [...] > [D3] Do we like base32??? > > In this proposal I suggest we keep the base32 encoding since we've been > using it for a while; but this is the perfect time to switch if we feel > the need to. > > For example, Bitcoin is using base58

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

chelsea komlo writes: > Hey George, > > Thanks for sending this and summarizing everything! > >> [D1] How to use version field: >> >> The version field is one byte long. If we use it as an integer we can >> encode 256 values in it; if we use it as a bitmap we

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

s7r writes: > Hello George, > > George Kadianakis wrote: >> Hello list, >> >> we've had discussions over the past years about how to encode prop224 onion >> addresses. Here is the latest thread: >> https://lists.torproject.org/pipermail/tor-dev/2016-December/011734.html >> >>

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

Hey George, Thanks for sending this and summarizing everything! > [D1] How to use version field: > > The version field is one byte long. If we use it as an integer we can > encode 256 values in it; if we use it as a bitmap we could encode > properties and such. > > My

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

Hello George, George Kadianakis wrote: > Hello list, > > we've had discussions over the past years about how to encode prop224 onion > addresses. Here is the latest thread: > https://lists.torproject.org/pipermail/tor-dev/2016-December/011734.html > > Bikeshedding is over; it's time to finally

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

> On 24 Jan 2017, at 00:36, George Kadianakis wrote: ... > [D1.1] Default version value: > > The next question is what version value to assign to normal onion > services. In the above scheme where: > > onion_address = base32(version + pubkey + checksum)

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

Hi George, George Kadianakis: > What should we do in Tor? My suggestion is to use '\x98' as the default > version value which prefixes all addresses with 't' (as in Tor). Check > the examples I cited above. > > An alternative is to turn the scheme to: >

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

On 2017-01-23 07:50, George Kadianakis wrote: George Kadianakis writes: Hello list, [D3] Do we like base32??? In this proposal I suggest we keep the base32 encoding since we've been using it for a while; but this is the perfect time to switch if we feel

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

George Kadianakis writes: > Hello list, > > > > [D3] Do we like base32??? > > In this proposal I suggest we keep the base32 encoding since we've been > using it for a while; but this is the perfect time to switch if we feel > the need to. > > For

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

On Mon, Jan 23, 2017 at 03:36:07PM +0200, George Kadianakis wrote: > [D2] Checksum strength: > > In the suggested scheme we use a hash-based checksum of two bytes (16 > bits). > This means that in case of an address typo, we have 1/65536 probability > to not detect the error

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

Hello list, we've had discussions over the past years about how to encode prop224 onion addresses. Here is the latest thread: https://lists.torproject.org/pipermail/tor-dev/2016-December/011734.html Bikeshedding is over; it's time to finally pick a scheme! My suggested scheme basically follows