tor-access October 2016

tor-access@lists.torproject.org

6 participants
5 discussions

Specification for bypassing CAPTCHAs using blinded tokens
by Alex Davidson 31 Dec '16

31 Dec '16

Hi everyone, I've been interning at Cloudflare for the past 3 months and have been working on developing an implementation of the blinded tokens spec that George and Filippo developed a while back. We've updated aspects of the original spec, the newest spec can now be viewed here: https://github.com/cloudflare/challenge-bypass-specification. We're happy to hear comments from any of you on the design and on the capacity of the solution for preserving anonymity. We've managed to build a test copy of the protocol along with an extension that carries out the required operations. The extension is not completely finished yet, but we're looking towards making that open source as well when it is done. Thanks, Alex

5 20

CloudFlare CAPTCHA Timeout Loop
by teor 11 Oct '16

11 Oct '16

Hi, I'm not sure if this is the best place for CloudFlare-specific bug reports. (I'm happy to direct it to the appropriate channel.) If I have Tor Browser open in High Security level (no JavaScript), and I open a page with a CloudFlare CAPTCHA, and wait a minute or so before answering the CAPTCHA, I see the following message: "Sorry, something went wrong. Please try reloading the page." This error message is also wrong: in order to get the link to work, I need to copy the link, close the tab, and open a new tab with the same link. Using the same tab and hitting reload results in a form resubmission dialog. If the form data is resubmitted, I get the same message, if I say Cancel, I get a blank page. I can imagine this being really frustrating for people who open tabs in the background, and for those whose cognitive or motor functions are slower than expected by the underlying code. (And those who don't understand the workaround of opening the same link in a new tab.) Any chance of getting this fixed as a matter of priority? Tim -- Tim Wilson-Brown twilsonb at mac dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------------ T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------------

2 1

Re: [tor-access] Specification for bypassing CAPTCHAs using blinded tokens
by Alex Davidson 06 Oct '16

06 Oct '16

>PSS is completely incompatible with blind signatures because the signer >must provide randomness. You could maybe fix this with some sort of cut >& choose or zero knowledge scheme for choosing the randomness, but.. > >All the security proofs for RSA blind signatures just replace PSS with >FDH anyways. In fact, CloudFlare might not need a FDH for verification >because hash factoring attacks sound implausible, but worse.. Yeah this is a mistake in the specification - thanks for pointing it out. We planned to use a FDH hash for this operation. >There is nothing about how the blinding factors get chosen! > >There are absolutely brutal deanonymization attack on blind signatures >where the blinding factor is not created using a full domain PRNG, >probably your FDH for the signature. In this case, I really mean full >domain where you (1) generate a random 2048 bit number, (2) test that >it's less than the RSA modulus n, and (3) throw it away and start again >if it is not. On average, this requires generating two 2048 bit numbers >because n should lie half way between 2^2047 and 2^2048, but obviously a >malicious exchange could pick a small n to make the clients do a bit >more work. I agree that the blinding factors should be chosen carefully and this is something that is currently being built into the extension we're developing. I'll add this explicitly to the document as well as it is an important consideration. Regarding the possibility of a malicious edge using a small modulus n. Given that there will only be one public signing key available at any time and since this will be publicly available (and checked by the clients using the CT log) it will be difficult to get away with this without clients realising. >There are more issues with blind Schnorr signatures, but they look >susceptible to this attack too. The blind BLS signature scheme somes >with different concerns : Thanks for the update on the security of BLS signatures. I haven't thought about these too much and they were added to the spec more as just an afterthought in case we wanted to explore an alternative to RSA. I had a conversation with Filippo a while ago and he mentioned that Tanja thought that going with RSA for now was probably the best idea due to the relative simplicity of the scheme. I'm open to re-engaging in the conversation however and if there are genuine attacks on this scheme then we'd have to consider something else.

2 1

deanonymizaton attacks
by Jeff Burdges 05 Oct '16

05 Oct '16

I've sent a bunch of emails to the tor-access list rather quickly, but just to reiterate the most important part : There are two very serious deanonymizaton attacks in the spec as written so far. First, if one does not use a blinding factor indistinguishable from random that ranges over precisely the domain Z mod n, then you leak 1 bit per token to the mint. Second, if one does not check the GCD of both the hash and the blinding factor* with the RSA modulus n, then one potentially leaks even more bits vs a malicious RSA key made from two bigish primes and several smaller primes. In both case, any leaked bits accumulate as you spend multiple tokens, or via an intersection attack, which quickly deanonymizes users. If one checks out GNUNet's svn repository, then one could find my commits that address these attacks in Taler by running : svn log gnunet/src/util/crypto_rsa.c | less Just wanted to reiterate this to it didn't get buried in all the minor concerns. Jeff * Inversion mod n might catch this on the blinding factor side, but doing it that way might give worse error reporting. p.s. I looked more seriously at blind BLS signatures, seemingly not as bad as I'd feared, although the public key validation issues are likely to remain tougher than one normally expects, especially for this application.

1 0

Re: [tor-access] Predicting effectiveness
by Alex Davidson 04 Oct '16

04 Oct '16

> If this becomes an issue, there is an approach that might work : Just > use multiple signing keys, one system wide key C for all CloudFlare > sites, and individual site keys for each site CloudFlare protects. If > you solve a CAPTCHA then you withdraw a moderate stack of C tokens. If > you visit site X then you spend an X token if you have one, but if you > do not then you spend a single C token to withdraw tens of thousands of > X tokens. So solving a CAPTCHA is worth hundreds of thousands of page > loads, but only across a moderate number of sites. We could've separate > Cbig and Csmall keys such that first it withdraws with Csmall, but if > the users blows through that quickly then it withdraws with Cbig. The spec already accounts for this by giving out a single-domain cookie to any client that successfully redeems a token. We'd need to figure out how long these cookies last for (a day perhaps?), but the idea is that the client would no longer need to redeem any more tokens for that domain. Each token effectively guarantees you access to a resource for the given time period. Because of this we have reduced the number of tokens that should be handed out. For example in the original spec 10,000 tokens were talked about as a reasonable amount whereas in our implementation we use somewhere between 100 and 1000. In our implementation we struggled to work with more than 1000 tokens without rendering the browser complete useless for a fairly long time period anyway, since the extension has to verify and unblind each of the tokens it receives. Alex

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

tor-access October 2016