Re: Brands' private credentials
On Wed, Apr 28, 2004 at 07:54:50PM +, Jason Holt wrote: Last I heard, Brands started a company called Credentica, which seems to only have a placeholder page (although it does have an info@ address). I also heard that his credential system was never implemented, It was implemented at least twice: once by ECAFE ESPRIT project years ago, more recently by ZKS before they stopped licensing the patents. Anna Lysyanskaya and Jan Camenisch came up with a credential system that I hear is based on Brands'. Anna's dissertation is online and might give you some clues. They might also have been working on an implementation. I looked at Camenisch protocol briefly a couple of years ago and it is not based Brands. It is less efficient computationally, and more rounds of communication are required if I recall. But one feature that it does have that Brands doesn't have directly is self-reblindability. In their protocol it is the credential holder who does the blinding, rather than the issuer / holder, and the issuer can also re-blind to get a 2nd unlinkable show. The way you do this with Brands is to have the CA issue you a new credential in a re-issuing protocol; Brands re-issuing protocol has the property that you do not even have to reveal to the CA what attributes are in the re-issued cert. On re-showable/re-blindable approach, as with Ernie Brikell's re-showable credential proposal for Palladium the converse side of unlinkable re-showing is that there is no efficient way to revoke credentials. (If eg the private key is compromised, or the credential owner violates some associated policy in the Palladium/DRM case). (Caveat of course I think DRM is an unenforceable idea and the schelling point ought to be not to even pretend to do it in software or hardware, rip-once copy-everywhere *always* wins). I came up with a much simpler system that has many similar properties to Brands', and even does some things that his doesn't. It's much less developed than the other systems, but we did write a Java implementation and published a paper at WPES last year about it. Is this the same as described in http://eprint.iacr.org/2002/151/ with interactive cut-and-choose and large credenitals? There was some discussion of that protocol in: http://archives.abditum.com/cypherpunks/C-punks20021028/0076.html Not read the new paper you cite yet. Note that most anonymous credential systems are encumbered by patents. The implementation for my system is based on the Franklin/Boneh IBE which they recently patented, although there's another IBE system which may not be encumbered and which should also work as a basis for Hidden Credentials. The problem with the Yacobi's scheme (which is based on a composite modulus variant of DH where you choose n=p.q such that p and q are relatively smooth so you can do discrete log to setup the public key for an identity) is that to get desirable security parameters for n (eg 1024 bits) you have to expend huge amounts of resources per identity public key. So I would say it is not really practical. It is the only other semi-practical IBE scheme that I am aware of which is why Boneh and Franklins IBE based on weil pairing was considered such a break through. Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
chaum's patent expiry? (Re: Brands' private credentials)
Oh yes, my other comment I forgot to mention was that if non-patent status were a consideration, aside from Wagner's approach, another approach for which the patent will presently expire is Chaum's original approach combined with Niels Ferguson's single term offline coins. (Don't have citation handy but google will find you both). Anyone have to hand the expiry date on Chaum's patent? (Think it is in patent section of AC for example; perhaps HAC also). Having an expired patent might be a clearer route to non-patented status than the putative this is a blind MAC not a blind signature approach of Wagner's protocol. But I obviously am not a patent lawyer, and have avoided reading and participating in the writing of patents. Adam On Sun, May 09, 2004 at 05:08:09AM -0400, Adam Back wrote: [...] I looked at Camenisch protocol briefly a couple of years ago and it is not based Brands. It is less efficient computationally, and more rounds of communication are required if I recall. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Brands' private credentials
[copied to cpunks as cryptography seems to have a multi-week lag these days]. OK, now having read: http://isrl.cs.byu.edu/HiddenCredentials.html http://isrl.cs.byu.edu/pubs/wpes03.pdf 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). On Wed, Apr 28, 2004 at 07:54:50PM +, Jason Holt wrote: properties to Brands', and even does some things that his doesn't. so here is one major problem with using IBE: everyone in the system has to trust the IBE server! I feel a little presumptuous mentioning it in the context of the other systems, which have a much more esteemed set of authors and are much more developed, but I'm also pretty confident in its simplicity. 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? 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. 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. Note that most anonymous credential systems are encumbered by patents. 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. What it enables is essentially an offline server assisted oblivious encryption where you can send someone a message they can only decrypt if they happen to have an attribute. You could call this a credential system kind of where the showing protcool is the verifier sends you a challenge, and the shower decrypts the challenge and sends the result back. In particular I don't see any way to implement an anonymous epayment system using Hidden Credentials. As I understand it is simply not possible as the system has no inherent cryptographic anonymity? Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: chaum's patent expiry? (Re: Brands' private credentials)
On Sun, 9 May 2004, Adam Back wrote: Anyone have to hand the expiry date on Chaum's patent? (Think it is in patent section of AC for example; perhaps HAC also). I think it's June 2005. Actually, now that you mention Chaum, I'll have to look into blind signatures with the BF IBE (issuing is just a scalar*point multiply on a curve). That could be a way to get CA anonymity for hidden credentials - just do vanilla cut and choose on blinded pseudonymous credential strings, then use a client/server protocol with perfect forward secrecy so he can't listen in. Hm, I'll have to think it out. -J - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Brands' private credentials
On Mon, May 10, 2004 at 02:42:04AM +, Jason Holt wrote:
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,
Well SSL was just to convince you that you were talking to the right
server (you have reached the AIDs db server).
After that I was presuming you use a signature to convince the server
that you are authorised. Your comment however was that this would
necessarily leak to the server whether you were a doctor or an AIDs
patient.
However from what I understood from your paper so does your scheme,
from section 5.1:
P = (P1 or P2) is encoded HC_E(R,p) = {HC_E(R,P1),HC_E(R,P2)}
With Hidden Credentials, the messages are in the other direction: the
server would send something encrypted for your pseudonym with P1 =
AIDs patient, and P2 = Doctor attributes. However the server could
mark the encrypted values by encoding different challenge response
values in each of them, right?
(Think you would need something like Bert Jaap-Koops Binding
cryptography where you can verify externally to encryption that the
contained encrypted value is the same to prevent that; or some other
proof that they are the same.)
Another approach to hiding membership is one of the techniques
proposed for non-transferable signatures, where you use construct:
RSA-sig_A(x),RSA-sig_B(y) and verification is x xor y = hash(message).
Where the sender is proving he is one of A and B without revealing
which one. (One of the values is an existential forgery, where you
choose a z value first, raise it to the power e, and claim z is a
signature on x= z^e mod n; then you use private key for B (or A) to
compute the real signature on the xor of that and the hash of the
message). You can extend it to moer than two potential signers if
desired.
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:
OK so the fact that the server is the AIDs db server is itself secret.
Probably better example is dissident's server or something where there
is some incentive to keep the identity of the server secret. So you
want bi-directional anonymity. It's true that the usual protocols can
not provide both at once; SSL provides neither, the anonymous IP v2
protocol I designed at ZKS had client anonymity (don't reveal
pseudonym until authenticate server, and yet want to authenticate
channel with pseudonym). This type of bi-directional anonymity pretty
much is going to need something like the attribute based encryption
model you're using.
However it would be nice/interesting if one could do that end-2-end
secure without needing to trust a CA server.
My system lets folks:
* access resources without the server even knowing whether they fulfill the
policy
this one is a feature auth based systems aren't likely to be able to
fullfil, you can say this because the server doesn't know if you're
able to decrypt or not
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 think it would be fair to call it anonymity system, just that the
trust model includes a trusted server. There are lots of things
possible with a trusted server, even with symmetric crypto (KDCs).
Adam
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: more hiddencredentials comments (Re: Brands' private credentials)
On Mon, 10 May 2004, Adam Back wrote: OK that sounds like it should work. Another approach that occurs is you could just take the plaintext, and encrypt it for the other attributes (which you don't have)? It's usually not too challenging to make stuff deterministic and retain security. Eg. any nonces, randomizing values can be taken from PRMG seeded with seed also sent in the msg. Particularly that is much less constraining on the crypto system than what Bert-Jaap Koops had to do to get binding crypto to work with elgamal variant. In either case, though, you can't just trust that the server encrypted against patient OR doctor unless you have both creds and can verify that they each recover the secret. The above approach should fix that also right? I don't quite get what you're suggesting. Could you give a more concrete example? Hugo Krawczyk gave a great talk at Crypto about the going-first problem in IPSec, which is where I got the phrase. He has a nice compromise in letting the user pick who goes first, but for some situations I think hidden credentials really would hit the spot. Unless it's signifcantly less efficient, I'd say use it all the time. Well, I wouldn't complain. :) (Although pairings are quite slow, on the order of hundreds of milliseconds.) Hilarie Orman presented it at an IETF meeting to what was reportedly a lukewarm response, and they also raised the patent issue. Dan Boneh is sensitive to the issue of patented crypto, and was quite considerate when I asked about it, but www.voltage.com still has the same vague statement in their FAQ about how they're not going to be evil with the patent, so it's still up in the air whether IBE will be useful in IETF standards. -J - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Brands' private credentials
Here's what I remember from about a year ago about the current state of private credentials. That recollection comes with no warranties express or implied. Last I heard, Brands started a company called Credentica, which seems to only have a placeholder page (although it does have an info@ address). I also heard that his credential system was never implemented, but that might be wrong now. Anna Lysyanskaya and Jan Camenisch came up with a credential system that I hear is based on Brands'. Anna's dissertation is online and might give you some clues. They might also have been working on an implementation. I came up with a much simpler system that has many similar properties to Brands', and even does some things that his doesn't. It's much less developed than the other systems, but we did write a Java implementation and published a paper at WPES last year about it. I feel a little presumptuous mentioning it in the context of the other systems, which have a much more esteemed set of authors and are much more developed, but I'm also pretty confident in its simplicity. http://isrl.cs.byu.edu/HiddenCredentials.html http://isrl.cs.byu.edu/pubs/wpes03.pdf Note that most anonymous credential systems are encumbered by patents. The implementation for my system is based on the Franklin/Boneh IBE which they recently patented, although there's another IBE system which may not be encumbered and which should also work as a basis for Hidden Credentials. -J - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
