> If a client could determine that the inserted KSK was inserted > as redirect to a specific key,
That's the problem though - I don't think that's possible. Even if it were marked somehow on insertion, it would only require some minor hackery of the node's source to make a user-created redirect look like a node-created redirect. Again though, I'm still not convinced it's worth worrying about. Dave On Wednesday 03 January 2007 17:05, bbackde at googlemail.com wrote: > It would help to prevent the usage of specific keys that were inserted > as a redirect target of a KSK. If a client could determine that the > inserted KSK was inserted as redirect to a specific key, we could > easily drop and ignore this KSK. We would only allow KSKs that were > inserted as data. This prevents attackers from inserting alot of KSK > redirects (which is very fast, compared to the insert of a KSK with > the data) in a short time, and it prevents spreading of specific CHK > keys over KSKs. > So I see some advantages there. It should'nt not too hard IF the node > knows when a KSK was inserted as redirect to a specific CHK. If not I > think we will have some more problems with KSK attacks than under 0.5. > On 0.5 this kind of attack is not possible such easily... > > On 1/3/07, Dave Baker <dbkr at freenetproject.org> wrote: > > I don't really see as that's relevant, since it would be spoofable > > anyway. Surely the point is setting a limit on the size of a key when > > it's requested (frosy must do this, surely..?) and limiting the number of > > redirects (which the ClientGet command doesn't seem to have an option > > for, but I assume the node has a sensible limit and detects redirect > > loops). > > > > This would prevent the second attack. I don't really see that the first > > is a problem anyway, since the risk of downloading arbitrary content is > > implicit when using frost. You could potentially only allow keys that are > > non-redirect KSKs (thus limiting the size of a frost post to 1k, which > > may or may not be desirable). That would prevent it, but as I say, I > > don't really see it as a problem assuming that there's a filesize limit. > > > > > > Dave > > > > On Wednesday 03 January 2007 14:19, bbackde at googlemail.com wrote: > > > I think he means that a client should be able to determine if a > > > KSK/SSK was inserted as a manual redirect to another key, or if the > > > KSK/SSK was inserted with data and a redirect to the content was > > > automatically created by the node. > > > > > > Is it possible to separate this in the node? This would be a great and > > > simple solution. > > > > > > On 1/2/07, bo-le at web.de <bo-le at web.de> wrote: > > > > hi, > > > > > > > > just in the frost-board 'frost' > > > > ----- EvilDude ----- 2007.01.02 - 07:22:29GMT ----- > > > > > > > > If I wanted to download a key but it was rare, could I increase my > > > > chances of getting it if I inserted a KSK redirecting to it, forcing > > > > every frost user to download that file? > > > > > > > > Similarly, could I create a denial of service attack by inserting a > > > > bunch of redirects to all the large files I can find? I'm not going > > > > to attempt it this time around, I'm just wondering. > > > > > > > > ----- > > > > > > > > The fcp client should be able to detect the redirects if wanted. > > > > > > > > My suggestion: a new progress, that show the redirects. > > > > > > > > static final int showRedirects = 128; > > > > > > > > verbose=verbose | showRedirects > > > > > > > > > > > > Now the ClientGet returns a new progress message > > > > > > > > FollowingRedirect > > > > Identifier=hello > > > > RequestedURI=freenet:KSK at something-1-2 > > > > RedirectTargetURI=freenet:CHK at jdncdj,hdcbd,a8 > > > > EndMessage > > > > > > > > Now the client app can decide how to handle it. > > > > > > > > thanks. > > > > > > > > -- > > > > Mfg > > > > saces > > > > > > _______________________________________________ > > > Tech mailing list > > > Tech at freenetproject.org > > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > > > _______________________________________________ > > Tech mailing list > > Tech at freenetproject.org > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech
