On Sunday 18 Nov 2012 21:34:03 Matthew Toseland wrote: > On Sunday 18 Nov 2012 20:57:39 Matthew Toseland wrote: > > p0s asked me to post some details on this. > > > > GROUND RULES: > > > > 1. Everything is specific to a single forum, on the theory that the number > > of active users on a forum is likely to be limited. > > > > 2. We are only concerned with demonstrable DoS attacks here. Trolling and > > "slow" attacks can be dealt with either by the user, or by using WoT, which > > is otherwise unnecessary with this architecture. In other words, it doesn't > > solve all spam problems, and it's not intended to. Ultimately it relies on > > some sort of non-trivial announcement system, as does WoT. > > > > DETAILS: > > > > Identities announce to the forum via some globally visible mechanism: > > Scarce SSKs, hashcash or similar. We might approximate this with CAPTCHAs > > where the solutions are published after a fixed period. > > We can use a cryptographic commitment protocol, and random sampling, to > ensure honesty here: > Active posters to a board publish a set of CAPTCHAs in their daily update: > * Context (board) to be announced into > * Base of the key to insert to. (E.g. KSK@<long string>; we append the > solution to the CAPTCHA to this key before inserting) > * CHK of the content of the CAPTCHA - or include it in the update if it's > small > * Algorithm used to generate the CAPTCHA (there should be a registry) > * E ( IV + RNG seed + solution + H ( RNG seed + solution ) ) (or similar > using HMAC or authenticated cipher) > The RNG seed here is that used to generate the CAPTCHA, apart from the > solution, which is the letters themselves, the output of the puzzle which is > part of the key to be fetched. > The next day, we publish the keys to decrypt the last set of CAPTCHAs. > Everyone watching the board downloads the solutions to see if anyone has > announced. > And they check that the solution and RNG seed produce exactly the data > published as the CAPTCHAs (automatically!). > > This provides strong protection against censorship/spam trust cabals. > Announcees are globally visible after a short delay. There is no incentive to > not publish CAPTCHAs, and in fact we can make it mandatory; you don't have to > accept the newbies, nor even fetch the keys. It can't be brute-forced; > there's no hashcash. And it doesn't even require a new key type, or > verification of CAPTCHAs. > > We can improve latency by including CAPTCHAs, when appropriate, on our posts, > rather than waiting until the next day's WoT update. We are posting anyway, > so we're not giving away any more information apart from having seen the > solutions (an arbitrary timing threshold may be needed). However in this case > the poster will have to poll for solutions, even if he doesn't want to see > the newbies, so he can publish new puzzles when needed.
To clarify: If you publish CAPTCHAs (which may be required), you are required to publish the solutions within a certain time period (if you post in that time period, otherwise when you post next), or within a certain number of posts. If we're making it part of the WoT daily update, then we just expect the next update to include the solutions (as well as new CAPTCHAs). > > The only problem with this is it relies on CAPTCHAs being not cheaply solved. > Unfortunately this is already false, and it's worse on Freenet since we get > multiple attempts (if we can't make out one letter we can insert all possible > variants cheaply enough). Long term we need something else, IMHO that's > either hashcash (which is very doubtful), bitcoin (again very doubtful), or > Scarce SSKs (to be developed). But short term we could implement the above > into any WoT-based system to announce newbies quickly in a context (e.g. a > board) without having to poll large numbers of identities.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
