Hi,
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.
Regards,
Phill.
On 28 October 2013 16:53, Nick Mathewson nickm@alum.mit.edu wrote:
On Mon, Oct 28, 2013 at 9:19 AM, Matthew Finkel matthew.finkel@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 offline.
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 hosts.
yrs,
Nick _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev