"patent free(?) anonymous credential system pre-print" - a simple attack and other problems

Jason Holt jason at lunkwill.org
Tue Nov 5 21:18:40 PST 2002

(Re: my paper at http://eprint.iacr.org/2002/151/ )

Stefan Brands wrote:
> - The system is subject to a simple attack. The problem lies with the
> multiplication of the  hashes. Let's take the Chaum blinding as an

	(For our readers at home, that was the vulnerability I mentioned in my 
response to Adam).

> - My work certainly does provide for "revocable anonymity" and "pooling"
> prevention. For  pooling protection, see paragraph 2 on page 193,
> section 5.11 page 210 paragraph 2, and  section 5.5.2 on page 211. For

	When I speak of pooling credentials, I'm talking about Alice
presenting her student ID along with the senior-citizen ID Bob loaned her (or
for which Bob is answering clandestine-ly), as if they both belonged to her,
in order to get both discounts on her movie tickets.  In my system, you get
your credentials issued in a set associated with a single identity, and it's
hard for Alice to get Bob's credentials included in one of her own sets.  It
works even if the CAs don't trust each other.

	Page 211 of your book talks about discouraging lending, which doesn't
help in the case when Bob answers in Alice's behalf when she shows his
credentials.  In any case, section 5.5.2 only adds liability to pooling - it
doesn't prevent it mathematically.  (As to lending in general, I think you're
right that discouragement may be the best we can do).

	Page 193 and 210 do talk about having an identifying value encoded in
the credentials which the holder can prove is or isn't the same as in other
credentials.  However, the discussion on page 193 is with respect to building
digital pseudonyms, and the discussion on page 210 seems to be about showing
that values are *not* the same, following a scenario in which a pseudonym
holder has been identified as a misbehaver. I can think of ways in which this
feature might be leveraged to create otherwise-unlinkable sets of credentials
from different (distrusting) CAs, but it's never addressed directly that I can
see, and would need some specifics filled in.  Nonetheless, I'll point out in
my paper that it's a possibility in your system.

> - The proposed hashing technique for selective disclosure was introduced
> by myself in 1999.  Quoting from page 27 of my MIT Press book titled

	Pages 27 and 184 of your book are now both referenced in my section on
selective disclosure.

> - More seriously, the simple hash technique has numerous drawbacks, as I
> explain on page page  27 of my MIT Press book, in the very same
> paragraph: "Although certificate holders now have  some control over
> which attributes they reveal to verifiers, they are forced to leave
> behind digital signatures. ...

	What do you mean by "forced to leave behind digital signatures"?  

> ...  Worse, nothing prevents the CA and others from tracing and linking all
> the communications and transactions of each certificate holder." ...

	This is of course overcome in my system with blinding and

> [
>   Snipped discussion of features which Brands' system has and my system 
>   doesn't: boolean formulae, lending prevention, limited show,
>   wallet-with-observer, discarding protection, anonymous recertification /
>   updating, multi-application certificates, etc.
> ]

	From my response to Adam Back:

I'm glad that was clear in my text.  This isn't a do-everything system like
Brands' - rather, it has 2 aims.  1: show how to do simple selective
disclosure in a Chaum/Fiat/Naor-like system using X.509v3 credentials as a
base, and 2: show how to link credentials from multiple issuers to the same
identity without compromising anonymity.

	And actually, I forgot to mention the original goal of my paper, which
was to create a system not encumbered by your patents or Chaum's.

	I'll expand my related work section to point out that your system and
others have lots of features which my system doesn't attempt to provide.  My
apologies if my terse treatment mischaracterized your work.


More information about the cypherpunks-legacy mailing list