On 29/10/14 13:01, George Kadianakis wrote:
Christopher Baines cbain...@gmail.com writes:
On 20/10/14 14:37, George Kadianakis wrote:
f) On a more researchy tone, this might also be a good point to start
poking at the HS scalability project since it will really affect HS
performance
, as part of the Next Generation HSes initiative [0], we
are considering enhancing the availability of HSes by allowing
multiple nodes per Hidden Service. A plausible idea for achieving that
is to allow multiple IP circuits per Introduction Point, as explained
in [tor-dev] by Christopher Baines
On 09/05/14 20:05, waldo wrote:
El 04/05/14 07:42, Christopher Baines escribió:
On 04/05/14 11:43, waldo wrote:
El 02/05/14 02:34, Christopher Baines escribió:
On 02/05/14 00:45, waldo wrote:
I am worried about an attack coming from evil IP based on
forced disconnection of the HS from the IP
On 07/05/14 18:30, Michael Rogers wrote:
On 07/05/14 17:32, Christopher Baines wrote:
What about the attack suggested by waldo, where a malicious IP
repeatedly breaks the circuit until it's rebuilt through a
malicious middle node? Are entry guards enough to protect the
service's anonymity
On 07/05/14 13:51, Michael Rogers wrote:
On 06/05/14 22:17, Christopher Baines wrote:
If so, then yes. When I implemented the deterministic selection of
introduction points, I had to implement a reconnection mechanism
to ensure that the introduction point would only be changed if it
had
On 06/05/14 20:13, Nicholas Hopper wrote:
On Sat, May 3, 2014 at 5:58 AM, Christopher Baines cbain...@gmail.com wrote:
On 03/05/14 11:21, George Kadianakis wrote:
On 08/10/13 06:52, Christopher Baines wrote:
In short, I modified tor such that:
- The services public key is used
, and
this is where I assume the problems with loosing connectivity occur?
On 30/04/14 22:06, Christopher Baines wrote:
- multiple connections for one service to an introduction point is
allowed (previously, existing were closed)
Does this mean that at present, the service builds a new IP
On 06/05/14 21:19, Roger Dingledine wrote:
On Tue, May 06, 2014 at 03:29:03PM +0100, Michael Rogers wrote:
I'm interested in your work because the hidden service protocol
doesn't seem to perform very well for hidden services running on
mobile devices, which frequently lose network
On 06/05/14 22:07, Christopher Baines wrote:
On 06/05/14 15:29, Michael Rogers wrote:
I'm interested in your work because the hidden service protocol
doesn't seem to perform very well for hidden services running on
mobile devices, which frequently lose network connectivity. I wonder
On 02/05/14 00:45, waldo wrote:
El 30/04/14 17:06, Christopher Baines escribió:
On 08/10/13 06:52, Christopher Baines wrote:
I have been looking at doing some work on Tor as part of my degree, and
more specifically, looking at Hidden Services. One of the issues where I
believe I might be able
On 08/10/13 06:52, Christopher Baines wrote:
I have been looking at doing some work on Tor as part of my degree, and
more specifically, looking at Hidden Services. One of the issues where I
believe I might be able to make some progress, is the Hidden Service
Scaling issue as described here [1
On 27/03/14 19:25, Helder Ribeiro wrote:
Great! Do you know what kinds of things are most useful to measure first?
Is it more useful at this point to:
1. measure time spent on functions within a process, to see if there's
anything taking up too much time, for example, at the hidden service's
On 10/10/13 23:28, Paul Syverson wrote:
On Wed, Oct 09, 2013 at 03:02:47PM +0100, Christopher Baines wrote:
On 09/10/13 11:41, Paul Syverson wrote:
These two changes combined should help with the two goals. Reliability
is improved by having multiple OP's providing the service, and having
all
On 09/10/13 01:16, Matthew Finkel wrote:
So, before I start trying to implement a prototype, I thought I would
set out my ideas here to check they are reasonable (I have also been
discussing this a bit on #tor-dev). The goal of this is two fold, to
reduce the probability of failure of a
On 09/10/13 11:41, Paul Syverson wrote:
These two changes combined should help with the two goals. Reliability
is improved by having multiple OP's providing the service, and having
all of these accessible from the introduction points. Scalability is
also improved, as you are not limited to one
On 08/10/13 23:41, Nick Mathewson wrote:
Here are some possible desirable things. I don't know if they're all
important, or all worth it. Let's discuss!
So, I think it makes more sense to cover the goals first.
Goal 1) Obscure number of hidden service instances.
Good to have, as it
16 matches
Mail list logo
