On Sunday 18 Nov 2012 21:38:24 Matthew Toseland wrote: > 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).
One of the fundamental problems with using CAPTCHAs on Freenet is you get multiple attempts if you're a spammer - e.g. if you can identify some of the letters with an algorithm but not all of them, you just insert every possible solution for the missing letter. We can solve this by using two CAPTCHAs, one generates the key, the other is required in the solution. Other minor tweak: If you publish the solution you need to insert to it first - or we need to arrange the timing so that the CAPTCHAs aren't polled after X period and solutions are posted after Y, Y>X. Unfortunately this is the basic weakness in the scheme: It still allows for a cabal of active posters to exclude newbies. The regular posters can insert to their own CAPTCHAs, and thus DoS the mechanism. Combining CAPTCHAs from multiple posters to make one key doesn't solve the problem either, since as soon as the solution is posted everyone can insert to it, so it would get spammed. BETTER SCHEME: We could use SSKs (or PSKs) so everyone can poll the solution, but only by solving the CAPTCHA can you fetch it (e.g. we specify the pubkey and part of the seed the privkey was generated from; with PSKs it's a bit cleaner crypto-wise). This reduces the latency of announcement considerably, and even better it means the user doesn't (usually) get asked to solve CAPTCHAs that have already been posted. But we would need sufficient entropy for it not to be easily brute forced, which probably means 2 CAPTCHAs. Which could be from different identities to make it harder for them to block their own slots. We could use a third CAPTCHA, which is required in the solution but not part of the key, to prevent "get most of the letters and insert every possible version of the missing one". That would increase latency though, as we'd have to wait for the third solution before accepting the announcee. But we still retain the key property that we don't need to ask users to solve CAPTCHAs that other users have already solved (unless there is a collision / very tight timing problem). This sounds inconvenient at first, but solving 3 CAPTCHAs and getting them right, and getting announced, verifiably and quickly, is preferable to the current situation of solving 20 CAPTCHAs and them colliding and not being visible for days! We can have feedback on the first 2 CAPTCHAs because of the commit/reveal above, but the third one we don't know anything about... Plus, it's global (visible to everyone watching the forum), and context-specific (per forum, to avoid scaling issues). Possibly we could do even better with some sort of collaborative randum number generation (which would produce a different random secret for each active poster), which would prevent conspiracies to block slots (unless they are very large), or deliberately creating unusually hard CAPTCHAs. Ultimately CAPTCHAs suck; for example, OCRing some letters and trying the missing ones would allow us to get the key for the above. And they're inconvenient, although half the internet uses them. Scarce SSKs will help, but are probably not fast enough for all applications. > > > > 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
