[tor-dev] Proposal for PoW DoS defenses during introduction (was Re: Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension)

[Jeff Burdges]

> On 2019-06-20 00:19, Watson Ladd wrote:
>> 
>> Privacy Pass has already been integrated into Tor Browser. Perhaps
>> work could be done to use it here?
> 
> As I said above, any oblivious PRF scheme like privacy pass violates privacy *if* you can supply different keys to different users.  We cannot derive the OPRF key from the HS key, so this requires some messy solution like certificate transparency or more likely zero-knowlege proofs.

Actually there is a method to use oblivious PRFs without sharing secrets, which then makes the HS key itself usable:  Just check the oblivious PRF token at the HS itself, not at the introducer.  If the token checks out then the HS responds quickly, but if not then it responds after some delay.  Introducers do nothing different in this design, but introduce cells can contain more data.


> If otoh you use blind signatures then the blind signing key can be derived from the HS key, which avoids this complexity.  We’ve new complexity in that blind signatures using an Edwards curve really suck, but we should be fine so long as only the soundness is weak, not the blindness.  I have not refreshed my memory on this point yet.

There is a tricky one-more-forgery attack on Schnorr blind signatures, but not afaik any key recovery attack:
https://www.iacr.org/archive/crypto2002/24420288/24420288.pdf

As a defence, one could do blind signatures in G^3 requiring three scalar multiplications per signature from both signer and client, but limiting the forgery count to 1 per 63 signatures, which sounds acceptable.
https://www.math.uni-frankfurt.de/~dmst/teaching/SS2012/Vorlesung/EBS5.pdf

We’d need to work out if using some key derived from the HS key works however because we must avoid creating a signing oracle for HS keys too.


So.. Do you want the filter at the introducer or at the HS itself?

Jeff


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20190620/f62b7808/attachment.sig>