[Top][All Lists]

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

Re: [Taler] post-quantum refresh

From: Jeff Burdges
Subject: Re: [Taler] post-quantum refresh
Date: Mon, 04 Apr 2016 18:33:08 +0200

On Mon, 2016-04-04 at 01:38 +0200, Jeff Burdges wrote:
> It's important however that a coin has zero value left on it after
> being
> melted because it cannot be melted twice, not without either the
> wallet
> keeping checking the state or the wallet retrieving the state from the
> exchange.  I suppose this makes recovery from backup more fragile. 

We chatted about the restoring from a backup situation over lunch.  It's
problematic because a malicious or sloppy exchange could allow a
refreshed coin through the refresh process a second time, choose a
different gamma, and expose the link.  

I believe the strongest fix would be :  Use the hash based linking key m
to encrypt a curve25519 public key P = p G where p is random.  Encrypt
the coin generator s with H( m, p C ).  Reveal both m and p for the
coins the exchange does not choose.

In this way, a user who never restores from backup gains full
post-quantum protection unconditionally.  A user who restores from a
backup risks exposing refresh that started before the backup and ended
after it, but only to a quantum adversary.  

As no quantum adversary exists now, the exchange should behave correctly
by not allowing the wallet to make this error, and linking data should
expire well before anyone invents a quantum computer.  If someone
invents a quantum computer, then wallets should be modified to mark all
coins as possibly tainted during backup, and take measures to avoid
refreshing restored coins into new coins. 

There is no need to store the m_path or m_hide records with the linking
data, so the storage costs do not grow.  And the coin generators s
actually reduced the storage costs. There is however a need to transfer
these things to the exchange.  In n<theta is the number of new coins
being issued, that costs like 16*( kappa*n + log theta ) extra bytes of



p.s.  There are probably schemes for making gamma deterministic that
fixes this, but that sounds shitty and fragile.  Just using both methods

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

reply via email to

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