The concept is based on a new key type, because there seems to be no way
to accomplish this with the ones available. The key index (which can be
used as an inbox for mail) has the the following features:
1) The key index can be read the same way as a KSK-based index. Anybody can
insert messages into free slots without previous negotiation, but he has
to calculate a hash cash to do so.
2) The index has an owner. He signs price tags with his private key. A price
tag fixes the price (in hash cash) an inserter has to pay for using a slot
depending on the slot number:
AmountOfHashCash = e^((slotNumber - a) / b)
(The price tag contains the numbers a and b.)
Therefore higher slot numbers are exponentially more expensive to use.
(Special care must be taken, so that the content of cheap slots
can not be replaced easily: The last node in an insert chain starts a
new data request for the key. The insert can only take place, if the
data is not found.)
The owner of the index will regularly publish new price tags
with reduced prices, as the slots are filled. If there is too much noise
or spam, then he will let the price increment with every slot filled.
If someone wants do perform an denial of service attack against the index
and fills quite a few slots, then he can never be sure though that no
legitimate user is able to calculate the hash cash for the next slot.
On the other hand, if there is too little traffic, then the owner of
the index will reduce the price.
(The slots of the key index are just numbered successively. They do not
include a date. So the owner of the key index should publish
the first free slot number regularly. From what I have seen in the
README, Freemail does that already.)
3) If the owner of the key index trusts an other identity,
he can send him a rebate ticket that disburdens him from part of
the hash cash calculation. The ticket increases the value a in the
price tags. One would send such a ticket with every mail so that the
recipient can reply easily.
Tickets have a special note on them, that they are only valid for
content signed by the trusted identity, so that they do not have to be
kept secret.
Rebate tickets expire at a certain slot number in order to limit the
impact of abuse. Alternatively the ticket may specify that it can
only be used once. (The last node in the insert chain for the slot
tries to insert a certain chunk of data as a CHK that is determined
by the ticket. If there is a key collision, then the insert will
be aborted. The ticket has to be kept secret until used in an insert.)
4) possible extension: The trusted identity in a ticket can pass his
privileges on to other identities.
Let us call the new key type HCKs (for Hash Cash based Keys).
HCKs contain the following data (readable by nodes):
slot number, public key, signed price tag,
[signed ticket, public key of the trusted identity, signature for the
content, ]
encrypted content, hash cash.
The items in brakets [] are optional.
Nodes verify the slot number and the public key from the search key of the slot.
The hash cash is a fixed number of bits and can be verified as follows:
First the node calculates the AmountOfHashCash (see above). Then the
hash of
the slot number,
the encrypted content and
the hash cash
modulo AmountOfHashCash must be zero.
--
Thomas Leske
_______________________________________________
devl mailing list
devl at freenetproject.org
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
