Ian Clarke: > Certainly, by removing a lot of the crypto in Freenet, you could probably come > up with a system that is faster,
Crypto is cheap. It's not Fred's bottleneck by a long shot. The only legitimate slowdown is the latency of a PKI key agreement, which requires a few packets back and forth. That's like 200ms. (This brings to mind one of my plans - to figure out how to prioritize certain packets in the linux networking subsystem. Is there a userland solution? An in-kernel solution? Anyone?) > You can't have it both ways. If you get rid of the crypto, you lose the > anonymity. You lose _some_ anonymity - specifically, some packet sniffing attacks now work. For instance, here's one I like: The attacker watches all the storedata messages replying through your node. If one of those messages is not forwarded, he knows you requested it. Encrypting the links prevents our packet sniffing attacker from identifying specific messages. Now you're probably thinking: yeah, but even if he can't find out what you requested, he still knows that you requested something. More bytes went in than out! And what if he can identify the file you requested by its size? FNP 0.4 pads files to the next power of two to avoid that. Designing a system that's vulnerable to packet sniffing is reasonable - even tentacle monster organizations like the MPAA will probably never have unfettered access to ISPs - and the relatively small overhead of crypto or file padding may not be worthwhile for many people. Document encryption is useless, by the way. > What if that node goes down? What if its connection is slow? What if its > data is so popular that the node goes down? What if the data is available > from multiple nodes? You should stick to Freenet's caching algorithms, they > are essential to Freenet's scalability and robustness. If you don't care > about those, then you shouldn't try to claim that your architecture is based > on Freenet, since you will be throwing out most of what is valuable about the > Freenet architecture. He's actually planning to use probabilistic caching. I suspect that it won't nearly be aggressive enough. _______________________________________________ freenet-tech mailing list [EMAIL PROTECTED] http://lists.freenetproject.org/mailman/listinfo/tech
