Re: [Taler] denomination manipulation

[Jeff Burdges]

On Fri, 2015-11-27 at 19:24 +0100, Christian Grothoff wrote:
> Sree and I have written now several times that /keys is supposed to
> be fetched via Tor,

We've been assuming Tor all along, obviously. 

> by the wallet, in the background without some strange cookies

I'm not sure that eliminating super-cookies or whatever is as easy as
you think, but we can ask the Tor Browser people for help with that, so
I'm not too worried. 

> or god knows what self-identifying information you assume may be
> provided. 

Timing correlation has been the identifying information all along. 


On Fri, 2015-11-27 at 18:18 +0100, Florian Dold wrote:
> The /keys request is completely independent of being logged in
> somewhere.

Wallets do not just randomly perform /keys requests of all taler mints
in existence.  Wallets must make /keys queries in response to an HTML
page that alerts them to a new mint.  A priori, there is every reason
to expect them to do this for old mints too, as Taler is mostly
RESTful.  An adversary controls that HTML page. 


On Fri, 2015-11-27 at 19:24 +0100, Christian Grothoff wrote:
> No. Not
always. More typically, because its old /keys state got stale
> /
expired.  Wallets will do this periodically in the background for a
>
all mints they have discovered/located/found are active/etc.  Wallets
>
may need /keys also simply to refresh existing coins.  So there are 
>
many reasons why a wallet may request /keys, and merchants do the
>
same.

Alright, I'll grant that, if /keys actually auto-updates for say the
mints for which the wallet holds coins, then over time the majority of
/keys accesses will not be correlated to web page activity.  I believe
that this should be enough to protect *existing* users against
denomination manipulation attacks.*

This is NOT a part of the spec though, neither is cashing of /keys. 
 You're wrong to complain that I'm highlighting these issues.  

> Mints do not have accounts or logins.

I'm aware that mints do not learn the reserve until the withdraw
request happens.  I'm not talking about reserves when I say accounts
though.  

In practice, there are many mint designs with associated services that
do have logins, like when the withdrawal page is offered by the user's
bank.  

A priori, these services are not likely to bring themselves to the
attention of the wallet until *after* that login.  There are however UI
features that encourage them to signal the wallet first.  That's
mostly* unneeded with the /keys being accessed at other times.

Jeff


*  A powerful adversary could still learn about repeated purchases made
by a person they already had under surveillance during the first month
or so of their using Taler.  I think that's a minor concern, but the
sorts of minor UI changes that discourage this will improve the wallet
UI anyways, so it's no conflict.  I'd say the principle is: The UI
should be improved if a site that interacts with the wallet announces
itself as early as possible.  This means the wallet can default to
showing balances in the right currencies as conveniently as possible. 
 It also means that if the wallet is install, but the mint is new, then
the wallet can fetch /keys before the site learns anything about the
user.

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