On Thursday 14 August 2008 20:10, Michael Rogers wrote:
> On Aug 13 2008, Theodore Hong wrote:
> >An explicit list of the keys in the store does provide extra value for
> >the attacker over having an oracle that says whether or not a given
> >key is in the store. The attacker can use it to view th
On Aug 14 2008, Daniel Cheng wrote:
>The store is also encrypted with a per-store key.
>In case of emergency,
>just erasing the key from disk would make the whole store unusable.
>
>Overwriting 16 bytes is far easier then overwriting the whole store.
>
>I am not sure if this worth the effort, but t
On Aug 13 2008, Theodore Hong wrote:
>An explicit list of the keys in the store does provide extra value for
>the attacker over having an oracle that says whether or not a given
>key is in the store. The attacker can use it to view the entire
>plaintext contents of the store. It's the same as the
On Thursday 14 August 2008 20:10, Michael Rogers wrote:
> On Aug 13 2008, Theodore Hong wrote:
> >An explicit list of the keys in the store does provide extra value for
> >the attacker over having an oracle that says whether or not a given
> >key is in the store. The attacker can use it to view th
* Daniel Cheng [2008-08-14 09:47:48]:
> On Thu, Aug 14, 2008 at 4:57 AM, Michael Rogers
> wrote:
> > On Aug 12 2008, Matthew Toseland wrote:
> >> We can increase the cost significantly and thereby slow the attacker
> >> down. It's still possible, but it's no longer trivial, because they have
>
On Aug 14 2008, Daniel Cheng wrote:
>The store is also encrypted with a per-store key.
>In case of emergency,
>just erasing the key from disk would make the whole store unusable.
>
>Overwriting 16 bytes is far easier then overwriting the whole store.
>
>I am not sure if this worth the effort, but t
On Aug 13 2008, Theodore Hong wrote:
>An explicit list of the keys in the store does provide extra value for
>the attacker over having an oracle that says whether or not a given
>key is in the store. The attacker can use it to view the entire
>plaintext contents of the store. It's the same as the
On Thu, Aug 14, 2008 at 4:57 AM, Michael Rogers
wrote:
> On Aug 12 2008, Matthew Toseland wrote:
>> We can increase the cost significantly and thereby slow the attacker
>> down. It's still possible, but it's no longer trivial, because they have
>> to try every key they are interested in against e
* Daniel Cheng <[EMAIL PROTECTED]> [2008-08-14 09:47:48]:
> On Thu, Aug 14, 2008 at 4:57 AM, Michael Rogers <[EMAIL PROTECTED]> wrote:
> > On Aug 12 2008, Matthew Toseland wrote:
> >> We can increase the cost significantly and thereby slow the attacker
> >> down. It's still possible, but it's no l
Michael Rogers wrote:
> Strictly speaking it's true that obfuscating the store prevents an attacker
> from enumerating the keys it contains, but that's not really relevant
> because the attacker doesn't want a list of the keys in the store - they
> want to know whether certain keys are in the stor
On Aug 12 2008, Matthew Toseland wrote:
> We can increase the cost significantly and thereby slow the attacker
> down. It's still possible, but it's no longer trivial, because they have
> to try every key they are interested in against every block in the store
No they don't. They just unplug the
On Thu, Aug 14, 2008 at 4:57 AM, Michael Rogers <[EMAIL PROTECTED]> wrote:
> On Aug 12 2008, Matthew Toseland wrote:
>> We can increase the cost significantly and thereby slow the attacker
>> down. It's still possible, but it's no longer trivial, because they have
>> to try every key they are inter
Michael Rogers <[EMAIL PROTECTED]> wrote:
> Strictly speaking it's true that obfuscating the store prevents an attacker
> from enumerating the keys it contains, but that's not really relevant
> because the attacker doesn't want a list of the keys in the store - they
> want to know whether certain k
On Aug 12 2008, Matthew Toseland wrote:
> We can increase the cost significantly and thereby slow the attacker
> down. It's still possible, but it's no longer trivial, because they have
> to try every key they are interested in against every block in the store
No they don't. They just unplug the
On Tuesday 12 August 2008 21:31, Michael Rogers wrote:
> On Aug 12 2008, Matthew Toseland wrote:
> >No. You can only decrypt the data if you have the key. :)
> >
> > Seriously, we encrypt the blocks in the salted hash datastore with a key
> > derived from the key of the block. And we index them by
On Aug 12 2008, Matthew Toseland wrote:
>No. You can only decrypt the data if you have the key. :)
>
> Seriously, we encrypt the blocks in the salted hash datastore with a key
> derived from the key of the block. And we index them by a different hash
> of the same key. This increases the cost of
On Tuesday 12 August 2008 18:14, Michael Rogers wrote:
> On Aug 11 2008, Matthew Toseland wrote:
> >> The full key can still be calculated from the data though, right? So not
> >> storing the key would only slow enumeration down.
> >
> >No. You can only decrypt the data if you have the key.
>
> I
On Aug 11 2008, Matthew Toseland wrote:
>> The full key can still be calculated from the data though, right? So not
>> storing the key would only slow enumeration down.
>
>No. You can only decrypt the data if you have the key.
I don't think we're talking about decrypting the data, just getting a l
On Tuesday 12 August 2008 21:31, Michael Rogers wrote:
> On Aug 12 2008, Matthew Toseland wrote:
> >No. You can only decrypt the data if you have the key. :)
> >
> > Seriously, we encrypt the blocks in the salted hash datastore with a key
> > derived from the key of the block. And we index them by
On Aug 12 2008, Matthew Toseland wrote:
>No. You can only decrypt the data if you have the key. :)
>
> Seriously, we encrypt the blocks in the salted hash datastore with a key
> derived from the key of the block. And we index them by a different hash
> of the same key. This increases the cost of
On Tuesday 12 August 2008 18:14, Michael Rogers wrote:
> On Aug 11 2008, Matthew Toseland wrote:
> >> The full key can still be calculated from the data though, right? So not
> >> storing the key would only slow enumeration down.
> >
> >No. You can only decrypt the data if you have the key.
>
> I
On Aug 11 2008, Matthew Toseland wrote:
>> The full key can still be calculated from the data though, right? So not
>> storing the key would only slow enumeration down.
>
>No. You can only decrypt the data if you have the key.
I don't think we're talking about decrypting the data, just getting a l
On Sunday 10 August 2008 15:05, Michael Rogers wrote:
> Daniel Cheng wrote:
> > We digest the key in data store to prevent enumeration of keys in the
store.
> > If we store the actual location, it would defect this purpose..
> > I suggest storing the location as float, which is only 4 bytes and ma
On Sunday 10 August 2008 15:05, Michael Rogers wrote:
> Daniel Cheng wrote:
> > We digest the key in data store to prevent enumeration of keys in the
store.
> > If we store the actual location, it would defect this purpose..
> > I suggest storing the location as float, which is only 4 bytes and ma
On Wed, Aug 6, 2008 at 11:50 PM, Michael Rogers
wrote:
> Ed Tomlinson wrote:
>>> Do we need to store the location for each key? (so that we can update
>>> the average location when the key is removed)
>>> Maybe a running average is just good enough?
>>> Or just store an approximated location, not
Daniel Cheng wrote:
> We digest the key in data store to prevent enumeration of keys in the store.
> If we store the actual location, it would defect this purpose..
> I suggest storing the location as float, which is only 4 bytes and may
> enumeration much more difficult.
Ah, I see - floats sounds
Daniel Cheng wrote:
> We digest the key in data store to prevent enumeration of keys in the store.
> If we store the actual location, it would defect this purpose..
> I suggest storing the location as float, which is only 4 bytes and may
> enumeration much more difficult.
Ah, I see - floats sounds
On Wed, Aug 6, 2008 at 11:50 PM, Michael Rogers <[EMAIL PROTECTED]> wrote:
> Ed Tomlinson wrote:
>>> Do we need to store the location for each key? (so that we can update
>>> the average location when the key is removed)
>>> Maybe a running average is just good enough?
>>> Or just store an approxim
On Wed, Aug 6, 2008 at 7:14 AM, Matthew Toseland
wrote:
> On Tuesday 05 August 2008 23:11, Ed Tomlinson wrote:
>> On August 5, 2008, Matthew Toseland wrote:
>> > On Sunday 03 August 2008 00:58, you wrote:
>> > > On August 2, 2008, Matthew Toseland wrote:
>> > > > On Saturday 02 August 2008 02:41,
Ed Tomlinson wrote:
>> Do we need to store the location for each key? (so that we can update
>> the average location when the key is removed)
>> Maybe a running average is just good enough?
>> Or just store an approximated location, not the actual value?
>
> A salted location would work as long as
On Wednesday 06 August 2008 13:06, Ed Tomlinson wrote:
> On August 6, 2008, Daniel Cheng wrote:
> > On Wed, Aug 6, 2008 at 7:14 AM, Matthew Toseland
> > wrote:
> > > On Tuesday 05 August 2008 23:11, Ed Tomlinson wrote:
> > >> On August 5, 2008, Matthew Toseland wrote:
> > >> > On Sunday 03 August
Ed Tomlinson wrote:
>> Do we need to store the location for each key? (so that we can update
>> the average location when the key is removed)
>> Maybe a running average is just good enough?
>> Or just store an approximated location, not the actual value?
>
> A salted location would work as long as
On Wednesday 06 August 2008 13:06, Ed Tomlinson wrote:
> On August 6, 2008, Daniel Cheng wrote:
> > On Wed, Aug 6, 2008 at 7:14 AM, Matthew Toseland
> > <[EMAIL PROTECTED]> wrote:
> > > On Tuesday 05 August 2008 23:11, Ed Tomlinson wrote:
> > >> On August 5, 2008, Matthew Toseland wrote:
> > >> > O
On August 6, 2008, Daniel Cheng wrote:
> On Wed, Aug 6, 2008 at 7:14 AM, Matthew Toseland
> wrote:
> > On Tuesday 05 August 2008 23:11, Ed Tomlinson wrote:
> >> On August 5, 2008, Matthew Toseland wrote:
> >> > On Sunday 03 August 2008 00:58, you wrote:
> >> > > On August 2, 2008, Matthew Toseland
On August 6, 2008, Daniel Cheng wrote:
> On Wed, Aug 6, 2008 at 7:14 AM, Matthew Toseland
> <[EMAIL PROTECTED]> wrote:
> > On Tuesday 05 August 2008 23:11, Ed Tomlinson wrote:
> >> On August 5, 2008, Matthew Toseland wrote:
> >> > On Sunday 03 August 2008 00:58, you wrote:
> >> > > On August 2, 200
On Wed, Aug 6, 2008 at 7:14 AM, Matthew Toseland
<[EMAIL PROTECTED]> wrote:
> On Tuesday 05 August 2008 23:11, Ed Tomlinson wrote:
>> On August 5, 2008, Matthew Toseland wrote:
>> > On Sunday 03 August 2008 00:58, you wrote:
>> > > On August 2, 2008, Matthew Toseland wrote:
>> > > > On Saturday 02
On Tuesday 05 August 2008 23:11, Ed Tomlinson wrote:
> On August 5, 2008, Matthew Toseland wrote:
> > On Sunday 03 August 2008 00:58, you wrote:
> > > On August 2, 2008, Matthew Toseland wrote:
> > > > On Saturday 02 August 2008 02:41, Ed Tomlinson wrote:
> > > > > On August 1, 2008, Michael Rogers
On August 5, 2008, Matthew Toseland wrote:
> On Sunday 03 August 2008 00:58, you wrote:
> > On August 2, 2008, Matthew Toseland wrote:
> > > On Saturday 02 August 2008 02:41, Ed Tomlinson wrote:
> > > > On August 1, 2008, Michael Rogers wrote:
> > > > > Daniel Cheng wrote:
> > > > > > in a circular
On Tuesday 05 August 2008 23:11, Ed Tomlinson wrote:
> On August 5, 2008, Matthew Toseland wrote:
> > On Sunday 03 August 2008 00:58, you wrote:
> > > On August 2, 2008, Matthew Toseland wrote:
> > > > On Saturday 02 August 2008 02:41, Ed Tomlinson wrote:
> > > > > On August 1, 2008, Michael Rogers
On August 5, 2008, Matthew Toseland wrote:
> On Sunday 03 August 2008 00:58, you wrote:
> > On August 2, 2008, Matthew Toseland wrote:
> > > On Saturday 02 August 2008 02:41, Ed Tomlinson wrote:
> > > > On August 1, 2008, Michael Rogers wrote:
> > > > > Daniel Cheng wrote:
> > > > > > in a circular
On Sunday 03 August 2008 00:58, you wrote:
> On August 2, 2008, Matthew Toseland wrote:
> > On Saturday 02 August 2008 02:41, Ed Tomlinson wrote:
> > > On August 1, 2008, Michael Rogers wrote:
> > > > Daniel Cheng wrote:
> > > > > in a circular space, we can get infinite number of "average" by
cha
On August 3, 2008, Ian Clarke wrote:
> On Sat, Aug 2, 2008 at 6:58 PM, Ed Tomlinson wrote:
> > No I have _not_ missed the point. If you map each key onto the rim of a
> > circle and
> > average resulting the x and y coords of all the keys you get an average in
> > a circular
> > keyspace. Try
On Sunday 03 August 2008 00:58, you wrote:
> On August 2, 2008, Matthew Toseland wrote:
> > On Saturday 02 August 2008 02:41, Ed Tomlinson wrote:
> > > On August 1, 2008, Michael Rogers wrote:
> > > > Daniel Cheng wrote:
> > > > > in a circular space, we can get infinite number of "average" by
cha
On August 3, 2008, Ian Clarke wrote:
> On Sat, Aug 2, 2008 at 6:58 PM, Ed Tomlinson <[EMAIL PROTECTED]> wrote:
> > No I have _not_ missed the point. If you map each key onto the rim of a
> > circle and
> > average resulting the x and y coords of all the keys you get an average in
> > a circular
Ed Tomlinson wrote:
> No I have _not_ missed the point. If you map each key onto the rim
> of a circle and average resulting the x and y coords of all the keys
> you get an average in a circular keyspace. Try it.
Oh sorry I was being dense, to convert back you do arctan(avg_x/avg_y)
to get the a
Ed Tomlinson wrote:
>>> eg x = sin (key * 360), y = cos(key * 360) assuming the angle
>>> is in degrees not radians.
>>> where a key is a number between 0 and 1
>> You miss the point. We already have what is effectively an angle,
>> it's just in 0 to 1 instead of 0 to 360 deg / 2*pi rads. The
>>
On Sat, Aug 2, 2008 at 6:58 PM, Ed Tomlinson wrote:
> No I have _not_ missed the point. If you map each key onto the rim of a
> circle and
> average resulting the x and y coords of all the keys you get an average in a
> circular
> keyspace. Try it.
>
> If fact radius of the averaged x, y will
On Sat, Aug 2, 2008 at 6:58 PM, Ed Tomlinson <[EMAIL PROTECTED]> wrote:
> No I have _not_ missed the point. If you map each key onto the rim of a
> circle and
> average resulting the x and y coords of all the keys you get an average in a
> circular
> keyspace. Try it.
>
> If fact radius of the
Ed Tomlinson wrote:
> No I have _not_ missed the point. If you map each key onto the rim
> of a circle and average resulting the x and y coords of all the keys
> you get an average in a circular keyspace. Try it.
Oh sorry I was being dense, to convert back you do arctan(avg_x/avg_y)
to get the a
Ed Tomlinson wrote:
>>> eg x = sin (key * 360), y = cos(key * 360) assuming the angle
>>> is in degrees not radians.
>>> where a key is a number between 0 and 1
>> You miss the point. We already have what is effectively an angle,
>> it's just in 0 to 1 instead of 0 to 360 deg / 2*pi rads. The
>>
On Saturday 02 August 2008 03:43, Daniel Cheng wrote:
> On Fri, Aug 1, 2008 at 11:52 PM, Michael Rogers
wrote:
> > Daniel Cheng wrote:
> >> in a circular space, we can get infinite number of "average" by changing
> >> point of reference. --- choose the point of reference with the smallest
> >> st
On Saturday 02 August 2008 02:41, Ed Tomlinson wrote:
> On August 1, 2008, Michael Rogers wrote:
> > Daniel Cheng wrote:
> > > in a circular space, we can get infinite number of "average" by changing
> > > point of reference. --- choose the point of reference with the smallest
> > > standard deviat
On August 2, 2008, Matthew Toseland wrote:
> On Saturday 02 August 2008 02:41, Ed Tomlinson wrote:
> > On August 1, 2008, Michael Rogers wrote:
> > > Daniel Cheng wrote:
> > > > in a circular space, we can get infinite number of "average" by changing
> > > > point of reference. --- choose the point
On August 2, 2008, Matthew Toseland wrote:
> On Saturday 02 August 2008 02:41, Ed Tomlinson wrote:
> > On August 1, 2008, Michael Rogers wrote:
> > > Daniel Cheng wrote:
> > > > in a circular space, we can get infinite number of "average" by changing
> > > > point of reference. --- choose the point
On Saturday 02 August 2008 03:43, Daniel Cheng wrote:
> On Fri, Aug 1, 2008 at 11:52 PM, Michael Rogers <[EMAIL PROTECTED]>
wrote:
> > Daniel Cheng wrote:
> >> in a circular space, we can get infinite number of "average" by changing
> >> point of reference. --- choose the point of reference with t
On Saturday 02 August 2008 02:41, Ed Tomlinson wrote:
> On August 1, 2008, Michael Rogers wrote:
> > Daniel Cheng wrote:
> > > in a circular space, we can get infinite number of "average" by changing
> > > point of reference. --- choose the point of reference with the smallest
> > > standard deviat
On Fri, Aug 1, 2008 at 11:52 PM, Michael Rogers
wrote:
> Daniel Cheng wrote:
>> in a circular space, we can get infinite number of "average" by changing
>> point of reference. --- choose the point of reference with the smallest
>> standard deviation.
>
> From an infinite number of alternatives? S
On Fri, Aug 1, 2008 at 10:39 PM, Theodore Hong
wrote:
> Ian Clarke wrote:
>> On Thu, Jul 31, 2008 at 5:22 PM, Matthew Toseland
>> wrote:
>>> On Thursday 31 July 2008 17:42, Florent Daigni?re wrote:
>>> IMHO the problem is location churn. The solution is for opennet nodes not to
>>> swap. But we
On August 1, 2008, Michael Rogers wrote:
> Daniel Cheng wrote:
> > in a circular space, we can get infinite number of "average" by changing
> > point of reference. --- choose the point of reference with the smallest
> > standard deviation.
>
> From an infinite number of alternatives? Sounds like i
On Fri, Aug 1, 2008 at 11:52 PM, Michael Rogers <[EMAIL PROTECTED]> wrote:
> Daniel Cheng wrote:
>> in a circular space, we can get infinite number of "average" by changing
>> point of reference. --- choose the point of reference with the smallest
>> standard deviation.
>
> From an infinite number
On August 1, 2008, Michael Rogers wrote:
> Daniel Cheng wrote:
> > in a circular space, we can get infinite number of "average" by changing
> > point of reference. --- choose the point of reference with the smallest
> > standard deviation.
>
> From an infinite number of alternatives? Sounds like i
Daniel Cheng wrote:
> in a circular space, we can get infinite number of "average" by changing
> point of reference. --- choose the point of reference with the smallest
> standard deviation.
>From an infinite number of alternatives? Sounds like it might take a
while. ;-) I think we can get away wi
On Friday 01 August 2008 16:23, Daniel Cheng wrote:
> On Fri, Aug 1, 2008 at 10:39 PM, Theodore Hong
> wrote:
> > Ian Clarke wrote:
> >> On Thu, Jul 31, 2008 at 5:22 PM, Matthew Toseland
> >> wrote:
> >>> On Thursday 31 July 2008 17:42, Florent Daigni?re wrote:
> >>> IMHO the problem is location
On Friday 01 August 2008 15:39, Theodore Hong wrote:
> Ian Clarke wrote:
> > On Thu, Jul 31, 2008 at 5:22 PM, Matthew Toseland
> > wrote:
> >> On Thursday 31 July 2008 17:42, Florent Daigni?re wrote:
> >> IMHO the problem is location churn. The solution is for opennet nodes not
to
> >> swap. But
Ian Clarke wrote:
> On Thu, Jul 31, 2008 at 5:22 PM, Matthew Toseland
> wrote:
>> On Thursday 31 July 2008 17:42, Florent Daigni?re wrote:
>> IMHO the problem is location churn. The solution is for opennet nodes not to
>> swap. But we need simulations before we can deploy that. Which Vive promise
On Fri, Aug 1, 2008 at 6:46 AM, Michael Rogers wrote:
> Ed Tomlinson wrote:
>> Not at all. Think that churn is making data much harder to find.
>> While I think FOF routing will help shorten path lenghts, I do not
>> think its going to help find older data all that much faster. I
>> would love t
On Thu, Jul 31, 2008 at 5:22 PM, Matthew Toseland
wrote:
> On Thursday 31 July 2008 17:42, Florent Daigni?re wrote:
> IMHO the problem is location churn. The solution is for opennet nodes not to
> swap. But we need simulations before we can deploy that. Which Vive promised
> to do...
Why would op
Daniel Cheng wrote:
> in a circular space, we can get infinite number of "average" by changing
> point of reference. --- choose the point of reference with the smallest
> standard deviation.
>From an infinite number of alternatives? Sounds like it might take a
while. ;-) I think we can get away wi
On Friday 01 August 2008 16:23, Daniel Cheng wrote:
> On Fri, Aug 1, 2008 at 10:39 PM, Theodore Hong
> <[EMAIL PROTECTED]> wrote:
> > Ian Clarke <[EMAIL PROTECTED]> wrote:
> >> On Thu, Jul 31, 2008 at 5:22 PM, Matthew Toseland
> >> <[EMAIL PROTECTED]> wrote:
> >>> On Thursday 31 July 2008 17:42, Fl
On Friday 01 August 2008 15:39, Theodore Hong wrote:
> Ian Clarke <[EMAIL PROTECTED]> wrote:
> > On Thu, Jul 31, 2008 at 5:22 PM, Matthew Toseland
> > <[EMAIL PROTECTED]> wrote:
> >> On Thursday 31 July 2008 17:42, Florent Daignière wrote:
> >> IMHO the problem is location churn. The solution is fo
On Fri, Aug 1, 2008 at 10:39 PM, Theodore Hong
<[EMAIL PROTECTED]> wrote:
> Ian Clarke <[EMAIL PROTECTED]> wrote:
>> On Thu, Jul 31, 2008 at 5:22 PM, Matthew Toseland
>> <[EMAIL PROTECTED]> wrote:
>>> On Thursday 31 July 2008 17:42, Florent Daignière wrote:
>>> IMHO the problem is location churn. T
Ian Clarke <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 31, 2008 at 5:22 PM, Matthew Toseland
> <[EMAIL PROTECTED]> wrote:
>> On Thursday 31 July 2008 17:42, Florent Daignière wrote:
>> IMHO the problem is location churn. The solution is for opennet nodes not to
>> swap. But we need simulations before
On Thu, Jul 31, 2008 at 5:22 PM, Matthew Toseland
<[EMAIL PROTECTED]> wrote:
> On Thursday 31 July 2008 17:42, Florent Daignière wrote:
> IMHO the problem is location churn. The solution is for opennet nodes not to
> swap. But we need simulations before we can deploy that. Which Vive promised
> to
Ed Tomlinson wrote:
> Not at all. Think that churn is making data much harder to find.
> While I think FOF routing will help shorten path lenghts, I do not
> think its going to help find older data all that much faster. I
> would love to see some simulations where the average location of the
> st
On Thursday 31 July 2008 17:42, Florent Daigni?re wrote:
> * Matthew Toseland [2008-07-31 17:37:41]:
>
> > On Tuesday 22 July 2008 23:33, Florent Daigni?re wrote:
> > > * Robert Mead [2008-07-22 18:21:14]:
> > >
> > > > So it sounds like it will be about as secure as it currently is, but a
> >
On Fri, Aug 1, 2008 at 6:46 AM, Michael Rogers <[EMAIL PROTECTED]> wrote:
> Ed Tomlinson wrote:
>> Not at all. Think that churn is making data much harder to find.
>> While I think FOF routing will help shorten path lenghts, I do not
>> think its going to help find older data all that much faster.
* Matthew Toseland [2008-07-31 17:37:41]:
> On Tuesday 22 July 2008 23:33, Florent Daigni?re wrote:
> > * Robert Mead [2008-07-22 18:21:14]:
> >
> > > So it sounds like it will be about as secure as it currently is, but a
> > > lot more efficient. 5 to 3 is a big difference.
> >
> > ... On a
On July 31, 2008, Florent Daigni?re wrote:
> * Matthew Toseland [2008-07-31 17:37:41]:
>
> > On Tuesday 22 July 2008 23:33, Florent Daigni?re wrote:
> > > * Robert Mead [2008-07-22 18:21:14]:
> > >
> > > > So it sounds like it will be about as secure as it currently is, but a
> > > > lot more
Florent Daigni?re wrote:
> * Matthew Toseland [2008-07-31 17:37:41]:
>
>> On Tuesday 22 July 2008 23:33, Florent Daigni?re wrote:
>>> * Robert Mead [2008-07-22 18:21:14]:
>>>
So it sounds like it will be about as secure as it currently is, but a
lot more efficient. 5 to 3 is a big dif
On Tuesday 22 July 2008 23:33, Florent Daigni?re wrote:
> * Robert Mead [2008-07-22 18:21:14]:
>
> > So it sounds like it will be about as secure as it currently is, but a
> > lot more efficient. 5 to 3 is a big difference.
>
> ... On a small, ideal network.
On a larger, messier network, it sh
Ed Tomlinson wrote:
> Not at all. Think that churn is making data much harder to find.
> While I think FOF routing will help shorten path lenghts, I do not
> think its going to help find older data all that much faster. I
> would love to see some simulations where the average location of the
> st
Florent Daignière wrote:
> * Matthew Toseland <[EMAIL PROTECTED]> [2008-07-31 17:37:41]:
>
>> On Tuesday 22 July 2008 23:33, Florent Daignière wrote:
>>> * Robert Mead <[EMAIL PROTECTED]> [2008-07-22 18:21:14]:
>>>
So it sounds like it will be about as secure as it currently is, but a
l
* Matthew Toseland <[EMAIL PROTECTED]> [2008-07-31 17:37:41]:
> On Tuesday 22 July 2008 23:33, Florent Daignière wrote:
> > * Robert Mead <[EMAIL PROTECTED]> [2008-07-22 18:21:14]:
> >
> > > So it sounds like it will be about as secure as it currently is, but a
> > > lot more efficient. 5 to 3 i
On Thursday 24 July 2008 10:15, Volodya wrote:
> Matthew Toseland wrote:
> > 3) Limit any single node to no more than 30% of our outgoing requests.
This
> > would help in that getting 100% of a node's outgoing requests wouldn't be
> > possible... but it wouldn't solve the problem. If an attacker
Matthew Toseland wrote:
> 3) Limit any single node to no more than 30% of our outgoing requests. This
> would help in that getting 100% of a node's outgoing requests wouldn't be
> possible... but it wouldn't solve the problem. If an attacker's objective is
> to capture all the locally originated
On Thursday 24 July 2008 10:15, Volodya wrote:
> Matthew Toseland wrote:
> > 3) Limit any single node to no more than 30% of our outgoing requests.
This
> > would help in that getting 100% of a node's outgoing requests wouldn't be
> > possible... but it wouldn't solve the problem. If an attacker
Matthew Toseland wrote:
> 3) Limit any single node to no more than 30% of our outgoing requests. This
> would help in that getting 100% of a node's outgoing requests wouldn't be
> possible... but it wouldn't solve the problem. If an attacker's objective is
> to capture all the locally originated
Matthew Toseland wrote:
> So you are saying that we should only worry about FOAF on darknet, where
> there
> clearly is an FOAF-specific problem?
I'm saying that limiting the number of FOAF locations each peer can send
us is probably a good enough solution, given that similar
non-FOAF-specific a
On Wednesday 23 July 2008 12:38, Michael Rogers wrote:
> Matthew Toseland wrote:
> > Why/how is this exacerbated by FOAF-routing exactly? If it isn't then it's
> > orthogonal.
>
> Exactly - the problem of an attacker being able to attract most of our
> traffic isn't specific to FOAF, so there's n
Matthew Toseland wrote:
> Why/how is this exacerbated by FOAF-routing exactly? If it isn't then it's
> orthogonal.
Exactly - the problem of an attacker being able to attract most of our
traffic isn't specific to FOAF, so there's no point looking for a
FOAF-specific solution.
Cheers,
Michael
Matthew Toseland wrote:
> So you are saying that we should only worry about FOAF on darknet, where
> there
> clearly is an FOAF-specific problem?
I'm saying that limiting the number of FOAF locations each peer can send
us is probably a good enough solution, given that similar
non-FOAF-specific a
On Wednesday 23 July 2008 12:38, Michael Rogers wrote:
> Matthew Toseland wrote:
> > Why/how is this exacerbated by FOAF-routing exactly? If it isn't then it's
> > orthogonal.
>
> Exactly - the problem of an attacker being able to attract most of our
> traffic isn't specific to FOAF, so there's n
Matthew Toseland wrote:
> Why/how is this exacerbated by FOAF-routing exactly? If it isn't then it's
> orthogonal.
Exactly - the problem of an attacker being able to attract most of our
traffic isn't specific to FOAF, so there's no point looking for a
FOAF-specific solution.
Cheers,
Michael
* Robert Mead [2008-07-22 18:21:14]:
> So it sounds like it will be about as secure as it currently is, but a
> lot more efficient. 5 to 3 is a big difference.
>
... On a small, ideal network.
NextGen$
-- next part --
A non-text attachment was scrubbed...
Name: signatu
* Michael Rogers [2008-07-22 22:38:12]:
> Matthew Toseland wrote:
> > Should we enable FOAF routing anyway, and if so, which mitigation measures
> > do
> > we need to implement first? Note that encrypted tunnels would not solve
> > this
> > problem, as they are impacted by it also (if we do r
On Tuesday 22 July 2008 23:21, Robert Mead wrote:
> So it sounds like it will be about as secure as it currently is, but a
> lot more efficient. 5 to 3 is a big difference.
>
> How about opt-in for the next version? I'd turn it on.
It's configurable, but we have to decide what the default will b
On Tuesday 22 July 2008 22:38, Michael Rogers wrote:
> Matthew Toseland wrote:
> > Should we enable FOAF routing anyway, and if so, which mitigation measures
do
> > we need to implement first? Note that encrypted tunnels would not solve
this
> > problem, as they are impacted by it also (if we d
Matthew Toseland wrote:
> Should we enable FOAF routing anyway, and if so, which mitigation measures do
> we need to implement first? Note that encrypted tunnels would not solve this
> problem, as they are impacted by it also (if we do rendezvous at a key, and
> use FOAF-routing; random walk ren
Two more possible solutions...
On Tuesday 22 July 2008 21:15, Matthew Toseland wrote:
> So far, various solutions to FOAF-routing vulnerabilities have been
proposed:
>
> 1) Limit an opennet peer to advertising 19 of its peers' locations (plus
> ours). Nextgens has implemented this. It's not a f
So far, various solutions to FOAF-routing vulnerabilities have been proposed:
1) Limit an opennet peer to advertising 19 of its peers' locations (plus
ours). Nextgens has implemented this. It's not a full solution. We need to
impose some limit on darknet peers too, but even then, a clever node c
1 - 100 of 109 matches
Mail list logo
