On Mon, Apr 16, 2001 at 08:25:18PM +0000, Adrian Lopez wrote:
> It seems like various people here would rather do away with KSKs. I'd
> like these people to address how data submission might be dealt with in
> lieu of public keyspace. How would in-freenet key indices work without
> KSKs? How would things like EOF be implemented if users aren't able to
> submit data under public keys bearing a particular prefix?
(I'm assuming I have the permission of the Freenet Government to discuss
this subject. If not, please say so and I'll have myself executed
immediately.)
The problem with KSKs is not that they're publicly writable, but that
they appear to provide a one-to-one mapping from a string to a document.
In fact they don't, because they can be changed by anyone to point to
any document. The fact that the string is readable just makes the problem
worse, because it will encourage users to create KSK redirects for
everything.
But you don't need KSKs for many-to-one communication. What you need is a
list that any user can add elements to, but only one user can remove
elements from. (It doesn't matter who can read the list, because items
added to the list can be encrypted with the owner's public key.)
The list has a public/private key pair. To start the list, the owner
generates a random number (the seed), signs it with the list's private
key, and inserts it under the list's public key. The seed is not cached by
any node except the node where the request dies. (I'm not sure how "dies"
should be defined - at the moment it would mean "runs out of HTL".) The
node that's holding the request when it dies verifies the signature,
caches the seed, and becomes the host of the list.
To append an item to the list, you insert the (unsigned) item under the
list's public key. The item is not cached by any node that doesn't have a
copy of the seed (and the only node that has the seed is the one where the
insert request died). If a node has a copy of the seed, it appends your
item to the list.
To retrieve the list, the owner requests the list's public key. The data
reply contains all the items submitted under the public key. It is not
cached, because that would create out-of-date copies of the list (the list
may be requested by more than one person in the case of a mailing list or
newsgroup, and all requests must travel to the host).
To clear the list, the owner inserts a new seed, signed with the list's
private key, under the list's public key. When the new seed reaches a node
with a copy of the old seed (the host), the signature is verified and if
it checks out, the list is cleared. For a normal fmail address, you would
clear the list after requesting it. For a mailing list, you might clear
the list daily, and replace the day's items with the CHK of a daily
digest, to reduce the load on the host. (Likewise daily digests could be
replaced with monthly digests at the end of the month.)
Redundancy:
Obviously there's no guarantee that the list the reader receives is
complete - malicious nodes can drop items during the insert (before they
reach the host), or during the request (before they reach the reader). Or
the host itself could be malicious. To combat this, the list owner
maintains two or more redundant lists with different key pairs. The public
keys of the lists are stored in an SVK. The owner's fmail address is the
public key of the SVK. The sender's fmail software retrieves the SVK,
inserts the message (encrypted with the recevier's fmail address) under a
CHK, and appends the CHK to each of the lists mentioned in the SVK. The
receiver's fmail software retrieves and merges the lists, sifts out the
obvious spam (see below), and downloads the message bodies.
There's only a small amount of redundant traffic (short messages that
don't have to be verified or cached), and only one copy of the message
body is inserted. In the case of a mailing list or newsgroup, message
bodies benefit from caching and it's only the lists of CHKs that have to
be retrieved directly from the host(s) each time.
Spamproofing:
All items in the list must be signed with the owner's public key (fmail
address) or they will be discarded by the receiver. (Provides lightweight
protection against spamming - people must know your address to spam you,
they can't just add messages to every list passing through their node.)
But this won't work for mailing lists (unless you want to tell all the
subscribers the owner's private key so they can verify the signatures).
For private mailing lists, the list can be collected and cleared
periodically by a bot, and items that were signed by a subscriber can be
forwarded to all subscribers - subscribers do not collect the list
directly, although they collect the message bodies directly. Moderated
public lists would work in a similar way, with the moderator forwarding
approved posts to the subscribers.
Each item in the list should therefore contain three fields:
(1) CHK of the message body
(2) Signature of (1) with sender's private key
(3) Signature of (1) and (2) with receiver's public key
Michael
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/devl
