[tor-access] Specification for bypassing CAPTCHAs using blinded tokens

Jeff Burdges burdges at gnunet.org
Mon Oct 3 19:21:00 UTC 2016


On Mon, 2016-10-03 at 09:43 +0000, Georg Koppen wrote:
> Thanks for the update. While I am still mulling over parts of the
> specification let me start with an issue I found while reading. I am
> wondering about how your specification is supposed to work for users of
> Private Browsing Modes in general and Tor Browser with its Disk
> Avoidance requirement[1] in particular.
> 
> Looking at section 7.1 it seems to me all those tokens (blinded/signed)
> are saved somewhere on the user's machine. As far as I can see the
> specification does not elaborate on this point further but I guess they
> are supposed to be saved on disk. This is not working for us at least.
> Thus, the other option would be to have them in memory. But then the
> user would be recreating tokens and getting those new tokens signed with
> every visit of a Cloudflare guarded site after Tor Browser got started.

This is an interesting objection that impacts Taler as well.  For Tails,
we'd might try to integrate with Tails directly and tweak Taler to ask
for persistence before doing the withdrawal.  I should read [1] to
better understand disk avoidance issues beyond Tails.*

> Additionally, and in contrast to what your spec is claiming in section
> 8.1, we have the New Identity feature[2] that is e.g. aimed at dealing
> with powerful first party entities and their long-term linkability
> capabilities. That feature ensures that by invoking it a user gets a
> clean, new browsing session. Thus, new tokens would need to get created,
> blinded and signed in this case again. 

If properly implemented, then blind signatures from one session can
safely be used with another session.**  

There are a bunch of caveats about the "properly implemented" part in my
previous email, like not using the full domain for the blinding factor,
and some additional ones I neglected to mention like key validation with
GCDs checks.  

Yet, the RSA blind signature primitive itself seems information
theoretically secure, assuming your blinding factor is a random oracle,
and the mint's public key is honestly a product of two large primes. 

Against Taler's anonymity, I believe the best attack is to detect
SHA2-512 output as non-random without knowing anything about the value
being hashed.  If a adversarial mint can do O(m^2) such recognition
attacks on SHA2-512 where m is the total coins processed system wide
during a denomination key lifetime, say 6 months, then they gain 1 bit
of deanonymizing information per coin, which lets them perform an
intersection attack. 

Anyways, there were notable gaps between theory and practice for blind
signatures, which we've fixed in Taler afaik.  If these gaps are
addressed, like we addressed them, then tokens from one session should
be safe to use with another session.

> And, as a final angle, we plan to get Tor Browser on mobile to feature
> parity with the one for desktop rather soon because there are large
> regions of the world that access the Internet mainly (or even only) over
> the phone. Often this is accompanied by unreliable and slow connections
> and it is probably still not uncommon that users in those countries have
> to pay for transferred bytes. Moreover, battery power is a scarce
> resource on mobile devices and public key cryptography is expensive.
> Thus, it seems to me that getting the tokens created, blinded and signed
> again and again after New Identity and restart of Tor Browser is
> especially problematic for those users.

This should be okay for Taler itself as coins represent money.  

Assuming persistence, users devices do their RSA computations during
withdrawal, but they're doing them for future page load in CloudFlare's
case.  In Taler, a single token requires two exponentiations mod n by
the smallish public exponent e, one for encrypting the blinding factor
and one for signature verification, and two extra GCD computations to
protect against malicious mint key's with hidden small prime factors***,
and two cheap modular multiplications.  Afaik, there need not be
additional public key crypto at page load time.  

I'd expect battery usage is improved by withdrawing more tokens at once.
Yes, this drains the battery more then, possibly forcing a recharge, but
overall this cost becomes less random.  So the question becomes : Would
CloudFlare make withdrawal sufficiently rare by allowing enough coins to
be withdrawn at once?

Best,
Jeff

> [1] https://www.torproject.org/projects/torbrowser/design/#disk-avoidance
> [2] https://www.torproject.org/projects/torbrowser/design/#new-identity


* For Taler, an options might be to return all the coins to the user's
reserve, which conceivably could be printed as a QR cod and scanned in
by Taler.  That's problematic because the reserve deanonymizes the user.
We could however create a second anonymous reserve and construct the
Taler coins so that they can only be refunded to that reserve via some
analog of our refresh protocol.  I think this still kinda sucks though
because withdrawals produces correlated activity with a non-anonymous
reserve.  Persistence seems preferable. 

** There were ideas about going with more efficient schemes, like maybe
whatever Brave uses.  We could look into that but my superficial take
is :  Anything like that will be doing this dance around pairing-based
crypro, so one must worry seriously about the concerns around decisional
Diffie-Hellman that I mentioned in my previous email.  I'd expect the
issues can be dealt with because there are a bunch of serious folks like
Matt Green behind ZCash, but they require rather deep expertise with
pairing-based crypto.  Also these schemes all move public key crypto
from the withdrawal phase to page load time, so maybe that's bad for
battery life. 

*** I neglected these GCD computations in my previous email, but they
are crucial for anonymity.  I actually missed them myself, after finding
the more subtle hash recognition attacks, but a fellow named
CodesInChaos asked me about GCDs at some point.  We could ask him if he
is interested in being added to this list.  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.torproject.org/pipermail/tor-access/attachments/20161003/07af6184/attachment-0001.sig>


More information about the tor-access mailing list