Re: [tor-dev] Starting with contributing to Anonymous Local Count Statistics.

Jaskaran Singh writes: > [ text/plain ] > Hi, > > I thought the project idea had already been depreciated in favor of > counting unique users by directory fetches. No? > Yes, we do count unique users by directory fetches for the "active Tor users" metric:

Re: [tor-dev] Starting with contributing to Anonymous Local Count Statistics.

Aruna Maurya writes: > [ text/plain ] > Hey! > > I was going through the Tor Volunteer page and came across the Anonymous > local count statistics project. As a student it would be a great starting > point and an even bigger opportunity to get a chance to collaborate

Re: [tor-dev] Bandwidth Authority Progress

teor writes: > Hi asn, > > Original Subject: Re: [tor-project] Meeting notes, network team meeting, 18 > Dec > >> On 19 Dec 2017, at 07:28, Nick Mathewson wrote: >> >> - Met with David Stainton, Moritz and others. Talked about relay load >>

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

As discussed in this mailing list and in IRC, I'm posting a subsequent version of this proposal. Basic improvements: - Uses a new custom HTTP header, instead of Alt-Svc or Location. - Does not do auto-redirect; it instead suggests the onion based on antonella's mockup:

Re: [tor-dev] Rebooting work on proposal #247 (guard discovery)

Mike Perry <mikepe...@torproject.org> writes: > George Kadianakis: >> Hello Mike, >> >> I'm finally getting out of the prop224/microdescriptor bug pile, and >> getting more time to start working on guard stuff like prop247 again. >> >> I'm pla

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

teor writes: >> >> On 16 Nov 2017, at 00:38, Alec Muffett wrote: >> >>> I think it's important to point out that a Tor client is never >>> guaranteed to hold a *definitive* consensus. >>> >> That's why I say "(mostly) definitive" in my text - my

[tor-dev] UX improvement proposal #2: Encrypted bookmarks for onions

Hello, here is another onion-related UX improvement proposal. We still don't have a plan for how to concretely fix the onion naming issue, and we recently released next gen onions so names just got bigger. Ideally we should start experimenting with solutions sooner than later (also see

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

Alec Muffett writes: > On 15 Nov 2017 12:18, "Iain R. Learmonth" wrote: > > Is this not what TorDNSEL does? > https://www.torproject.org/projects/tordnsel.html.en > > > Hi Iain! > Hey Alec, thanks for the feedback. > That certainly sounds like it

Re: [tor-dev] Understanding the guard/md issue (#21969)

George Kadianakis <desnac...@riseup.net> writes: > Hey Tim, > OK updates here. We merged #23895 and #23862 to 032 and master. #23817 is now in needs_review and hopefully will get in the next 032 alpha. I think this next alpha should be much better in terms of mds. Next tick

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

Tom Ritter writes: > I am a big proponent of websites advertising .onions in their Alt-Srv. > >> 4.2. No security/performance benefits >> >>While we could come up with auto-redirect proposals that provide security >>and performance benefits, this proposal does not

[tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header 1. Motivation: Lots of high-profile websites have onion addresses these days (e.g. Tor , NYT, blockchain, ProPublica). All those websites seem

Re: [tor-dev] Understanding the guard/md issue (#21969)

teor <teor2...@gmail.com> writes: >> On 29 Oct 2017, at 01:19, George Kadianakis <desnac...@riseup.net> wrote: >> >> >> >> Let me know what you think! Perhaps you have other ideas here of how we >> should approach this issue. > >

Re: [tor-dev] Understanding the guard/md issue (#21969)

teor <teor2...@gmail.com> writes: >> On 29 Oct 2017, at 01:19, George Kadianakis <desnac...@riseup.net> wrote: >> >> Hey Tim, >> >> just wanted to ask a clarifying question wrt #21969. >> >> First of all there are various forms of #21969 (a

Re: [tor-dev] v3 hidden services: inconsistencies between spec and implementation

inkylatenoth writes: > 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

[tor-dev] Understanding the guard/md issue (#21969)

Hey Tim, just wanted to ask a clarifying question wrt #21969. First of all there are various forms of #21969 (aka the "missing descriptors for some of our primary entry guards" issue). Sometimes it occurs for 10 mins and then goes away, whereas for other people it disables their service

Re: [tor-dev] Padding prop224 REND1 cells to blend them with legacy cells

teor <teor2...@gmail.com> writes: >> On 20 Sep 2017, at 00:44, George Kadianakis <desnac...@riseup.net> wrote: >> >> Legacy RENDEZVOUS1 cells are bigger than the prop224 ones. The prop224 >> spec suggests we pad the new cells so that they look s

[tor-dev] Padding prop224 REND1 cells to blend them with legacy cells

Hello Ian, (and other cryptographers on the list) here is a quick question which you might be able to answer super fast: Legacy RENDEZVOUS1 cells are bigger than the prop224 ones. The prop224 spec suggests we pad the new cells so that they look similar in size to the legacy ones. Here is how

Re: [tor-dev] Open topics of prop247: Defending Against Guard Discovery Attacks using Vanguards

s7r <s...@sky-ip.org> writes: > George Kadianakis wrote: >> Hello, >> >> here is some background information and summarizing of proposal 247 >> "Defending Against Guard Discovery Attacks using Vanguards" for people >> who plan to work on this in

Re: [tor-dev] Clarifications on guard-spec.txt

Roger Dingledine writes: > Hi folks! > > I'm catching up on my proposals, and I really like guard-spec.txt. > Nicely done! > > I made some fixes that I hope are straightforward: > https://lists.torproject.org/pipermail/tor-commits/2017-May/122942.html >

Re: [tor-dev] Clarifications on guard-spec.txt

Roger Dingledine writes: > Hi folks! > > I'm catching up on my proposals, and I really like guard-spec.txt. > Nicely done! > > I made some fixes that I hope are straightforward: > https://lists.torproject.org/pipermail/tor-commits/2017-May/122942.html >

[tor-dev] Open topics of prop247: Defending Against Guard Discovery Attacks using Vanguards

Hello, here is some background information and summarizing of proposal 247 "Defending Against Guard Discovery Attacks using Vanguards" for people who plan to work on this in the short-term future. I include a list of open design topics (probably not exhaustive) and a list of engineering topics.

Re: [tor-dev] Action items wrt ed25519 onion address verification in prop224 (was Re: [tor-project] Network team meetings notes from 17 April 2017)

Ian Goldberg <i...@cs.uwaterloo.ca> writes: > On Tue, Apr 25, 2017 at 03:38:37PM +0300, George Kadianakis wrote: >> > It turns out the point whose packed representation is 32 bytes of 0x00 >> > is a torsion point; it is the point (-1,0). >> > >> >

Re: [tor-dev] Action items wrt ed25519 onion address verification in prop224 (was Re: [tor-project] Network team meetings notes from 17 April 2017)

Ian Goldberg <i...@cs.uwaterloo.ca> writes: > On Mon, Apr 24, 2017 at 04:47:44PM +0300, George Kadianakis wrote: >> Ian Goldberg <t...@cypherpunks.ca> writes: >> >> > On Thu, Apr 20, 2017 at 03:40:58PM +0300, George Kadianakis wrote: >> >&

Re: [tor-dev] Interest in collaborating on a standard Ed25519 key blinding scheme?

Tony Arcieri writes: > I'm trying to gauge interest on the IRTF's CFRG mailing list regarding > collaborating on a draft for a standard Ed25519 hierarchical derivation / > key blinding scheme: > > https://mailarchive.ietf.org/arch/msg/cfrg/lM1ix9R-0tVzhZorQhQlKvi4wpA > > The

Re: [tor-dev] Action items wrt prop224 onion address encoding (was Re: Proposition: Applying an AONT to Prop224 addresses?)

Michael Rogers <mich...@briarproject.org> writes: > On 11/04/17 11:45, George Kadianakis wrote: >> We basically add the canonical onion address in the inner encrypted >> layer of the descriptor, and expect the client to verify it. I made this >> feature opti

Re: [tor-dev] Action items wrt prop224 onion address encoding (was Re: Proposition: Applying an AONT to Prop224 addresses?)

George Kadianakis <desnac...@riseup.net> writes: > Ian Goldberg <i...@cs.uwaterloo.ca> writes: > >> On Wed, Apr 05, 2017 at 10:02:07AM -0400, David Goulet wrote: >>> Another thing about this I just thought of. This AONT construction seems >>> wise >

[tor-dev] Action items wrt ed25519 onion address verification in prop224 (was Re: Proposition: Applying an AONT to Prop224 addresses?)

Ian Goldberg writes: > On Mon, Apr 03, 2017 at 04:40:52PM +0100, Alec Muffett wrote: >> On 3 Apr 2017 3:48 p.m., "Ian Goldberg" wrote: >> >> The other thing to remember is that didn't we already say that >> >>

[tor-dev] Action items wrt prop224 onion address encoding (was Re: Proposition: Applying an AONT to Prop224 addresses?)

Ian Goldberg writes: > On Wed, Apr 05, 2017 at 10:02:07AM -0400, David Goulet wrote: >> Another thing about this I just thought of. This AONT construction seems wise >> to use. But it's still not entirely clear to me why we need a 1bit version >> field. Taking this: >> >>

Re: [tor-dev] ***SPAM*** Re: Proposition: Applying an AONT to Prop224 addresses?

Ian Goldberg <i...@cs.uwaterloo.ca> writes: > On Mon, Apr 03, 2017 at 02:53:17PM +0100, Alec Muffett wrote: >> On 3 April 2017 at 13:04, George Kadianakis <desnac...@riseup.net> wrote: >> >> > I'm calling it weird because I'm not sure how an >> > a

Re: [tor-dev] Comments on proposal 279 (Name API)

Nick Mathewson writes: > Hi ! I'll make some comments here on the draft onion naming API at > > https://gitweb.torproject.org/torspec.git/tree/proposals/279-naming-layer-api.txt > > (Some of these are probably things you already meant, or already said > elsewhere.) >

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

Ian Goldberg writes: > On Mon, Mar 27, 2017 at 01:59:42AM -0400, Ian Goldberg wrote: >> > To add an aside from a discussion with Teor: the entire "version" field >> > could be reduced to a single - probably "zero" - bit, in a manner perhaps >> > similar to the distinctions

Re: [tor-dev] GSoC 17 | Name System API for Tor Onion Services

George Kadianakis <desnac...@riseup.net> writes: > Pickfire <pickf...@riseup.net> writes: > >> Hi, >> >> I am Ivan Tham. Currently studying in Computer Science in APIIT Malaysia. I >> am >> interested particapate in Google Summer of Code 2017 under

Re: [tor-dev] GSoC 17 | Name System API for Tor Onion Services

Ivan Tham <pickf...@riseup.net> writes: > George Kadianakis <desnac...@riseup.net> wrote: > >> Pickfire <pickf...@riseup.net> writes: >> >> > I am Ivan Tham. Currently studying in Computer Science in APIIT Malaysia. >> > I am >> >

Re: [tor-dev] GSoC 17 | Name System API for Tor Onion Services

Pickfire writes: > Hi, > > I am Ivan Tham. Currently studying in Computer Science in APIIT Malaysia. I am > interested particapate in Google Summer of Code 2017 under tor organization. I > am interested to see Proposal 224 coming along but I would really like to see >

Re: [tor-dev] Proposal xyz : Count Unique IP addresses in an anonymous way

teor writes: > Hi Jaskaran, > >> On 17 Mar 2017, at 23:42, Jaskaran Singh wrote: >> >> §2. Research >> >> There are three ways to solve this problem. All the three ways are >> actually Big Data >> Algorithms. A few problems arises for each of these

Re: [tor-dev] [PATCH] prop224: Trivial improvements to HS ntor section

George Kadianakis <desnac...@riseup.net> writes: > Hey David, > > please check my `prop224-ntor` torspec branch for some basic > improvements to the HS ntor section that came up while implementing it. > > Here it is: >https://gitweb.torproject.org/user/asn/tors

[tor-dev] [PATCH] prop224: Trivial improvements to HS ntor section

Hey David, please check my `prop224-ntor` torspec branch for some basic improvements to the HS ntor section that came up while implementing it. Here it is: https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224-ntor Let me know if you like them and I will merge them ASAP. Cheers!

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

David Goulet <dgou...@ev0ke.net> writes: > On 30 Jan (16:16:07), George Kadianakis wrote: >> David Goulet <dgou...@ev0ke.net> writes: >> >> > On 26 Jan (15:05:26), George Kadianakis wrote: >> >> Hey list, >> > >> > Hi! >> &g

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

Ivan Markin <t...@riseup.net> 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=50ffab9903880acf55fe387f4d509ecb2aa17

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

David Goulet <dgou...@ev0ke.net> 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 >> t

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

David Goulet <dgou...@ev0ke.net> writes: > On 24 Jan (14:27:43), George Kadianakis wrote: >> s7r <s...@sky-ip.org> writes: >> >> > > I like this quite a bit! Simple, easy, and trivial to understand. 56 > characters address, after that it will be

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

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

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 <s...@sky-ip.org> 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.or

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

George Kadianakis <desnac...@riseup.net> 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 swit

[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

Re: [tor-dev] Proposal 274: A Name System API for Tor Onion Services

grarpamp writes: > Always wondered how naming is relevant, > for example, IPv6 with OnionCat as a deterministic > form of naming. So now we propose a 'naming' layer. > Which should not also support IPv6 addressing? > Is not IPv6, subsequent to the 80bit scheme, > merely a

Re: [tor-dev] Remaining 4 bits in prop224 addresses

Jesse V writes: > On 12/06/2016 11:27 AM, David Goulet wrote: >> We had little discussion but some of us agree for sure on having bits for the >> version number. That will tell a tor client to fetch the right descriptor >> instead of trying all version that have the

Re: [tor-dev] prop224: What should we do with torrc options?

David Goulet writes: > On 06 Dec (10:09:57), teor wrote: >> >> > On 6 Dec. 2016, at 09:56, David Goulet wrote: >> > >> > >> > >> >> Here's a suggested strategy: >> * at load time, validate the HS options as if v2 is the default, and >> validate them

Re: [tor-dev] Remaining 4 bits in prop224 addresses

Jesse V writes: > Hello all, > > I've been closely following the other Proposal 224 threads regarding the > next-generation of onion services. I'm glad to see that we have a > timeline and plan for migrating the network. One unresolved point is > what to do with the

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

George Kadianakis <desnac...@riseup.net> writes: > Nick Mathewson <ni...@torproject.org> writes: > >> [ text/plain ] >> Hi! I thought I'd write this up while it was fresh in my mind. It >> could be used as an alternative method to the current proposed cli

Re: [tor-dev] [PATCH] torspec: Keep proposal-status.txt up to date

s7r <s...@sky-ip.org> writes: > George Kadianakis wrote: >> Hello, >> >> I was in a train yesterday and decided to do some torspec >> housekeeping. So I updated the proposals/proposal-status.txt file which >> includes a summary of every propos

[tor-dev] [PATCH] torspec: Keep proposal-status.txt up to date

Hello, I was in a train yesterday and decided to do some torspec housekeeping. So I updated the proposals/proposal-status.txt file which includes a summary of every proposal. You can find my changes here:

[tor-dev] Scheduling future Tor proposal reading groups

Hello people, in the beginning of 2016 we started organizing little-t-tor proposal reading groups in IRC, where we would discuss the current status of Tor proposals and coordinate on how to move them forward. You can see a list of previous such meetings here:

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

Nick Mathewson writes: > [ text/plain ] > Hi! I thought I'd write this up while it was fresh in my mind. It > could be used as an alternative method to the current proposed client > authentication mechanism. We could implement both, or just this, or > just the other. > >

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

David Goulet <dgou...@ev0ke.net> writes: > [ text/plain ] > On 15 Nov (16:29:33), George Kadianakis wrote: >> Nick Mathewson <ni...@torproject.org> writes: >> >> >> >> Hello, >> >> I worked some more on prop224 client authorizati

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

Nick Mathewson writes: > [ text/plain ] > Hi! I thought I'd write this up while it was fresh in my mind. It > could be used as an alternative method to the current proposed client > authentication mechanism. We could implement both, or just this, or > just the other. > >

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

teor <teor2...@gmail.com> writes: > [ text/plain ] > >> On 11 Nov. 2016, at 04:18, George Kadianakis <desnac...@riseup.net> wrote: >> >> George Kadianakis <desnac...@riseup.net> writes: >> >>> [ text/plain ] >>> Nick Mathewson &

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

George Kadianakis <desnac...@riseup.net> writes: > [ text/plain ] > Nick Mathewson <ni...@torproject.org> writes: > >> [ text/plain ] >> Hi! I thought I'd write this up while it was fresh in my mind. It >> could be used as an alternative method to the cu

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

Nick Mathewson writes: > [ text/plain ] > Hi! I thought I'd write this up while it was fresh in my mind. It > could be used as an alternative method to the current proposed client > authentication mechanism. We could implement both, or just this, or > just the other. > >

Re: [tor-dev] Revisiting prop224 client authorization

David Goulet <dgou...@ev0ke.net> writes: > [ text/plain ] > On 17 Oct (13:35:24), George Kadianakis wrote: >> George Kadianakis <desnac...@riseup.net> writes: >> >> > [ text/plain ] >> > Hello, >> > >> > we've reached the point

Re: [tor-dev] Revisiting prop224 client authorization

George Kadianakis <desnac...@riseup.net> writes: > [ text/plain ] > Hello, > > we've reached the point in prop224 development where we need to pin down > the precise cell formats, so that we can start implementing them. HS > client authorization has been one of thos

[tor-dev] Revisiting prop224 client authorization

Hello, we've reached the point in prop224 development where we need to pin down the precise cell formats, so that we can start implementing them. HS client authorization has been one of those areas that are not yet finalized and are still influencing cell format. Here are some topics based on

[tor-dev] Proposal 274: A Name System API for Tor Onion Services

: George Kadianakis, Yawning Angel, David Goulet Created: 04-Oct-2016 Status: Draft Table Of Contents: 1. Introduction 1.1. Motivation 1.2. Design overview and rationale 2. System

Re: [tor-dev] Joining Tor Project's software infrastructure

Paul Syverson <paul.syver...@nrl.navy.mil> writes: > [ text/plain ] > On Tue, Oct 04, 2016 at 12:54:55PM -0700, George Kadianakis wrote: >> >> BTW, monitor this list, there will soon be a proposal specifying a Tor >> API for naming systems like OnioNS, similar to th

Re: [tor-dev] Joining Tor Project's software infrastructure

Jesse V writes: > [ text/plain ] > Hey everyone, > > Although it hasn't been obvious, I actually have been making some > serious progress on my Onion Name System (OnioNS) project. The paper was > accepted into PoPETS, the design is finally stable, and the software is >

Re: [tor-dev] How to query HS hostname from control port

meejah writes: > [ text/plain ] > Jesse V writes: > >> TL;DR: Please let me know how to fetch the hostname of my hidden service >> from Tor's control port. > > There are two types of onion services: "on disk" ones configured via > torrc/SETCONF and the

Re: [tor-dev] [tor-talk] Onion Service introduction point selection

Muhammad Hammad Mazhar writes: > [ text/plain ] > I am looking into Tor onion services as part of my research, and am > interested in how an Onion Service selects its introduction points, in > particular where in source code does it do so. I am aware of rendservice.c in >

Re: [tor-dev] prop224: Ditching key blinding for shorter onion addresses

Jeremy Rand <jeremyr...@airmail.cc> writes: > [ text/plain ] > George Kadianakis: >> Lunar <lu...@torproject.org> writes: >> >>> [ text/plain ] >>> George Kadianakis: >>>> this is an experimental mail meant to address legitimate us

Re: [tor-dev] prop224: Ditching key blinding for shorter onion addresses

Lunar <lu...@torproject.org> writes: > [ text/plain ] > George Kadianakis: >> this is an experimental mail meant to address legitimate usability concerns >> with the size of onion addresses after proposal 224 gets implemented. It's >> meant for discussion and it's

Re: [tor-dev] Alternative Implementations of Tor

Alexander Færøy writes: > [ text/plain ] > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hello. > > Over the past year I've been hacking, on and off, on an implementation > of Tor in the Erlang programming language. The project started out after > I met Linus Nordberg at

Re: [tor-dev] Tor and Namecoin

George Kadianakis <desnac...@riseup.net> writes: > [ text/plain ] > Jeremy Rand <jeremyr...@airmail.cc> writes: > >> [ text/plain ] >> Hello Tor devs, >> >> Namecoin is interested in collaboration with Tor in relation to >> human-readable .on

Re: [tor-dev] Tor and Namecoin

Jeremy Rand writes: > [ text/plain ] > Hello Tor devs, > > Namecoin is interested in collaboration with Tor in relation to > human-readable .onion names; I'm reaching out to see how open the Tor > community would be to this, and to get feedback on how exactly the >

Re: [tor-dev] prop224: Ditching key blinding for shorter onion addresses

ban...@openmailbox.org writes: > [ text/plain ] > On 2016-07-29 17:26, George Kadianakis wrote: >> Hello people, >> >> this is an experimental mail meant to address legitimate usability >> concerns >> with the size of onion addresses after proposal 224

Re: [tor-dev] prop224: Ditching key blinding for shorter onion addresses

Nick Mathewson <ni...@alum.mit.edu> writes: > [ text/plain ] > On Fri, Jul 29, 2016 at 11:26 AM, George Kadianakis > <desnac...@riseup.net> wrote: >> So basically in this scheme, HSDirs won't be able to verify the signatures of >> received descriptors

[tor-dev] prop224: Ditching key blinding for shorter onion addresses

Hello people, this is an experimental mail meant to address legitimate usability concerns with the size of onion addresses after proposal 224 gets implemented. It's meant for discussion and it's far from a full blown proposal. Anyway, after prop224 gets implemented, we will go from 16-character

[tor-dev] Implementation plan for prop271 "Another algorithm for guard selection"

Hello people, our new guard algorithm proposal (prop271) is getting finalized and we are planning to move to implementation soon. You can find the proposal here: https://gitweb.torproject.org/torspec.git/tree/proposals/271-another-guard-selection.txt You can also find the STRIKE

Re: [tor-dev] [network-team] [doodle poll] Meeting to discuss guard proposal draft status

Nick Mathewson <ni...@alum.mit.edu> writes: > [ text/plain ] > On Tue, Jul 5, 2016 at 11:44 PM, isis agora lovecruft > <i...@torproject.org> wrote: >> George Kadianakis transcribed 1.6K bytes: >>> Hello! >>> >>> With Nick we settled

Re: [tor-dev] [network-team] [doodle poll] Meeting to discuss guard proposal draft status

Nick Mathewson writes: > [ text/plain ] > Hi! > > We should do proposal discussion meetings again. In particular, we > should talk about this draft I've been working on for a revised > version of the twstrike team's revised version of Isis's revised > version of the guard

[tor-dev] Improving hidden services on mobile phones

Hey list, just for the record, during the past weeks we've been discussing how to improve hidden services hosted on mobile phones in this here trac ticket: https://trac.torproject.org/projects/tor/ticket/16387 Discussion has also spilled over ticket #18620. The discussion also has a

Re: [tor-dev] Revisiting prop224 overlap descriptor logic and descriptor lifetimes

George Kadianakis <desnac...@riseup.net> writes: > [ text/plain ] > Roger Dingledine <a...@mit.edu> writes: > >> [ text/plain ] >> On Mon, Jun 13, 2016 at 03:48:39PM +0300, George Kadianakis wrote: >>> The main issue for me right now is that I can't r

Re: [tor-dev] Revisiting prop224 overlap descriptor logic and descriptor lifetimes

Roger Dingledine <a...@mit.edu> writes: > [ text/plain ] > On Mon, Jun 13, 2016 at 03:48:39PM +0300, George Kadianakis wrote: >> The main issue for me right now is that I can't recall how this helps with >> clock skewed clients, even though that was a big part of our di

Re: [tor-dev] Revisiting prop224 overlap descriptor logic and descriptor lifetimes

David Goulet <dgou...@ev0ke.net> writes: > [ text/plain ] > On 13 Jun (15:48:39), George Kadianakis wrote: >> Hello people, >> >> I invite you to check out another round of time period-related prop224 spec >> changes, based on our discussions in

[tor-dev] Onionboat: Using Docker for easy hidden services

Hello segfault, someone linked me to this today: https://nonconformity.net/2016/06/10/onionboat-using-docker-for-easy-tor-hidden-services/ https://github.com/jheretic/onionboat Forwarding it because of being potential relevant to your GSoC project (Tails server).

[tor-dev] Revisiting prop224 overlap descriptor logic and descriptor lifetimes

Hello people, I invite you to check out another round of time period-related prop224 spec changes, based on our discussions in Montreal. These new changes simplify the overlap descriptor publishing logic, and improve the caching lifetime of descriptors in HSDirs. You can find them in my branch

[tor-dev] Improving PT documentation on website

Hello Nima, I see you said this on IRC yesterday while referring to the pluggable transport docs: "I'm gonna be working on some of these documentations this month. do you have any suggestions on how we can improve them?" I agree that this is extremely high priority right now and I'm very glad to

Re: [tor-dev] Onioncat and Prop224

str4d writes: > [ text/plain ] > On 27/04/16 22:31, grarpamp wrote: >> On 4/25/16, Tim Wilson-Brown - teor wrote: >>> On 22 Apr 2016, at 17:03, grarpamp wrote: FYI: The onioncat folks are interested in collaborating

Re: [tor-dev] Latest state of the guard algorithm proposal (prop259) (April 2016)

Fan Jiang <fanji...@thoughtworks.com> writes: > [ text/plain ] > 2016年4月22日 上午4:54，"George Kadianakis" <desnac...@riseup.net>写道： >> >> Fan Jiang <fanji...@thoughtworks.com> writes: >> >> > [ text/plain ] >> > On Thu, Apr 21,

Re: [tor-dev] Latest state of the guard algorithm proposal (prop259) (April 2016)

Fan Jiang <fanji...@thoughtworks.com> writes: > [ text/plain ] > On Thu, Apr 21, 2016 at 4:32 AM, George Kadianakis <desnac...@riseup.net> > wrote: > >> Fan Jiang <fanji...@thoughtworks.com> writes: >> >> > [ text/plain ] >> > Hi, &

Re: [tor-dev] Revisiting prop224 time periods and HS descriptor upload/downloads

David Goulet <dgou...@ev0ke.net> writes: > [ text/plain ] > On 13 Apr (15:34:54), George Kadianakis wrote: >> David Goulet <dgou...@ev0ke.net> writes: >> >> > [ text/plain ] >> > On 12 Apr (16:01:32), George Kadianakis wrote: >> >> Da

Re: [tor-dev] prop224: HSDir caches question with OOM

Tim Wilson-Brown - teor <teor2...@gmail.com> writes: > [ text/plain ] > >> On 20 Apr 2016, at 07:22, David Goulet <dgou...@ev0ke.net> wrote: >> >> On 18 Apr (13:18:25), George Kadianakis wrote: >>> Tim Wilson-Brown - teor <teor2...@gmail.com>

Re: [tor-dev] Latest state of the guard algorithm proposal (prop259) (April 2016)

Fan Jiang writes: > [ text/plain ] > Hi, > >> Hello Fan and team, >> >> I think I'm not a big fan of the pending_guard and pending_dir_guard >> concept. To me it seems like a quick hack that tries to address fundamental >> issues with our algorithm that appeared when

Re: [tor-dev] prop224: HSDir caches question with OOM

Tim Wilson-Brown - teor writes: > [ text/plain ] > >> On 16 Apr 2016, at 05:47, David Goulet wrote: >> >> Hi! >> >> (For the following, I'm only talking about HS directory.) >> >> Here is my conundrum. I was working on plugging the new cache for

Re: [tor-dev] Latest state of the guard algorithm proposal (prop259) (April 2016)

Fan Jiang writes: > [ text/plain ] > Thanks for the insights. > > >> >> It seems like the latest version of prop259 was posted a few weeks ago: >> >> >> https://lists.torproject.org/pipermail/tor-dev/2016-March/010625.html >> >> >> > >> > >> >> A few things: >> >> >>

Re: [tor-dev] Revisiting prop224 time periods and HS descriptor upload/downloads

David Goulet <dgou...@ev0ke.net> writes: > [ text/plain ] > On 12 Apr (16:01:32), George Kadianakis wrote: >> David Goulet <dgou...@ev0ke.net> writes: >> >> > [ text/plain ] >> > On 11 Apr (14:42:02), George Kadianakis wrote: >> >> Da

Re: [tor-dev] Revisiting prop224 time periods and HS descriptor upload/downloads

David Goulet <dgou...@ev0ke.net> writes: > [ text/plain ] > On 11 Apr (14:42:02), George Kadianakis wrote: >> David Goulet <dgou...@ev0ke.net> writes: >> >> > [ text/plain ] >> > On 04 Apr (19:13:39), George Kadianakis wrote: >> >> He

Re: [tor-dev] Revisiting prop224 time periods and HS descriptor upload/downloads

David Goulet <dgou...@ev0ke.net> writes: > [ text/plain ] > On 04 Apr (19:13:39), George Kadianakis wrote: >> Hello, >> >> during March we discussed the cell formats of prop224: >> https://lists.torproject.org/pipermail/tor-dev/2016-March/010534.html >>

Re: [tor-dev] Reviewing prop224 fixes

David Goulet <dgou...@ev0ke.net> writes: > [ text/plain ] > On 04 Apr (13:07:29), George Kadianakis wrote: >> John Brooks <john.bro...@dereferenced.net> writes: >> >> > [ text/plain ] >> > (Thread forked from [tor-dev] Notes from the prop224 pr

<    1   2   3   4   5   >