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

[Georg Koppen]

Jeff Burdges:
> On Mon, 2016-10-03 at 09:43 +0000, Georg Koppen wrote:

[snip]

>> 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.**  

Well, I assumed that blind signatures get properly implemented when
writing my mail. There is more, though. The idea behind New Identity is
clearing browser state as well as this state risks leaking into the new
identity. "state" in this particular case would mean "having been on a
clouldflare customer website before and having blinded tokens ready for
spending". Having done New Identity might even be detectable by the edge
in this case, given that it could send a cookie after performing the
CAPTCHA request and signing the blinded tokens which would get cleared
by New Identity.

[snip]

>> 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?

I don't know. I guess seeing numbers about how both schemes fare with
Tor Browser day-to-day usage might be interesting and could help getting
a better understanding for the constraints at play.

Georg

[snip]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-access/attachments/20161006/016d07cb/attachment.sig>