Re: [Taler] presenting refreshment

[Christian Grothoff]

On 10/06/2015 12:13 AM, Fabian Kirsch wrote:
> Hi Christian
> 
> first: about the term 'identity', which was quite a bad choice.
> what about 'unminted coins' vs. 'minted coins'?

Better, but I still don't really like it. An "unminted coin" isn't
really a coin, it's some kind of raw material (like a chunk of metal).
With your terminology, we'd have to everywhere say 'minted coin' where
we currently just write 'coin', and that makes no sense as all 'real'
coins are 'minted' by some mint.  I think we should stick to 'coin'
instead of 'minted coin'. There are better terms for "unminted coin",
like flan or planchet or "coin blank".  I could go for planchet (de:
Rohling, fr: flan de forçage).

> a keypair whose public key wasn't signed yet by the mint is unminted.
> so
> 1.) the customer provides unminted coins with corresponding links and
> commits to them,
> 2.) the mint chooses one of the links to go unchecked,
> 3.) the customer prooves his fairplay by revealing the unchoosen links
> 4.) the satisfied mint makes the chosen coin a minted coin by signing it.

Well, that's this high-level description which for the paper is too
abstract.
You're also omitting that the customer commits to the coins that are
being melted (and risks to forfeit their value).  I think this is fine
for a high-level description like for the webpage, but not a suitable
level of abstraction for the paper. For the paper, I want it to be very
concrete.

> about the nature of the link:
>> reveal [..] mint must be able to verify that the decryption works
> without learning the private key of the old coin,
> 
> yes. "revealing" means the customer reveals the "plaintext" of the link.
> anybody can check that the decryption works by just encrypting the
> plaintext again (IF its a nonprobabilistic encryption).
> SHOULD the encryption be probabilistic (which it is in the current
> implementation) THEN the random element has to be revealed
> as well in order to check the decryptability by encrypting again.

Eh, I'm confused. In /refresh/reveal, the customer effectively provides
the mint the private (transfer) key which is necessary for the mint to
perform the DH and decrypt the link secret. So the mint really decrypts
to obtain the plaintext, it does not encrypt anything. And the
encryption is hardly 'probabilistic' encryption, it's just normal
symmetric encryption with a DH-derived session key.

> And sugar on top: revealing the random element often makes the plaintext
> easily recoverable which saves some transfers.

Sorry, I'm not sure what you're talking about.  Is the "random element"
gamma, or the transfer secret? Other than that, nothing is 'relevealed'
here (at least not directly) by either party.

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

>> DH satisfies this,
> 
> so DH is sufficient (which i never questioned), but it is not necessary,
> and there is no written comparison to other options.
> I don't question the DH+Enc_K to be a good choice. I really don't like
> it presented as if there was no choice at all.

The paper should present the specific scheme we settled on, not all
possible variations.  Understanding one scheme is hard enough, and as
long as the choices are sound there is no need to discuss inferior
alternatives.