On 11/12/2013 04:16 AM, Michael Pearce wrote: > I just noticed... the AntiSpamHash should also include the sender's > identifier to avoid the sender using a nonce from a message already > sent to the recipient and avoiding calculating the AntiSpamHash.
That does seem like an improvement, but one worry I have with short-lived identities in general is that a spammer needs only to compute more hashes faster to spam more effectively. It's a balancing act between making identity establishment fast enough to be useful and involving enough social forces / slowness to impair spam. > On Tuesday, November 12, 2013 1:07 AM, Michael Pearce > <michaelgpearce at yahoo.com> wrote: > > Thanks for the response! All good information. Its fun to think > about how to build a system with the very specific constraints that > Freenet imposes. > > I'm not building a messaging application per se, but users will need > to communicate and most identities will not be very long-lived. This > is leading me towards thinking I can get away with a single key to > announce new messages. I was also thinking about adding a Nonce to > the message combined with an expensive hashing algorithm (i.e. > BCrypt) so spamming a user takes some work on the spammer's side. May I ask what you're building? It will be easier to give more informed and specific suggestions with that knowledge. > A sender would create a message similar to: > > Sender <- my public identifier > > Recipient <- recipient's public identifer Nonce <- unique value to > this recipient from the sender for this message > > SenderSignature <- sender signs message with (recipient, nonce) to > ensure sender is who he says he is AntiSpamHash <- Bcrypt(recipient, > nonce, minimum_rounds) to force some work on the sender > > MessageBodyId <- location of signed/encrypted message body located at > a different Freenet key > > As a receiver checking for incoming messages, he only fetches the > message body for messages that: > > * Have himself as the recipient > * Have a unique Nonce from the sender (no duplicates to avoid > signature / anti-spam value stealing) > * Correct signature at SenderSignature * Correct AntiSpamHash > > If all of these match, the receiver will then retrieve the message > body. > > I think the above scheme will allow for looking at the shared key > pretty quickly, and a computationally expensive AntiSpamHash will > disincentivize large amounts of spam. Definitely not perfect but it > may be good enough for my needs. This is between individual users? This sounds a lot like Freemail's use case. Perhaps you could base your protocol on that, or use Freemail as a transport? [0] Steve [0] https://github.com/Thynix/Freemail/blob/spec/docs/spec/spec.tex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20131116/653db801/attachment.pgp>
