El 09/05/14 16:03, Christopher Baines escribió:
Maybe a good idea would be to try to reconnect and if it is
failing too much select another IP.
It currently does do this, but on probably a shorter time period
than you are suggesting. It keeps a count of connection failures
while trying to reconn
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
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. I don't know if this is possi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/05/14 14:31, Christopher Baines wrote:
> How do you see the guards being "scheduled" for replacement?
Two possibilities (there are probably others):
1. Periodically select a new guard by hashing a secret key and the
date, similar to the way H
On 09/05/14 10:14, Michael Rogers wrote:
> On 08/05/14 14:40, Christopher Baines wrote:
>>> Perhaps it would make sense to pick one or more IPs per guard,
>>> and change those IPs when the guard is changed? Then waldo's
>>> attack by a malicious IP would only ever discover one guard.
>
>> If you c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/05/14 14:40, Christopher Baines wrote:
>> Perhaps it would make sense to pick one or more IPs per guard,
>> and change those IPs when the guard is changed? Then waldo's
>> attack by a malicious IP would only ever discover one guard.
>
> If you
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
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'
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
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/05/14 22:07, Christopher Baines wrote:
> On 06/05/14 15:29, Michael Rogers wrote:
>> Does this mean that at present, the service builds a new IP
>> circuit (to a new IP?) every time it receives a connection? If
>> so, is it the IP or the servic
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/05/14 22:17, Christopher Baines wrote:
> 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 hidd
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 connec
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
>> i
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
> if the situation can be improved by choosing introdu
On 06/05/14 20:13, Nicholas Hopper wrote:
> On Sat, May 3, 2014 at 5:58 AM, Christopher Baines 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 in the connection
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 connectivity. I wonder
> if the situation can be impro
On Sat, May 3, 2014 at 5:58 AM, Christopher Baines 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 in the connection to introduction
>>> points (a return to the stat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Christopher,
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
if the situation can be improved by
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. I don't know if this is possible
>>> but I am worried that if you pick
El 02/05/14 02:34, Christopher Baines escribió:
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. On
On 03/05/14 11:21, George Kadianakis wrote:
> Christopher Baines writes:
>
>> On 08/10/13 06:52, Christopher Baines wrote:
>> In short, I modified tor such that:
>> - The services public key is used in the connection to introduction
>> points (a return to the state as of the v0 descriptor)
>
>
Christopher Baines writes:
> 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
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 mi
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 to make some progress, is the Hidd
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
On Sun, Oct 13, 2013 at 10:22:29PM +0100, Christopher Baines wrote:
> On 09/10/13 18:05, Matthew Finkel 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 fr
Christopher Baines writes:
> 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 mult
If the goal is to prevent introduction points from guessing the number
of instances because of multiple instances using the same introduction
points, shouldn't this scheme work?
1. On deployment, all instances of a hidden service have a copy of a
secret bitstring (maybe the private key for the hid
On 09/10/13 18:05, Matthew Finkel 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 no
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, an
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 of these accessible fro
On Wed, Oct 09, 2013 at 09:58:07AM +0100, Christopher Baines wrote:
> On 09/10/13 01:16, Matthew Finkel wrote:
> >> Then comes the second problem, following the above, the introduction
> >> point would then disconnect from any other connected OP using the same
> >> public key (unsure why as a reas
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
On Wed, Oct 09, 2013 at 09:58:07AM +0100, Christopher Baines wrote:
> On 09/10/13 01:16, Matthew Finkel wrote:
> >> Then comes the second problem, following the above, the introduction
> >> point would then disconnect from any other connected OP using the same
> >> public key (unsure why as a reas
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
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 proba
Hi Christopher,
It's great that you started thinking about a design (and the potential
obstacles). I will try not to reiterate what Nick already said, though.
On Tue, Oct 08, 2013 at 06:52:39AM +0100, Christopher Baines wrote:
> I have been looking at doing some work on Tor as part of my degree,
On Tue, Oct 8, 2013 at 1:52 AM, 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 d
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].
So, before I start trying to implement a protot
39 matches
Mail list logo
