Re: EvilDude, Round 2

> 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-gM/[email protected] 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 <[email protected]> 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-gM/[email protected] 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-S0/[email protected] <bo-le-S0/[email protected]> 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@something-1-2
> > > >    RedirectTargetURI=freenet:CHK@jdncdj,hdcbd,a8
> > > >    EndMessage
> > > >
> > > > Now the client app can decide how to handle it.
> > > >
> > > > thanks.
> > > >
> > > > --
> > > > Mfg
> > > > saces
> > >
> > > _______________________________________________
> > > Tech mailing list
> > > [email protected]
> > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech
> >
> > _______________________________________________
> > Tech mailing list
> > [email protected]
> > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech
>
> _______________________________________________
> Tech mailing list
> [email protected]
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech