(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