Re: [Taler] presenting refreshment

[Christian Grothoff]

On 10/07/2015 01:34 AM, Jeff Burdges wrote:
> On Wed, 2015-10-07 at 00:21 +0200, Christian Grothoff wrote:
>>>> customer performing linking must be able to do it without knowing
>> the
>>> private transfer key.
>>>
>>> yes. encrypting anything with the old coin's public key allows the
>>> customer (who knows the old coin's private key) to decrypt it.
>>
>> Careful, you cannot just 'encrypt' using a Curve25519 point and
>> decrypt
>> it with the scalar. That does not work. With the ECC we use here, we
>> can
>> sign and do DH, but for DH you need *two* public key pairs, not just
>> one
>> coin public key. So I think you're confusing the use of RSA for blind
>> signatures with our use of ECC for coin signatures and coin-DH.
> 
> There is an amusing scenario that this confusion leads to : 
> 
> A particularly worried merchant might demand that a customer prove they
> have sufficient funds before beginning some transaction.  A customer
> could show them the coins without signing anything.  At which point,
> the merchant could 'reserve' those coins with the mint.  

(1) That's a silly thing for the merchant to worry about, as the
contract only becomes valid/accepted if (sufficient) coins are signed over.

(2) This is the 'locking' protocol we dropped from the original design
as it is just overhead without really achieving anything terribly
relevant (just complexity).

> All fine so far, but there is a race condition here in that one fake
> merchant requiring this can show their customer's coins to a real
> merchant requiring the same thing.

Not with locking. But regardless, you don't want to ever 'show coins'
just for show, as then you have to refresh if the contract doesn't go
through.

> If our merchant asks the customer to sign a pre-contract, then the
> customer needs to trust that hash collision should be impossible on
> that pre-contract.  Now that's easy enough, but it's slightly faster if
> the customer just does a DH exchange with an ephemeral key provided by
> the merchant.  It's necessary to actually send some encrypted data over
> this encrypted link, but that's fast.  As that communication is
> authenticated by the mint, the middle fake merchant cannot do an mitm
> attack.  
> 
> All this appears useless in practice since RSA is so slow, but still.

I agree this is useless, but I don't see how this has anything to do
with RSA being slow. First of all, RSA signature verification is rather
fast (after all, we can pick the exponent to be small!), and secondly we
don't do DH or contract signing with RSA (Taler uses EdDSA for contract
signing).

0xE29FC3CC.asc
Description: application/pgp-keys