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.
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.? 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. On Sunday, November 10, 2013 2:38 PM, Steve Dougherty <steve at asksteved.com> wrote: On 11/10/2013 12:45 AM, Michael Pearce wrote: > Hi Steve. > > I'm using Ruby and the library for Ruby is... well... a little out of > date.? There were a couple of quick changes to make (syntax for Ruby > 1.9 and library changes), but i was having a hard time getting things > to work with making a blocking request...? Since i really want to do > just a few simple things, i'll most likely roll my own library and > publish as a Ruby Gem. Alright, sounds good. > I did have another question: How do applications such as a "chat" > work?? The only way that I could think of is to have multiple clients > sharing the same SSK private key, publish to a USK to write a new > message, then read all versions of with the public key to see what > others have written.? Is this even close? That could work, but it would be problematic. With this kind of approach one malicious person can spam messages to that single key so that no one can reliably send messages. The problem to solve here is finding other identities to fetch messages from. My understanding is that FMS and FLIP (examples of forums and chat respectively) have a shared key for announcing identities, and after that each identity inserts messages to their own private SSK. Individuals can then be ignored at will, and all a malicious individual can do - at least at a key level - is overwhelm the announcement mechanism. This is often coupled with a trust/scoring system where in addition to publishing messages, identities publish a trust list, and give bad scores to spammers or those who abuse their trust list. If you want to do something like this, you could roll your own identity announcement, or make use of an established system like Web of Trust (WoT) or Less Crappy Web of Trust (LCWoT). [0][1] WoT provides identity creation and announcement. Unlike FMS and FLIP, it does not use a shared announcement key. Instead it ships with a list of trusted "seed identities" that already run the software, and add at neutral trust those who solve CAPTCHAs they publish. LCWoT was written due to frustration with WoT's performance and stability, and only supports established identities. -Steve [0] https://github.com/freenet/plugin-WoT-staging/ [1] https://github.com/tmarkus/LessCrappyWebOfTrust _______________________________________________ Tech mailing list Tech at freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech _______________________________________________ Tech mailing list Tech at freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20131112/034ccbdf/attachment.html>
