On Wednesday 03 January 2007 21:32, bbackde at googlemail.com wrote: > > I'm not really sure what you mean by a 'global messaging feature'. > > I mean clients that rely on public keys, readable and writable be > everyone. Without private keys (like freemail) because you would have > to check the keys for each known user in this case. So each client > must know to what key it should write to if it inserts a new message, > and each client must know what keys to check to get new messages.
Sorry - I still don't understand. A key that's readable and writable to everyone - is that not a KSK? Dave > > On 1/3/07, Dave Baker <dbkr at freenetproject.org> wrote: > > On Wednesday 03 January 2007 19:42, bbackde at googlemail.com wrote: > > > What is wrong with the described advantages? > > > > > > Scenario: > > > > > > board_1 and board_2 exists. An attacker tries to spam them to make the > > > retrieval of messages nearly impossible. > > > > > > On board_1 he inserts 100 KSK keys with redirects to CHK keys that > > > were randomly created and point to no existing content. The insert > > > completes _very_ quickly. > > > > > > On board_2 he inserts 100 KSKs with random data behind it. The insert > > > takes a _much_ longer time to complete. > > > > > > Now a Frost client updates this board. > > > > > > On board_1 the client requests the 1st KSK. The node redirects > > > transparently to the CHK in the KSK redirect, and needs a _long_ time > > > until he gives up and reports code=28 to the client. The client does > > > not know if the request failed because the CHK does'nt exist at all, > > > or if the CHK could not be retrieved this time, but later. The client > > > steps over all 100 KSK keys (each one failing after a long search > > > time) and after this the client have to request all keys again during > > > next update, because some CHK might be retrievable now. > > > > > > On board_2 the client also requests the 1st KSK key. The node > > > redirects to the CHK key, and after a _shorter_ time the request is > > > successful or not. If it _is_ successful the client marks the slot > > > used (tried never again) and inspects the retrieved data, which are > > > random and therefore invalid. If the request was _not_ successful, the > > > client gets code=28, but this time he knows that the redirect points > > > to valid CHK key! So a retry will be successful later, and its worth > > > to retry. > > > > > > So why does the node even allow to insert a redirect to not-existing > > > data? He should check if the data is retrievable from the inserting > > > node. I can't understand why someone should insert a redirect to > > > content that cannot be retrieved by himself. > > > > > > I think an indication if the CHK is valid would be better than > > > without. Even with patched nodes, each insert node on the htl chain > > > could check if the CHK is known, and it is known if at least e.g. 2 > > > nodes (on the chain or neighbors) say it is valid. > > > > This would surely make the insertion of redirects quite considerably > > slower? It also means that the network could refuse to insert a redirect > > just because some node on the chain can't retrieve the data, for whatever > > reason. These would be my reasons for allowing insertion of arbitrary > > redirects, but I didn't write it! > > > > Come to think of it, surely only the data and the routing key is sent on > > an insert, so the destination nodes can't check the redirect because they > > can't decrypt the data because they don't have the public key. In fact, > > they can't even tell it's a redirect. > > > > > I don't know if my points are valid, but I want some explanations that > > > help me to understand this. A simple 'its not worth to think about', > > > without to provide a working circumvention for this, its not enough > > > for me. > > > > > > And why is there no type of key in 0.7 that is designed for > > > applications like Frost that provide a global messaging feature? There > > > are many improvements for freesites (e.g. USK) and easy filetransfer > > > (although to less detailed for clients, currently). > > > > I'm not really sure what you mean by a 'global messaging feature'. > > > > > > > > Dave > > > > > On 1/3/07, Dave Baker <dbkr at freenetproject.org> wrote: > > > > > 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 > > > > > > > > _______________________________________________ > > > > 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 > > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech
