[tor-dev] [Draft Proposal] Scalable Hidden Services
PhillW at PhillW.net
Mon Oct 28 17:04:33 UTC 2013
you good people do still have a VM on its own ipV4 sat twiddling its
thumbs. It is pencilled in to be a 2nd relay for beta testing on. If you'd
like to put it to a different use, please feel more than free to ask.
On 28 October 2013 16:53, Nick Mathewson <nickm at alum.mit.edu> wrote:
> On Mon, Oct 28, 2013 at 9:19 AM, Matthew Finkel
> <matthew.finkel at gmail.com> wrote:
> > Hi everyone,
> > This is a proposal I wrote to implement scalable hidden services. It's
> > by no means finished (there are some slight inconsistencies which I will
> > be correcting later today or tomorrow) but I want to make it public in
> > the meantime. I'm also working on some additional security measures that
> > can be used, but those haven't been written yet.
> > Many thanks to George for his initial feedback. I pushed this version to
> > my public repo, and will continue to push updates there.
> > In reality this is really 3.2 proposals, so the end result, if accepted,
> > will look significantly different, but I'm indecisive at this point
> > about which of the designs is least dangerous.
> Looks cool!
> Generally, I think that requiring a single node to be master is fine
> in initial designs only: if we consider such a design, it's important
> to have a migration path to a design where the whole service doesn't
> fall over when a single leader goes down. It's less important to me
> that there be no master key, especially if that master key can be kept
> I also like designs where it's not immediately obvious how many hosts
> a hidden service has just from looking at its descriptor.
> FWIW, I'm working on a complete revision to rend-spec.txt, since I
> think the scope of hidden service changes under consideration is broad
> enough that it makes sense to reconsider the entire system as a whole
> rather than trying to do it one piece at a time. I haven't even
> gotten to the spec parts yet -- just the preliminaries -- but you can
> see the draft in progress as it was on my desktop this morning in
> branch "rendspec-ng" in my torspec repo. I'll be putting more updates
> there as I go.
> I mention that here because some of the design work I'm recording
> there should mitigate the dangers of distributing keys to different
> tor-dev mailing list
> tor-dev at lists.torproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tor-dev