-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 9 May 2004, Adam Back wrote:
and seeing that it is a completely different proposal essentially being an application of IBE, and extension of the idea that one has multiple "identities" encoding attributes. (The usual attribute this approach is used for is time-period of receipt .. eg month of receipt so the sender knows which key to encrypt with).
Right, good summary.
One claim is that the system should hide sensitive attributes from disclosure during a showing protocol. So the example given an AIDs patient could authenticate to an AIDS db server without revealing to an outside observer whether he is an AIDs patient or an authorised doctor.
However can't one achieve the same thing with encryption: eg an SSL connection and conventional authentication?
How would you use SSL to prove fulfillment without revealing how? You could get the CA to issue you a "patient or doctor" SSL cert, likewise for every possible combination of things somebody might ask you for, but that's not very practical. Presumably this is why the other systems also allow proof of expressions without revealing all the attributes you used to do so.
Outside of this, the usual approach to this is to authenticate the server first, then authenticate the client so the client's privacy is preserved.
If you can trust the server to do so. Firstly, hidden credentials limit what the server learns, so you don't *have* to trust the server as much. But secondly, they also solve the problem which shifts to the server when it goes first: now the server has to reveal attributes to a complete stranger. For sensitive systems, it's easy to get circular dependencies where neither side wants to go first. Hidden credentials let you enforce the policy in the ciphertext: "if you can read this, let's talk. if not, I didn't want to talk to you anyway (and you won't learn why)". (Incidentally, two other similar systems came out at about the same time as mine, both geared less toward extreme policy/credential paranoia and more toward resolving such circular dependencies: OSBE (Li, Du, Boneh) and Secret Handshakes (Balfanz et al)).
Further more there seems to be no blinding at issue time. So to obtain a credential you would have to identify yourself to the CA / IBE identity server, show paper credentials, typically involving True Name credentials, and come away with a private key. So it is proposed in the paper the credential would be issued with a pseudonym. However the CA can maintain a mapping between True Name and pseudonym.
However whenever you show the credential the event is traceable back to you by collision with the CA.
Right, that is a big consideration with my system; CAs can be nosy. Of course, any CA will want you to show paper credentials or some other real-world proof that they should give you a credential. But you're right that the Chaum/Brands/L&C family do have a big advantage in limiting the risks of big-brother CAs once they've issued it to you.
I would not say your Hidden Credential system _is_ an anonymous credential system. There is no blinding in the system period. All is gated via a "trust-me" CA that in this case happens to be an IBE server, so providing the communication pattern advantages of an IBE system.
If your definition requires anonymity wrt the CA, then you're right. My system lets folks: * authenticate based on attributes rather than identity * access resources without the server even knowing whether they fulfill the policy * hide policies from people who don't fulfill them So it's definitely in the realm of other privacy systems. We could define a new term just to exclude my system from the others, but at this point I don't think naming confusion is any worse for my system; they all have lots of different nonorthogonal features. I have to write a survey paper for my Ph.D. requirements, and I've been thinking I should write a big feature table as part of it.
In particular I don't see any way to implement an anonymous epayment system using Hidden Credentials. As I understand it is simply not
I've never really considered it as a payment system. It's geared more toward systems which use extremely sensitive resources, and their corresponding sensitive policies and credentials. -J -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAnuwCnwLgjivV2NERAs/lAKC2B9R0EQJY+fgh46QpjkdmsdjbMwCgziHw VRCNzAhIdnIImHMyu7Lpvwk= =wpJ0 -----END PGP SIGNATURE-----