Re: [Taler] OPRFs

[Jeff Burdges]

On Fri, 2017-11-10 at 17:52 +0100, Christian Grothoff wrote:
> It's not just that, it also makes it impossible for third parties (like
> the auditor) to verify that the exchange acted correctly. 

Yes, these are important properties for full blind signatures, but one
point worth clarifying:

If I understand, their batched DLEQ proofs do provide roughly a Schnoor
signature for the withdrawal, so they suffice for some purposes.  You
loose the blinding when using the DLEQ proof though because their hash
incorporates the blinded T.  In other words, users would reveal their
withdrawal operation when revealing issues to the auditor or a judge.
This is why the DLEQ proof cannot be shown to merchants.

It's actually worse because any batching means the coins withdrawn
together must be deanonymized together for third party verification.
I'd think the protocol with separate unbatched DLEQ proofs triples the
number of scalar multiplications, not sure if hashing to the cure is
slow, and doubles or triples the space requirements. 

As an aside, these Schnorr signatures are extremely sensitive to nonce
reuse issues, so you require a very good PRNG or else you'll reveal your
denomination key.. not such a big deal if you're merely protecting blogs
from SPAM.

> <rant>
> That said, I do not entirely buy their argument that this is about
> increasing performance (bandwidth or CPU). This smells more like a "not
> invented here" motivation, as we/Tor suggested Taler to them before for
> this.

Anyone paranoid enough could worry about their NIST curve choice and/or
their hashing to the curve function ;) but presumably the DH assumption
fixes anything wonky there.


In fact, there are shades of a "bug door" in their no certificates
arguments :
- "The only thing edge to manage is a private scalar. No certificates."
- The edge's public key xG is "posted publicly [similar] to a
Certificate Transparency Log [and] "verifiable by all users and so the
deanonymization attack above would not be possible."

In other words, there is no plan for the Tor Project to control any
certificate authorizing the edge's public keys, ala an auditor key in
Taler.  There aren't even any promises made about any particular
certificate transparency scheme being employed to keep edges from
employing unique keys.  

I think their client software could track the public keys they see
themselves easily enough, but if different edge servers use different
keys then this becomes mostly useless.  In fact, if the transparency log
posts 256 keys supposedly used concurrently by 256 different edge
servers, but secretly all edge servers used all keys, then your edge
server plus your edge public key gives CF 8 bits of identifying
information, but nothing looks suspicious in the transparency log. 

Jeff

signature.asc
Description: This is a digitally signed message part