On Wed, Oct 10, 2012 at 07:51:45PM +0100, Matthew Toseland wrote: > Sadao@JXXNvLaHdNMysx7GmY5~L4aCoMuQV85oJM9OIqhkTR8 wrote : > > > > Let's consider the Frost message system and see what exactly it lacks to > > be spam protected. Every board has one SSK key pair. The public key of > > the board is normally known by everyone and used to download the > > messages in the very efficient manner. The private key of the board is > > used to post the messages by anyone who knows it. The moderator of the > > board gives it to some persons on individual basis. If one of those > > trusted persons begins to spam the board, it's trivially to block him by > > changing the board SSK key pair (manually or automatically) and giving > > the new private key to the same set of trusted persons except the > > spammer. There is only one problem: how to determine who exactly is spammer? > > > > This problem can't be solved by means of SSK keys only. If two persons > > know a private SSK key and one of them is a spammer, it's impossible to > > determine which of them he is. Therefore I propose to implement a new > > freenet key type (personalized SSK key), which is based on SSK but has > > two additional features: > > > > 1. While the personalized key may be publicly known, it can be used for > > inserts only by the person who it was issued for. > > 2. When the data is downloaded from the personalized key, it must be > > possible to determine who was the inserter (more precisely, which of the > > issued personalized keys was used for the insert). > > > > That's how it should work. The moderator of the board generates a base > > SSK key pair. Then he generates a number of personalized keys (one for > > every user who can post to the board) derived from the base private SSK > > key and the public key of the user. He publishes the list of all > > personalized keys in some way. Every user uses his own personalized key > > to insert the messages, but all messages are going to the same place as > > if they would be inserted with the base SSK private key. I.e. in order > > to download messages, all users still use the single base SSK public key. > > > > Additionally, the moderator (or maybe everyone) can see which > > personalized key was used to insert every message. If he notices that > > someone begins to post spam and wants to block him, he simply generates > > a new base SSK key pair and new personalized keys for all users except > > the spammer. And the spammer can no longer post. > > > > As you can see, in order to have the board working, there is no need for > > the moderator to always be online. The moderator only adds and removes > > the users from the write list, but as soon as the user was added, he can > > read and post to the board even when the moderator is on vacation. Yes, > > there is still the problem of identity introduction, but it's not so > > important. And it has been already solved in some way in FMS, and I have > > another possible solution for it. But I don't think that it's time to > > talk about this particular problem now. > > > > P.S. I can describe the algorithm the node should use to deal with new > > key type in order to show that it's possible. But I have some > > unconfirmed assumptions on how SSK keys work in freenet now and I'd like > > toad (or someone else who knows) confirm them first: > > > > 1. The routing key for SSK inserts is always derived from the public SSK > > key (not from the private key). The private SSK key never leaves the > > local node and is used only to make some signature in order to prove > > that the inserter owns the private SSK key. > > Yes. The routing key is derived from the document name and the hash of the > public key. The private key is only known by the client, and only temporarily > by the client's node. > > > 2. When the SSK block is about to be stored in the datastore of the > > remote node, the remote node checks if the block has correct signature, > > i.e. the inserter indeed owns the private SSK key. Otherwise the SSK > > block is dropped. This way the network guarantees that only the key > > owner is allowed to insert the data to that key. > > Yes. > > > > Is this correct? > > Yes, looks like. > > You've got it, inspiration, woah! > > I apologise for spoiling what I'm sure you were going to trickle over a > longer period, but I think we should build the basic, generic tools ASAP. > Something similar was actually proposed *way back*, pre-0.5, but its > usefulness wasn't recognised at the time, probably because we didn't have the > immediate problem of chat tools. I should have seen it but haven't been > sufficiently immersed in cypherpunk... > > BASIC MODERATION: > > PSK: (basic personalised SSK) > - Public key A (moderator's key) > - Public key B (poster's key) > - A signature on key B by key A. > - A signature on the whole message including the keys by B. > > Routing: > PSK@<hash of A's public key>,<document crypto key>,<crypto > settings>/<document name> > > MULTIPLE MODERATORS: > > GPK: (general purpose SSK) > - Full group identity: The full group identity is a list of public keys. The > group identity is a hash over a group of public keys. > - Posting rule: Some function, written in a non-turing-complete language > (with cryptographic operations), to decide whether a message is allowed. > Limited runtime. Can only refer to the signing data and the group identity. > - Signing data which conforms to the posting rule, with a length limit. > - The payload data, with whatever encryption is appropriate. > > I'm not sure whether the payload data and signing data should be a single > entity. We don't want to allow operations so heavy that they constitute a CPU > DoS... > > The URI would incorporate all of the above: > PGK@<group identity hash>,<posting rule hash>,<crypto key>,<crypto > config>/<document name> > > This is very similar to how Bitcoin works. > > The main operations we would implement with the above: > - Posting to a board. The posting rule may vary depending on the board, but a > typical one would be "contains a pubkey signed by a moderator". > - Board maintenance. Changing the moderators list could have formal > cryptographic requirements (e.g. some specified majority). Since the posting > rule is part of the URI, we can simply poll the key that corresponds to the > "change group" posting rule. And since the posting rule is configurable, we > could have the same slot correspond to both changing the group and posting a > message. However, what the application does with the data should be up to the > application: Freenet should be able to return data from the posting rule, but > the application decides whether to e.g. poll a different key. > > The rules can be arbitrary, but the need to limit the amount of data > validated means we won't see e.g. fully democratic scalable mechanisms. > Basically what it gives you is efficient searching for content provided by > anyone within a group, provided they accept the rules of the group; > practically these will probably have to be hierarchical at least for now > (e.g. the need for an invite, or for an invite from somebody invited by a > top-level moderator, etc). > > The constraint that we can't refer to other keys is IMHO absolute for > performance and architecture reasons. Maybe we could have another key type > that allowed inter-key dependencies (e.g. with passing on the dependencies at > each hop to help validation), but there would need to be severe restrictions, > since *every hop needs to be able to verify the key, both on insert and > request*. Hence there would be fairly major load management implications too; > e.g. if the number of keys involved is predictable, we'd ask for more than > one from load management at each hop. So that's something for the future. And > yes it probably would enable various forms of digicash. > > For distributed search, this is usable as long as the group doesn't change > too often: You don't want to insert 10,000 keywords and then have to do it > all over again when the group changes. On the other hand if you increase the > size of the bundles you insert, you reduce the number of reinserts (which can > point to the same CHKs); there are useful tradeoffs. > > Also, the above mechanism can allow for quite a bit of scalability, e.g. > hierarchies of moderators. > > Finally, it combines neatly with multiple-return SSKs, although I'm not sure > how useful these are as they require all the results to have the same > location, meaning it becomes a bottleneck and censorship point - you > certainly don't want to use a single key for a video stream, for example!
Details on how to implement moderation: There is a small number of primary moderators. They are included in the posts. There is a larger number of secondary moderators. They have a signature from a primary moderator allowing them to introduce identities. A normal post includes an identity, signed by a secondary moderator. Newbies introduce (via hashcash or CAPTCHAs etc) to a secondary moderator. The moderator signs their certificate so they can post. When an identity starts posting spam, a moderator can post a control message adding it to a blacklist. If the blacklist gets too big, we need a new identity for the secondary moderator who introduced the spammers. The old identity can again be blacklisted, but if that gets too big as well, we need a new identity for the primary who introduced the secondary - and that means a new queue key. A single primary moderator may unilaterally change their key, thus redirecting to a new queue, where all the other identities are the same and theirs is changed. A single moderator of any kind can post to the blacklist. And so on. So there is no voting requirement for routine maintenance. When a secondary moderator gets a new key, all those who he's signed need new signatures. They keep their old identities though. The moderator will upload the new signatures for everyone (except the spammers they are removing). It is only necessary to sign keys for active posters signed by that moderator, so the number should be reasonably small.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
