> Sorry - I still don't understand. A key that's readable and writable to > everyone - is that not a KSK?
Yes, thats KSK. But you see the problems we have with the 'new' KSK keys which are 1KB in size and provide transparent redirects to other keys? KSKs on 0.5 were great for Frosts messaging (32KB size, no transparent redirects), but the 'new' KSKs introduced the problems we talk about here (new kind of attacks, ...). The devs tried to make it easier for clients, but now some clients have serious problems. It could help to introduce a new type of freenet key, like KSK but without redirects and 32KB maximum size (like CHK). This would be perfect for Frost like clients. On 1/4/07, Dave Baker <dbkr at freenetproject.org> wrote: > 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 > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech >
