[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Taler] Blind Schnorr signatures
From: |
Jeff Burdges |
Subject: |
[Taler] Blind Schnorr signatures |
Date: |
Sat, 02 Jul 2016 11:49:06 +0200 |
I mentioned to Christian that Schnorr signatures incurred an extra round
trip when he mentioned that storage costs were a potentially major
component of running Taler in the Amazon EC2 costs tests.
I'm going to expand on this statement below :
Apparently Brands starts with blinded Schnorr signatures. Amongst
other sources, they're described on page 8 of
http://www.di.ens.fr/users/pointche/Documents/Papers/2000_joc.pdf
The extra round trip comes from the exchange sending the user
"commitments" for it's side of the blinding factor, making a full round
trip if the user initiates the protocol. In principle though, an
exchange could maybe send the user a big stash of commitments in
advance, possibly when retrieving the denomination keys, thereby
eliminating any visible round trips. Is this workable?
A denomination private key x could contain another secret value l and
the blinding commitments could be (j,k) where k = HMAC(l,j). To sign,
the user supplies (j,e), so the exchange can recall k and compute s = k
+ e x as usual. After signing the user knows e and s, so fit hey can
trick the exchange into signing twice with the same k, then they can
learn x. This is very bad.
I'd worry the situation might be worse even since making k ephemeral
enough disagrees with the protocol being RESTful. Boo fragile crypto!
I suppose you guys maybe already noticed this in the past, since you
were doing something different from RSA originally, but thought I'd
mention it here.
Jeff
signature.asc
Description: This is a digitally signed message part
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Taler] Blind Schnorr signatures,
Jeff Burdges <=