On Mon, May 10, 2004 at 08:02:12PM +0000, Jason Holt wrote:
Adam Back wrote:
[...] However the server could mark the encrypted values by encoding different challenge response values in each of them, right?
Yep, that'd be a problem in that case. In the most recent (unpublished) paper, I addressed that by using R as the key for a ciphertext+MAC on the actual message.
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?
(And you're right, the AIDS example is not very compelling. The slides give a better one about FBI agents, but I'm still looking for other examples of super-sensitive transactions where HCs would fit)
dissident computing I think Ross Anderson calls it. People trying to operate pseudonymously and perhaps hiding the function of their servers in a cover service.
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.
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).
Yeah, although I think most of them would require an on-line trusted server. But that just makes all sorts of things way too easy to be interesting. :)
Yes. But you could explore public key based without IBE. You may have to use IBE as a sub-protocol, but I think ideally want to avoid the IBE server being able to decrypt stuff. Sacrificing the IBE communication pattern wouldn't seem like a big deal. Hmm well IBE is has a useful side-effect in pseudonymity systems because it also has the side-effect of saving the privacy problems in first obtaining the other parties key. Other way to counteract that is to always include the psuedonym public key with the pseudonym name (which works for mailto: style URLs or whatever that are electronically distributed, but not for offline distributed). Btw one other positive side-effect of IBE is the server can't impersonate by issuing another certificate in a pseudonyms name because there is definitionally only one certificate. I was thinking particularly if you super-encrypt with the psuedonym's (standard CA) public key as well as the IBE public key you get the best of both feature sets. btw#2 You could probably come up with a way to prevent a standard (non IBE) CA from issuing multiple certs. eg. if he does that and someone puts two certs together they learn CA private key, ala Brands credential kind of offline double spending protection. Kind of a cryptographically enforced version of the policy enforced uniqueness of serial numbers in X.509 certs. And we change the policy to one cert per pseudonym (kind of sudden death if you lose the private key, but hey just don't do that; we'd have no other way to authenticate you to get a new cert in the same psuedonyms name anyway, so you may just as well backup your pseudonym private key). Adam