Re: [Taler] OPRFs

[Christian Grothoff]

It's not just that, it also makes it impossible for third parties (like
the auditor) to verify that the exchange acted correctly. A customer
could no longer prove to a judge that the coin he had is valid and that
he thus paid -- without the judge ordering the exchange to disclose its
private key. The latter is obviously problematic for security, but may
also be technically difficult, say if the private key is on an HSM and
cannot easily be extracted.  So the lack of universal verifiability of
OPRF is really problematic in our domain, but doesn't matter for CF.

<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. And for their application, RSA 1024 is perfectly sufficient, and
would be very competitive in terms of CPU time and the bandwidth
multiplier should be around 4x. But doing something yourself with new
and fancy crypto from 2014 is clearly more applicable for a PhD student
than using someone else's solution that already works.  If OPRF really
was chosen for performance, why does the article not have any
benchmarks? Wouldn't that be the first thing to provide? Can't imagine
CF does not benchmark almost everything they do.
</rant>

On 11/10/2017 04:01 PM, Jeff Burdges wrote:
> In Taler, I'd imagine the merchant checks the exchange's denomination
> key signature before running the deposit protocol.  An OPRF makes this
> impossible, so merchants could be used to hide botnet nodes in a DDoS
> attack on an exchange, and maybe merchants should be slightly more
> careful about delays in depositing.

signature.asc
Description: OpenPGP digital signature