Hooking nym to wikipedia (fwd)

Jason Holt jason at lunkwill.org
Mon Oct 3 08:58:28 EDT 2005



---------- Forwarded message ----------
Date: Mon, 3 Oct 2005 08:32:44 -0400
From: Paul Syverson <syverson at itd.nrl.navy.mil>
Reply-To: or-talk at freehaven.net
To: or-talk at freehaven.net
Cc: cryptography at metzdowd.com
Subject: Re: Hooking nym to wikipedia

Hi Jason et al,

On Mon, Oct 03, 2005 at 11:48:48AM +0000, Jason Holt wrote:
>
> More thoughts regarding the tokens vs. certs decision, and also multi-use:
>
[snip]
>
> A related approach that thwarts the network eavesdropper would be to issue
> a series of certificates which expire one per interval (hour/day/whatever,
> trading privacy against the hassle of managing lots of certs).  Then our
> dissident uses each cert in turn, securely deleting it after it expires.
> The CA keeps a list recording all the certs issued to the same user, and
> when Wikipedia wishes to ban a user, the CA revokes all the unexpired certs
> for that user.  The CA also securely deletes expired certs from its lists,
> so that if compromised, it has merely the same list of certs found on the
> client machine, and is likewise devoid of any reference to certs used in
> prior transactions.
>
> Of course, there are nifty cryptographic solutions to the problem of
> revoking repeat offenders without linking activities of good users.
> Private Credentials and Idemix are the two best known examples, but both
> are complicated and patent-ridden.
>

You might want to have a look at our UST (Unlinkable Serial Transactions)

It was published in ACM TISSEC

http://chacs.nrl.navy.mil/publications/CHACS/1999/1999stubblebine-serial.pdf
(or .ps)

There was also an earlier version published at Financial Crypto.
(It lacks the proofs and some improvements to the protocols)

http://chacs.nrl.navy.mil/publications/CHACS/1997/1997goldschlag-FC97.pdf
(or .ps)

1. I think it is much less complicated than the other things you raised,
    but of course has other tradeoffs.

2. The papers are it. There is no current code worth looking at.

3. Thanks for the reminder. It too is patented if not patent-ridden,
    but we should be able to cope with that. Basically you shouldn't put
    huge work in assuming that there are no encumbrances to address, but if
    you are interested given 1 and 2 after you look at it, let me
    know. I can then explain the issues regarding the patent situation.

aloha,
Paul




---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list