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]