[tor-dev] Improving onion service availability during DoS using anonymous credentials

[Jeff Burdges]

There is another component of the design space:

Do you want credentials to be movable from one introduction point to another?

If so, you can do this or not with both blind signatures and OPRFs by enabling or restricting their malleability properties, but probably not with anything symmetric.  If tokens are movable, then this encourages users to use multiple introduction points, but doing so sounds unlikely, but worse gives DoS attackers parallel access to introduction points.  I suppose no for this reason, but maybe it’s worth considering for the future..


> On 23 Mar 2020, at 14:23, George Kadianakis <desnacked at riseup.net> wrote:
> - Discrete-logarithm-based credentials based on blind signatures:
> 
>    This is a class of anon credential schemes that allow us to separate the
>    verifier from the issuer. In particular this means that we can have the
>    service issue the tokens, but the introduction point being the verifier.
> 
>    They are usually based on blind signatures like in the case of Microsoft's
>    U-Prove system [UUU].

We should mention that Fuchsbauer, et al. recently addressed the forgeability problem for blind Schnorr signatures in https://eprint.iacr.org/2019/877.pdf which should improve performance, but still costs more round trips than slower blind signature variants.  I think the attacks were never relevant for DoS protection anyways though.

You need 64 bytes for the Schnorr signature plus whatever you require to identify the signing key, so 80-96 bytes .

> - Discrete-logarithm-based credentials based on OPRF:
> 
>    Another approach here is to use OPRF constructions based on the discrete
>    logarithm problem to create an anonymous credential scheme like in the case
>    of PrivacyPass [PPP]. The downside, IIUC, is that in PrivacyPass you can't
>    have a different issuer and verifier so it's the onion service that needs
>    to do the token verification restricting the damage soaking potential.

Issuer and verifier must share secret key material, so not exactly the same thing as being the same.  You must share some special public key material for the blind signatures.

I believe redemption could cost 64-96 bytes bytes, so a 32 byte curve point, a 16-32 bytes that identifies the issuing key, and a 16-32 bytes seed that gets hashed to the curve.

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/20200323/2512111f/attachment.sig>