On Thursday 28 August 2008 20:54, Jusa Saari wrote: > On Mon, 15 Aug 2005 19:10:18 +0100, Matthew Toseland wrote: > > > On Sat, Aug 13, 2005 at 11:04:35PM +0300, Jusa Saari wrote: > >> On Sat, 13 Aug 2005 10:13:19 +0100, Matthew Toseland wrote: > >> > >> > On Sat, Aug 13, 2005 at 10:23:44AM +0300, Jusa Saari wrote: > >> >> On Fri, 12 Aug 2005 22:23:31 +0100, Matthew Toseland wrote: > >> >> > >> >> > You would probably have to have it return only the most recent key. > >> >> > There > >> >> > >> >> That would leave us vulnerable to censorship, if the original author > >> >> decides (or is forced to) insert a new, censored version. It would > >> >> also limit the usability of updatable keys for things like message > >> >> boards and such - instead of getting a list of all the messages, you > >> >> get only the most recent (of course you could use it to store a list > >> >> of messages instead, but having to post the whole list every time you > >> >> post a message is a waste of both bandwith and storage space). > >> > > >> > And returning all of them makes us vulnerable to flooding. Which would > >> > not be correctible by the usual popularity mechanisms, because we > >> > always return all of them. > >> > >> We aren't returning all the files. We are simply returning a list of > >> versions and hashes, which can then be used to request individual > >> file(s). This doesn't count as requesting the key for the purposes of > >> datastore purging and obviously doesn't create the traffick sending all > >> those files to the requesting node would, whichever you meant by > >> flooding. > > > > Hmm. Not bad. Of course, there can still be a million different files > > under 1 TUK, which will use up space in stores and consume massive amounts > > of bandwidth. > > The former problem is no better or worse than someone inserting massive > amounts of junk under any other keytypes; the latter can be solved easily > by putting a limit to the number of keys returned (say, 10000) and adding > a "too many to list all" mark if there's more. > > >> Sure, you could still go and request each and every version, but that is > >> no different than requesting a large number of unrelated keys. > >> > >> >> My proposal prevents these issues by keeping the older keys available > >> >> too, for as long as there is requests for them. > >> >> > >> >> An additional note to my proposal, BTW: The system should expect, > >> >> since Freenet as a whole is nonsynchronous, that there will be two > >> >> files with same key and version number, but different contents (if, > >> >> for example, two people post on a Frost board simultaneously). To > >> >> cope with this, it might be neccessary to send back not only version > >> >> numbers, but CHK's (or some other hash of file contents) as well, to > >> >> allow differentiating between such files. > >> > > >> > Possibly. There was some discussion of this with SSKs. I'm half > >> > inclined to make SSKs (and especially TUKs) really small... > >> > >> Not neccessary a good idea, since the more redirection layers there is, > >> the longer it takes to get the actual data, the more work the network > >> has to do (larger overhead), and the more likely it is that one of the > >> keys in redirection chain can't be retrieved. > > > > Technically yes, but, TUKs should just be pointers. Then we don't need to > > return a list of insecure hashes; we can just return a list of keys. And > > CHK collisions generally are a good idea. > > Do CHK collisions actually happen ? Especially for updatable files, which > are likely to contain, say, the latest index page for a freesite (as > opposed to, say, graphics files used on said freesite) ? > > Besides, like I said, there should be a mechanism to tell two TUKs that > have been inserted at the same time apart from each other - otherwise you > are going to have very serious problems using this for things like message > boards and such. That, in turn, requires some kind of hash - unless, of > course, the returned list from an updatable key request really is just a > list of VSK-timestamp-CHK lines, in which case it could easily contain two > entries for the same VSK-timestamp value... > > However, if we do this, we'll run into "which version should be purged" > problem when datastore fills, since we can't know which CHK key the user > ended up requesting. If we store files directly under VSK keys, this > problem gets solved. > > Furthermore, if VSK's are just pointers, someone could fill up a popular > Frost board with a thousand pointers for nonexistent CHK's with very > little resource usage from the attackers part, causing an abhorrent amount > of requests that will travel the maximum HTL without any chance to > succeed. If the VSK's themselves contain the data, you can still fill up > Frost with junk, but requests for that junk will succeed in a normal > amount of hops, leading to much less total network resource usage. > > Sure, it will then require more bandwith to transfer all the junk, but > the effectiveness of that attack will depend on the work done by the > attacker (uploading junk files), and could be done just as easily with any > key type and message board implementation. > > So, basically, pointer-type VSK's would allow for very cheap and effective > attacks, as well as cause problems for datastore maintenance, whereas > data-carrying ones wouldn't. > > >> BTW, I couldn't find the discussion about TUKs from gmane, except from > >> an old discussion from 2003. I think my proposal is superior, since it > >> allows to maintain a list of editions, instead of always returning just > >> the latest edition. > > > > This is also why your proposal is vulnerable. > > If you're referring to the traffick generation trap you mentioned on top > of your post, I'd like to point out that a much more efficient way to > generate wastefull traffick would be to insert a large junk file, call it > "hot teen porn.avi" and post a link to a Frost board. > > There is no way to stop an attacker from generating extra traffick on the > network, because even if you pluck every possible technical hole, there's > always social engineering. > > >> And, of course, with such a list key, you could easily add support in > >> FProxy for more advanced feedback mechanism - the NIM is pretty > >> horrible, since it forces the poster to check slots manually (leading to > >> obvious spamming opportunities) and almost begs for some l33t h4x0r to > >> take over a slot containing, for example, a link to a site he happens to > >> disagree with. My proposal, on the other hand, would allow for easy and > >> secure feedback channel to be included in freesites (something like <a > >> href="/freenetcgi/feedback?destinationprivatekey=12345&encryptpublickey=3213"). > >> Then just add an option in FProxy gateway page to view your mailbox. > > > > Any sort of public feedback system has major vulnerabilities. There are > > many ways to address this but most of them (hash cash, think cash, etc) > > need to be done at the client level... > > None of which has anything to do with NIM being pretty horrible, and my > proposal allowing for a much better mechanism being incorporated into > FProxy (which _is_ a client, and the only one each user of Freenet is > guaranteed to have).
Your mechanism does not solve the fundamental, basic spam problems that a web of trust based chat system does solve. And for FMS, or for saces' java based FMS port, which hopefully will eventually be web interfaced and embeddable in freesites, what we need is a highly efficient way to poll output queues. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20080829/aefcaadb/attachment.pgp>
