Can you kindly remove me from the mailing list.
From:
Taler <taler-bounces+sahnil=uw.edu@gnu.org> on behalf of Jeff Burdges <burdges@gnunet.org>
Date: Wednesday, September 8, 2021 at 6:54 PM
To: jcb62281@gmail.com <jcb62281@gmail.com>, Taler <taler@gnu.org>
Subject: Re: [Taler] [rms-rss@gnu.org: 'Oh, that's an idea...': U.S. parents respond to China screen time ban]
> On 8 Sep 2021, at 03:05, Jacob Bachmeyer <jcb62281@gmail.com> wrote:
> How does your proposed system handle a "borrowed" or outright stolen user key? The server cannot identify the user, so how can Mallory walking off with a copy of Alice's key be detected?
Slowly. :)
If Alice updates her entry in the ring then the new ring gives her all new accounts everywhere. We must expire old rings but we do not want all users building new heavier zk proofs everytime the ring updates.
We’d maybe implement a special joining ring with a signature so that Alice could initially join and later rejoin instantly. We’d maybe have a staging process by which multiple regular ring iterations could be accepted simultaneously too. It follows some
overlap exists between Alice’s new accounts and the thief accessing her old accounts.
If Alice has backed up her key, then she could deprecate individual important accounts instantly via some migration protocol, but if she lost her old key then only the thief accesses her old accounts but only until the old ring gets deprecated.
It’s always tricky to set expiration times: If mobile devices can only produce the heavier proofs when plugged in, then old rings could be expired like every 24 hours I guess. Yet, if you disappear offline for a few days then you need internet access and
this computation time before using the system. This computation time is likely similar to a zcash tx.
We’ve an issue that thieves like perhaps governments who access Alice’s key could identify her across all websites. Any single use token protocol reduces this problem, ala CloudFlare’s PrivacyPass, but then websites cannot block missbehaviour and the system
requires careful rate limiting.
Jeff