patent free(?) anonymous credential system pre-print

Jason Holt jason at lunkwill.org
Tue Nov 5 13:20:38 EST 2002


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

	Let me first point out that Dr. Stefan Brands noted an insecurity in
my system which would allow malicious users to obtain issuer signatures on
arbitrary documents.

	This is due to the fact that users aren't prevented from using the
(bitwise) same document for each element but one in the cut and choose
protocol and making the remaining document malicious.  If the malicious
document isn't selected for inspection, dividing out the signatures on the
(n/2)-1 identical documents is trivial, leaving a signature on the malicious
value.

	The credential IDs described in section 4.1 of my paper were designed
to thwart this attack, (and the session random values to thwart similar
attacks over multiple issuing sessions), and do appear to succeed with the
additional requirement that each credential ID be different from the others.
This requirement will be added to the next update to the pre-print.

	This requirement is analogous to the variable i in the preimage of y_i
in the Chaum/Fiat/Naor system.  It ensures that each candidate is different,
and therefore that the values of the elements signed will be unpredictable.  


On Thu, 31 Oct 2002, Adam Back wrote:

> Some comments on this paper comparing efficiency, and functionality
> with Camenisch, Chaum, Brands.

	Thanks for your feedback!

[...]
> - efficiency
> 
> The non-interactive cut and choose protocol results in quite big
> messages in the issuing and showing protcols to attain good security.
[...]
> ... a single credential would be order of 10KB.  Similar for the showing
> protocol.

	Indeed, as section 6 points out, a set of 3 credentials could be a
megabyte in size and require half a megabyte of network traffic.  Efficiency
is /not/ a major selling point of this system. :)

[...]
> - functionality

[pulling up from later on in Adam's post]
> 
> Most of these short-falls stem from the analogous short-falls in the
> Wagner blinding method they are based on.  Of course (and the point of
> the paper) the credentials do offer over the base Wagner credentials
> (a restrictive) form of selective disclosure which the base
> credentials do not.

	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.

	The feature comparison is appreciated, though; it may be useful for an
expansion of the related work section, and in terms of features to add in the
future.

[...]
> The credentials can be replayed (as there is no credential private
> key, a trace of a credential show offers no defense against replay).
> Brands credentials have a private key so they can defend against this.
> (Chaum's credentials have the same problem).

	Section 4.3 specifies that Alice should create a keypair and store the
public key as a selective disclosure field, allowing her to prove ownership as
you describe.

> 
> The credentials unavoidably leave the verifier with a transferable
> signed trace of the transaction.  Brands credentials offer a
> zero-knowledge option where the verifier can not transfer any
> information about what he was shown.

	Good point.

> The credentials support selective disclosure of attributes, but only
> in a restricted sense.  Attributes can be disclosed with AND
> connectives.  However other connectives (OR, +, -, negation, and
> formulae) are not directly possible.  Brands supports all of these.

	Also true.  I point this out in paragraphs 1 and 2 of section 2. 

> 
> The credentials do not support lending deterence (there is no option
> to have a secret associated with a credential that must necessarily be
> revealed to lend the credential as with Brands).

	This could be added to my system.  To be honest, I don't consider
Brands' implementation of lending deterrence to be a worthwhile feature.  
Having embarassing information in a credential could be a deterrence against
lending to an untrusted party, but comes at the cost of an equal liability if
the credential is stolen.  It also doesn't prevent the rightful holder from
providing the response to the challenge on that field when the lendee uses the
credential (in real time).  Lending is a problem which I don't believe can be
solved purely mathematically (which Brands also points out, as I recall).  
Thus I prefer to avoid the topic rather than give it unavoidably insufficient
treatment.

> 
> The credentials are not suitable for offline use because they offer no
> possibility for a secret (such as user identity, account number etc)
> to be revealed if the user spends more times than allowed.

	My credentials aren't designed to do limited-show, although I do point
out in section 4.4.1 that credentials should be used only one time for maximum
privacy.  Revocable anonymity would be sufficient to detect and identify a
multiple-show offender offline, although of course it doesn't protect the
rightful user's privacy like normal limited-show systems.  This is another
feature which I believe could be added to my system in the future.

[...]
> Brands discusses the salted hash form of selective disclosure in his
> book [2], you might want to cite that.  He includes some related
> earlier reference also.  I reinvented the same technique before being
> aware of the Brands reference also -- it seems like an obvious
> construction for a limited hashing based form of selective disclosure.
[...]

	Indeed.  I've mentioned Brands' mentioning in section 3.1.1 of the
update to my paper.

	Thanks again for your time and input.  Unless you prefer otherwise,
I'll add you to the acknowledgements (a14s?) in the next revision of the
paper.

						-J




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



More information about the cryptography mailing list