taler
[Top][All Lists]
Advanced

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

Re: [Taler] G the generator


From: Christian Grothoff
Subject: Re: [Taler] G the generator
Date: Mon, 05 Oct 2015 00:38:17 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0

Dear Fabian,

I think some of these issues were already addressed, others I don't see
the reason for (like your introduction of L for (E, T_P) -- just another
symbol for the reader to remember).

What I should say is that I strongly dislike your use of the term
'identity'. Maybe that's because in GNUnet we have identities (which are
like pseudonyms), but also it just doesn't feel right to think of
cut-and-choose options as 'identities'. It's just a terrible term here,
especially as the gamma-identity becomes a coin. And coins are certainly
not 'identities'.

As for your point (2), this is not so much a choice. During the reveal
step, the mint must be able to verify that the decryption works without
learning the private key of the old coin, and a customer performing
linking must be able to do it without knowing the private transfer key.
DH satisfies this, and so ECC is a good choice for the coin keys as we
can safely do EdDSA and ECDH using the same secret.

So yes, there are arguments for this.

Happy hacking!

Christian

On 10/04/2015 06:12 AM, Fabian Kirsch wrote:
> Dear all,
> Have a look at the paragraphs in the screenshots.
> 
> http://www.krautchan.net/download/1443931492001.png/01_linking_in_general.png
> 
> http://www.krautchan.net/download/1443931492002.png/02a_refreshing_in_general.png
> 
> 
> Encrypt(..)
>    is containing all the stuff that happens with DH and E_K(..)...
> 
> L
>    is the tuple that was called (E,T_p) before.
> 
> What was called step 6 and 7 before, was giving the mint enough
> info to "break" the nongamma-link-encryption and checking if they were
> created fair.
> 
> Here my two cents:
> 1.) For understanding the concept, it is good to start with a high-level
> description.
> 1.a) the presented notation of an encrypted message for C' directly
> matches what everybody expects the Link to be
> 2.) If the best implementation choice is  "we encrypt our link-info by
> combining DH with symmetric crypto but the DH has to be with EC" there
> should be arguments for that.
> 
> greetings
>   Fabian

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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