On 6/20/06, Colin Davis <Colin at sq7.org> wrote: > Hrmm... > Perhaps I am under a mistaken impression of how easy a KSK page is to > forge? I recall under .5, it was rather do-able. > > Even if they aren't forge-able (while I'll take your word for), > aren't they still floodable?
Floodable? > -Colin > > > On Jun 20, 2006, at 3:35 AM, freenetwork at web.de wrote: > > >> The difference is, if it worked properly, it would allow you to give > >> a "Short name" on a business card/Note to conspirators. > >> > >> Example: > >> > >> John Doe > >> VOIP: 555-555-1212 > >> e-mail: JohnDoe at hushmail.com > >> Freenet URL: Alice\MySecretPage\ > > > > What about this? > > > > John Doe > > VOIP: 555-555-1212 > > e-mail: JohnDoe at hushmail.com > > Freenet URL: KSK at MySecretPage > > > > Where the KSK is just a meta-redirect to an USK at blafasel/-1/ > > freesite. Done and I'm sure nobody I don't even know messes with > > the index. > > > > Maybe KSKs are not *that* secure as SSK/USK are, but neither the > > index is. > > Whereas KSKs can only by compromized by a network split or bad > > routing (and having to know the KSK-key in forehand to insert bogus > > data to), the index can be manipulated *at will* as it's under the > > control of a single person/org, that can be forced by The Guys to > > tamper the index. > > As 0.7 doesn't have a HTL-field anymore, modifying KSKs is even > > more difficult. On an insert collision, the valid KSK is returned > > along all the request chain, which distributes the original key > > even more (if it goes into the datastore). The chain is now longer > > as with 0.5, > > and with 0.5 the attacker could set a HTL of 2 or 3, which > > "infects" nearby nodes without collision. > > > > > > > > > >> On Jun 19, 2006, at 10:36 PM, Matthew Toseland wrote: > >> > >>> This seems increasingly similar to searching ... isn't DNS just > >>> another > >>> search/labelling system? Certainly splitting up indexes by letters, > >>> and > >>> even inheriting stuff from other indexes, is very close > >>> technically to > >>> the mechanisms we will have to provide for searches. > >>> > >>> Why not just use searches? I ran into just this debate in a bug on > >>> mozilla once; the consensus seemed to be that people shouldn't be > >>> guessing URLs, they should just use Google; hence the addition of > >>> the > >>> Google Bar to firefox. > >>> > >>> On Sun, Jun 18, 2006 at 06:09:56AM -0400, Colin Davis wrote: > >>>>> > >>>>> I like the idea. I had been pondering something very similar for > >>>>> Freemail to > >>>>> combat the problem that I can't give my Freemail address to > >>>>> someone > >>>>> in the > >>>>> pub. Aside from a business card almost as large as the table > >>>>> itself, it would > >>>>> also require a lot of patience from the poor person that's got to > >>>>> type it in. > >>>>> > >>>> > >>>> Absolutely. There's a lot of uses for a system like this- Unlike a > >>>> KSK, it's signed & distributed, so it's under your control, but > >>>> it's > >>>> still available for everyone. > >>>> Since anyone can publish a name page, it's democratic. > >>>> > >>>>>> * Allow Bob to subscribe to Alice's page, and include it as part > >>>>>> of his. > >>>>> > >>>>> The problem being that a tree structure like this can make the > >>>>> lookup time > >>>>> very large very fast, since it can very quickly have a lot of > >>>>> indexes to > >>>>> check, each of which is not that quick. > >>>> > >>>> > >>>> That's true, but keep in mind- You can copy their entries to a > >>>> static > >>>> list, once you access them. Ie, use cron to have FCP access their > >>>> lists once per 12 hours, and copy them to your own list. Then it's > >>>> essentially a giant hosts.txt file.. > >>>> > >>>> For example- > >>>> > >>>> Alice publishes the following list. > >>>> Greatsite -> USK at SDFSDFSDFSDFSDFSD > >>>> ReallyGreatSite -> USK at XCVXCVXCVXVXCV > >>>> GreatPic.jpg -> CHK at SDFSDFSDVXCSDFZXF > >>>> > >>>> > >>>> Bob creates his own list: > >>>> BobIsCool -> USK at CVBNCVBCVBCVBCV > >>>> Bob'sSuperFriend -> USK at SDFGCBVXCVHNFDGND > >>>> > >>>> > >>>> > >>>> Bob then subscribes to Alice's list. > >>>> His client Creates a new master list, which looks like- > >>>> > >>>> Bob/BobIsCool -> USK at CVBNCVBCVBCVBCV > >>>> Bob/Bob'sSuperFriend -> USK at SDFGCBVXCVHNFDGND > >>>> Alice/Greatsite -> USK at SDFSDFSDFSDFSDFSD > >>>> Alice/ReallyGreatSite -> USK at XCVXCVXCVXVXCV > >>>> Alice/GreatPic.jpg -> CHK at SDFSDFSDVXCSDFZXF > >>>> > >>>> > >>>> At that point, going to a URL is just a matter of looking up the > >>>> name > >>>> in a flatfile. Yes, it could be broken up/arranged in a Database, > >>>> etc.. But conceptually, think of it as one file that is added to. > >>>> > >>>> If Chris publishes a list > >>>> UBERSITE -> USK at SDFHBYFGDJNHSTNHWR > >>>> > >>>> > >>>> And he subscribes to Alice, he'd then have hers and his, but not > >>>> Bob's. > >>>> If he subscribed to Bob's, he'd have him, Bob, and Alice. > >>>> > >>>> Etc. > >>>> > >>>> > >>>>> One problem I can see is that if I give one of mates one of these > >>>>> URLs, will > >>>>> he then get very confused when his node tells him it doesn't know > >>>>> about it, > >>>>> since he doesn't subscribe to the right names list? > >>>> > >>>> While that's true, as-written it works well in a darknet- Your > >>>> friends can add your list ;) > >>>> In a wider opennet, you'd probably have someone like Yahoo > >>>> publishing > >>>> a master list, which most people subscribed to, either directly, or > >>>> through someone who subscribed to it. > >>>> > >>>> > >>>>> That can be solved by > >>>>> just having a default one that will suffice for 99% of people > >>>>> though, and > >>>>> potentially build in some kind of revocation mechanism. > >>>>> > >>>> IIRC, there is already a revocation method- > >>>> If you change a key to be blank, the next time people sync against > >>>> it, the key is removed from your list. > >>>>> > >>>>> I'm just throwing some ideas around really, use whatever you > >>>>> will. :) Either > >>>>> way, I do like the idea. > >>>>> > >>>>> > >>>>> Dave > >>>>> > >>>>> > >>>>>> > >>>>>> I think this is a much better idea. > >>>>>> > >>>>>> The idea, as I understand it, lets a user set up a USK page, to > >>>>>> which > >>>>>> he posts a list of freenet links. This is somewhat similar to the > >>>>>> multitude of Freenet indexes that already exist ;) > >>>>>> > >>>>>> In this USK page, A user could specify "Friendly Names", > >>>>>> similar to > >>>>>> DNS, or a KSK. > >>>>>> > >>>>>> InterestingSite -> USK at BlahBlahBlah > >>>>>> GreatPic -> CHK at blahBlahBlah > >>>>>> > >>>>>> > >>>>>> A user can then "Subscribe" to another users name's list- So for > >>>>>> example, if Alice published this page, I could subscribe to his > >>>>>> pages, and access any of her links, via her username, and the > >>>>>> short > >>>>>> name he gave it- > >>>>>> For example- Alice/InterestingSite > >>>>>> > >>>>>> If Bob were to do the same thing, I could access Bob/ > >>>>>> SuperCoolSite, > >>>>>> which would link me to things that he thinks are interesting. > >>>>>> > >>>>>> > >>>>>> > >>>>>> You, as a user, can subscribe to as many of these indexes as you > >>>>>> want, by telling your client to know about both USK index pages. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> The most interesting part is yet to be written. I'm still > >>>>>> talking to > >>>>>> Aum about how best to do it, but I'd welcome suggestions. > >>>>>> > >>>>>> * Allow Bob to subscribe to Alice's page, and include it as part > >>>>>> of his. > >>>>>> > >>>>>> > >>>>>> What this does is allow a web-of-trust for DNS. Bob trusts > >>>>>> Alice's > >>>>>> pages, so he tells the client to automatically copy them into his > >>>>>> list, under her name. > >>>>>> That means that by subscribing to JUST BOB, I can access BOTH > >>>>>> Bob/ > >>>>>> SuperCoolSite, AND Alice/InterestingSite > >>>>>> > >>>>>> > >>>>>> That means that you could subscribe to as many DNS providers > >>>>>> as you > >>>>>> choose, and they all publish their lists to a global datastore. > >>>>>> > >>>>>> This isn't easily implementable under the general internet, > >>>>>> because > >>>>>> it doesn't have a global datastore.. It's a freenet unique > >>>>>> solution, > >>>>>> and the idea is fascinating to me. > >>>>>> > >>>>>> > >>>>>> This is a VERY exciting idea, and I'd love to see it implemented > >>>>>> more > >>>>>> globally. Discussion appreciated. > >>>>>> > >>>>>> http://freenet.org.nz/pyfcp/fcpnames.1.html > >>>>>> _______________________________________________ > >>>>>> Devl mailing list > >>>>>> Devl at freenetproject.org > >>>>>> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > >>>>>> > >>>>> _______________________________________________ > >>>>> Devl mailing list > >>>>> Devl at freenetproject.org > >>>>> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > >>>> > >>>> _______________________________________________ > >>>> Devl mailing list > >>>> Devl at freenetproject.org > >>>> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > >>>> > >>> > >>> -- > >>> Matthew J Toseland - toad at amphibian.dyndns.org > >>> Freenet Project Official Codemonkey - http://freenetproject.org/ > >>> ICTHUS - Nothing is impossible. Our Boss says so. > >>> _______________________________________________ > >>> Devl mailing list > >>> Devl at freenetproject.org > >>> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > >> > >> _______________________________________________ > >> Devl mailing list > >> Devl at freenetproject.org > >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > > > > > _______________________________________________ > > Devl mailing list > > Devl at freenetproject.org > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >
