Identity Based Encryption
Hello, I have had a look at Identity Based Encryption but I have not been able to find out whether there are any protecting patents. It appears that the breakthrough happend just two years ago with the work of Beneh and Franklin [1] and there exist an open source implementation of their scheme (no GPL though) from the same Applied Crypto Group at Stanford http://crypto.stanford.edu/ibe/ Not sure whether the Voltage Security software, which was discussed on this list back in July, is actually based on this very same implementation (I think it is the same people). Does anybody know more about how free it is to develop another IBE implementation? I know that HP also have their own implementation of IBE, which is also not freely available. And there is another IBE schema developed by Cocks [2] of which I haven't come across any implementation yet Ciao Al [1] SIAM J. of Computing, Vol. 32, No. 3, pp. 586-615, 2003. Extended abstract in proceedings of Crypto '2001, Lecture Notes in Computer Science, Vol. 2139, Springer-Verlag, pp. 213-229, 2001. [2] C. Cocks, An identity based encryption scheme based on quadratic residues, Eighth IMA International Conference on Cryptography and Coding, Dec. 2001, Royal Agricultural College, Cirencester, UK. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Voltage - Identity Based Encryption.
On Mon, 7 Jul 2003, Hack Hawk wrote: So what they're saying is that your PRIVATE key is stored on a server somewhere on the Internet?!?! No, this (like Kerberos) works best in a federated model. Each organization (or group of organizations that trust a common third party and have mechanisms to authenticate their users to said party) runs a key server. The recipient's address together with the organization-wide public key of the recipient's server (s.P) allow the sender to unilaterally construct a session key that is only recoverable by recipient's private key which is derived from the recipient's server secret and the recipient's identity. The recipient needs to (at least once) authenticate to *his* server and get his private key. The server secret s (like a KDC master key in Kerberos) yields *everyone's* private key in the organization in question. Unlike a KDC the database consists only of a single secret! If a user's key is compromised, the user needs to change identities (email adddreses). If a server key is compromised, ... This obviates the need for key exchange between individual users, but creates a need for a TTP in each participating organization or consortium. I look at this as a Kerberos alternative with a public/private master key. Creating a session key does not involve any calls to the KDC because the KDC public keys are published. Interactive user principals can avoid storing their keys in persistent storage, by authenticating each time (the mail client starts), disconnected users or server applications store secrets in access controlled storage (analogous to keytabs). In an AD environment the authentication to the new key server can use the real Kerberos... Unlike the real Kerberos this does not require (n^2)/2 keys, but it does require (n^2)/2 key exchanges of n keys, otherwise one gets back to Verisign style models for server key signing. Key management does not ever go away! How does one secure the key management? (Bilaterial diplomatic cases chained to wrists work, but are difficult on an Internet scale)... If all server keys are held in write-only tamper-proof hardware, perhaps server key revocation will be rare and key exchanges might be less frequent... As on online protocol, it resembles Kerberos even more, but perhaps works better accross organizational boundaries. Each organization periodically obtains via some secure channel the public keys of their business partners. These are leveraged to create secure channels between users. The channels are not server mediated so unlike a VPN or SMTP+TLS, the crypto is end-to-end with the servers at each site holding a secret that can compromise every user. I doubt Voltage.com will be able to sell everyone on a single server for the whole Internet so the bilateral key management problem does not go away, it just gets factored into clumps... Please correct my impression if I got this completely wrong... -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Voltage - Identity Based Encryption.
also sprach C. Wegrzyn [EMAIL PROTECTED] [2003.07.08.2324 +0200]: This is the same approach used in the Authentica system but it is deployed in an enterprise environment. Sure, but this doesn't make it any more secure. I only know very little about Authentica, but it also doesn't strike my fancy. Private keys are private, period. There got to be other ways to make PK cryptography easier. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] invalid PGP subkeys? use subkeys.pgp.net as keyserver! die menschen drängen sich zum lichte, nicht um besser zu sehen, sondern um besser zu glänzen. - friedrich nietzsche pgp0.pgp Description: PGP signature
