On Thu, Dec 28, 2000 at 06:09:11PM -0800, Mr.Bad wrote:
> >>>>> "IC" == Ian Clarke <[EMAIL PROTECTED]> writes:
>
> IC> So I was sitting in the bath this-morning and I think I may
> IC> have the beginnings of an idea about how to address this issue
>
> Isn't that how all the best ideas get done? B-)
Yep, I didn't shout "Eureka!" though.
> IC> Let's say, on the introduction of public/private key
> IC> inter-node comms, a node address looks like
> IC> ptcp/x.x.x.x:yy/PUBKEYPUBKEY
>
> As an aside -- is there someplace I can find the proposal for pk in
> Freenet? Or is it one more of those hivemind designs that Freenet is
> famous for (i.e., everybody considers it obvious except for me. B-)?
I am not sure, but the concept is simple. Basically node addresses will
also include a public key, so that any node which wishes to send a message
to a node must encrypt it using the public key. Right now a DH
key-exchange is used, which (while a super-clever piece of mathematics),
is vulnerable to "man in the middle" attacks. A PK mechanism should make
such an attack much more difficult (and - Scott, correct me if I am wrong
- should be faster than DH).
> IC> What if we define a new address type, called a "Shadow
> IC> Address", which looks like this:
>
> IC> stcp/x.x.x.x:yy/PUBKEYPUBKEY/CYPHERTEXTCYPHERTEXT
>
> IC> Where the cypertext is a node address (with some added random
> IC> salt to thwart traffic analysis) encrypted using the public
> IC> key. When a node wishes to send a message to a ShadowAddress
> IC> they must forward it to the node at x.x.x.x:yy which will
> IC> decrypt it and forward it to the decrypted address.
>
> So, if I understand the advantage of this, it's that outside nodes
> (yes, I can't help thinking of "inside" and "outside") will still be
> able to have unique addresses for "inside" nodes, but all requests
> will route through the "shield" node? Is that right?
Yes, but there doesn't have to be just one shield node, any given node
could make use of hundreds of shield nodes and select a different shield
node on a random basis.
> And all the shield node does is provide an address-rewriting service,
> kind of like a PGP mail anonymizer. In fact, maybe it wouldn't hurt to
> support shadow chaining....?
Yes, it is basically like a simple mail anonymizer. I would assume that
the implementation would allow recursive shadow-addresses, although I am
not sure of the advantage of this (since the only node that really matters
is the last one to route the request to the user).
> One thing I'm not sure of, though: what's the advantage of having lots
> of shadow addresses out there, if all messages still have to go
> through the "shield node"? I see that it's a different mechanism, but
> I'm not sure I understand the topological difference between shadow
> addresses and clusters.
Well, I just think that the shadow node idea achieves similar goals, but
in a much simpler way, where the implications are much more obvious than
with the cluster proposal, and where the benefits and risks are easily
apparent.
> Although it -does- kind of draw more attention to a shield node than a
> clustering system would (since no one would know that a gateway was
> actually a gateway, but a shield node's IP address goes out with every
> shadow address).
True, but it would be possible for a node to say that it didn't want to be
a shadow node if it felt that it would be at risk (the default should be
to permit shadowing though).
> However, shadow addresses still don't deal with "shy nodes."
Not sure what you mean here - can you explain?
Ian.
PGP signature