taler
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Taler] presenting refreshment


From: Jeff Burdges
Subject: Re: [Taler] presenting refreshment
Date: Wed, 07 Oct 2015 01:34:21 +0200

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.  

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.

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.
Jeff

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]