On Mon, May 12, 2003 at 10:08:42PM +0200, Thomas Leske wrote:
> 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:
No, you can do it with KSKs, assuming that only the owner or people who
crack the hashcash/thinkcash puzzles are supposed to be able to read the
queue, which is reasonable.
KSK@<unique name>-<result of hashcash puzzle>-<result of thinkcash puzzle>
Hashcash puzzle would be something like:
"Run SHA-1 on the string "Zaphod Beeblebrox" 10,000 times, and use the
output as SHA-1".
Your random parameter is the string, this needs to be unique. Your
difficulty parameter is the number of hashes.
Thinkcash puzzle would be something like:
"CHK at blah...blah/image.png contains some obscured letters, a human should
be able to pick them out reasonably easily but a computer will have one hell
of a time... a computer can however GENERATE thinkcash puzzles" - this
is used by amongst others paypal and egold to prevent bulk automated
registrations, it can work.
You can vary the difficulty by using different obscuring algorithms or
whatever, but primarily it's a matter of varying the number of digits.
Thinkcash puzzles are fairly culturally specific - blind users would
need a voice recognition task, for example, and there are plenty of
other things that _could_ be used.
>
> 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.
See above. All he needs to do is publish a list of tuples:
{ string to hash, number of hash rounds, think-cash image }
And of course the basename. This can all be done on a freesite or via
some machine readable format.
>
> (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.
I would implement this side differently: my proposal would be that the
hash-think-cash scheme would only be for "introductions", and after that
we would use an outbox polling scheme. See the archives.
> 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.
No need for a new keytype, like I said above.
>
> 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
