--- Toad [EMAIL PROTECTED] wrote:
On Sat, Nov 01, 2003 at 03:19:43PM -0800, pineapple
wrote:
Uh oh! I have another idea for this! Another
weakness with this attack is the assumption that
is
made about what constitutes a nearby key. Right
now
all nodes arrange their estimator
only way to find out would be to gather the estimator graphs
from many nodes and compare them to see if a node has some
kind of global estimator graph, or if a node has a
different graph for each node that has an estimator for it.
That would be very useful I think. Write the script and
--- Some Guy [EMAIL PROTECTED] wrote:
--- pineapple [EMAIL PROTECTED] wrote:
--- Nick Tarleton [EMAIL PROTECTED] wrote:
Maybe just XOR with a randomly chosen
node-private
value. But won't this fubar
routing and specialization, if each node has a
different ordering in its
--- pineapple [EMAIL PROTECTED] schrieb:
--- Some Guy [EMAIL PROTECTED] wrote:
--- pineapple [EMAIL PROTECTED] wrote:
--- Nick Tarleton [EMAIL PROTECTED] wrote:
Maybe just XOR with a randomly chosen
node-private
value. But won't this fubar
routing and specialization,
--- Some Guy [EMAIL PROTECTED] wrote:
--- pineapple [EMAIL PROTECTED] schrieb:
--- Some Guy [EMAIL PROTECTED] wrote:
--- pineapple [EMAIL PROTECTED]
wrote:
--- Nick Tarleton [EMAIL PROTECTED]
wrote:
Maybe just XOR with a randomly chosen
node-private
value. But
On Sat, Nov 01, 2003 at 03:19:43PM -0800, pineapple wrote:
Uh oh! I have another idea for this! Another
weakness with this attack is the assumption that is
made about what constitutes a nearby key. Right now
all nodes arrange their estimator keyspace internally
in the same manner. Why?
--- Nick Tarleton [EMAIL PROTECTED] wrote:
Maybe just XOR with a randomly chosen node-private
value. But won't this fubar
routing and specialization, if each node has a
different ordering in its
routing? Or do I misunderstand what is meant by
estimator keyspace?
--
Since the ordering
On Sun, 2003-11-02 at 09:08, pineapple wrote:
Actually, I withdraw my last proposal. I think this
one would work much better. So the two proposals for
thwarting Toad's key DoS scenario are:
1) Hash-cash - works by making requesters pay a price
for each request.
2) Estimator keyspace
My previous proposal was dynamic estimators, but it
would be slow to compensate and hard to implement.
Forget I mentioned it :) Also, I'd like to add a
third item to my list:
3) Tom's decentralized positive trust biased model -
solves the DoS problem and is much more usefull for
solving other
Uh oh! I have another idea for this! Another
weakness with this attack is the assumption that is
made about what constitutes a nearby key. Right now
all nodes arrange their estimator keyspace internally
in the same manner. Why? The keys are encrypted so
they are essentially random and
On Saturday 01 November 2003 06:19 pm, pineapple wrote:
Uh oh! I have another idea for this! Another
weakness with this attack is the assumption that is
made about what constitutes a nearby key. Right now
all nodes arrange their estimator keyspace internally
in the same manner. Why? The
11 matches
Mail list logo
