An Overview of Identity Based Encryption

An Overview of Identity Based Encryption – A White Paper by Vertoda

Copyright © Sykoinia Limited 2009 1


Please Read before reading this White Paper
This white paper is not distributed under a GPL license. Use of this white paper is subject to the
following terms:

 This white paper is copyrighted by Sykoinia Limited. Copyright © Sykoinia Limited
2009. All Rights Reserved.
 You may create a printed copy of this white paper solely for your own personal use.
 Conversion to other formats is allowed as long as the actual content is not altered or
edited in any way.
 You shall not publish or distribute this white paper in any form or on any media, except
if you distribute the documentation in a manner similar to how Sykoinia Limited
disseminates it (that is, electronically for download on a Web site with the software) or
on a CD-ROM or similar medium, provided however that the white paper is
disseminated together with the software on the same medium.
 Any other use, such as any dissemination of printed copies or use of this white paper, in
whole or in part, in another publication, requires the prior written consent from an
authorised representative of Sykoinia Limited.
 Sykoinia Limited reserves any and all rights to this white paper not expressly granted
above.

For more information on the terms of this license or if you are interested in doing a translation,
please contact us at info@vertoda.com.

If you find a typographical error in this white paper or if you have thought of a way to make this
white paper better please contact us at info@vertoda.com.

Please note that this white paper is for informational purposes. Sykoinia Limited accepts no
responsibility for any loss due to the use of this white paper.

If you have any comments please email us at info@vertoda.com with your feedback.



Abstract

This white paper reviews Identity Based Encryption (IBE) and Identity Based Signatures (IBS)
and explores how the schemes work. A review of current research and literature in the area is
carried out and practical implementations of the schemes are considered. We then consider open
issues and possible future work in the area.



Table of Contents

Table of Contents....................................................................................................................................5

Table of Figures....................................................................................................................................... 6

Glossary................................................................................................................................................... 7

1. Introduction ........................................................................................................................................8

2. Common Key Management Systems .................................................................................................. 9

3. Identity Based Encryption .................................................................................................................13

4. Literature & Academic Research.......................................................................................................16

5. Applications......................................................................................................................................19

6. Implementations of IBE.....................................................................................................................20

7. Open Problems & Future Work.........................................................................................................21

9. Digital Signatures & Identity Based Signature Schemes ...................................................................22

11. Conclusion.......................................................................................................................................26



Table of Figures

Figure 1: Symmetric Key Management .................................................................................................................. 11

Figure 2: PKI Key Management System................................................................................................................ 12

Figure 3: Identity Based Encryption....................................................................................................................... 14

Figure 4: Sending an Email using Identity Based Encryption ............................................................................ 15

Figure 5: Hierarchy of Private Key Generators .................................................................................................... 18

Figure 6: A Typical Digital Signature Scheme....................................................................................................... 22

Figure 7: Creating a Digital Signature..................................................................................................................... 23

Figure 8: Verifying a Digital Signature.................................................................................................................... 24



Glossary

A-IBE Accountable Authority Identity Based
Encryption

BDH Bilinear Diffie-Hellmann Assumption

CA Certifying Authority

CBE Certificate Based Encryption

ECC Elliptic Curve Cryptography

GIBE Generalized Identity Based and Broadcast
Encryption Scheme

HIBE Hierarchical ID-Based Encryption

IBE Identity Based Encryption

IBS Identity Based Signature Scheme

JCA Java Cryptography Architecture

JCE Java Cryptography Extensions

MAC Message Authentication Code

PEKS Public Key Encryption with Keyword Search

PKG Private Key Generator

PKI Public Key Infrastructure

WSN Wireless Sensor Network



1. Introduction

Identity Based Encryption (IBE) is a public cryptographic scheme where any piece of text can
act as a valid public key. This is a powerful concept as it means that email addresses, dates or a
combination of both can act as public keys.

The concept of IBE was first proposed by Shamir [1]. However, despite many proposals no
satisfactory implementation of IBE was formulated until 2001 by Boneh and Franklin [2].

This whitepaper will explore how IBE works and will review current literature on the area.
Current and potential applications of IBE will be investigated. Implementations of IBE will be
assessed and. We will also propose future work in the area. We will then consider Digital
Signature Schemes and the Identity Based Signature (IBS) Scheme in particular. Firstly though,
we will assess the most common key management systems.



2. Common Key Management Systems

The Voltage Corporation’s white paper on IBE [3] outlines the requirements for key
management in an enterprise environment. These are:

1. Delivery of Encryption Keys for internal recipients, customers and partners.

2. Authenticate users and deliver decryption keys to users and groups specified by the data
sender.

3. Jointly manage keys with partners where each partner only needs to manage keys for its
own users.

4. Deliver keys to trusted infrastructure components e.g. technical and business processes
such as content scanning, auditing, or anti-virus.

5. Recover Keys e.g. in scenarios where a user leaves the organisation or machines lose disk
storage.

6. Scale for Growth so that large transaction volumes can be managed and load-balanced
and geographic deployments are possible.

This whitepaper [3] also argues that these requirements are not met by the most common key
management systems – symmetric key management and public key infrastructure (PKI) key
management.

illustrates the operation of a Symmetric Key Management system. In essence, the sender tells
the key manager who is receiving the data to be encrypted and an encryption key is set. The
receiver of the encrypted data then authenticates that the data is coming from a valid sender via
the key manager who in turn sends the decryption key so as to enable the data to be decrypted.
The cardinal point to note here is that the same key is used to encrypt and decrypt the data. This
means that Symmetric Key management systems are fast from a performance perspective.
However, in many cases, Symmetric Key Management systems have high storage costs as they
require a database to store the generated keys. Furthermore, the key manager must always be
available as it plays a role in every encryption and decryption operation.

Figure 2 illustrates the Public Key Infrastructure (PKI) Key Management system. The PKI
system uses what are termed public key or asymmetric algorithms where the key used to decrypt
data is different from the key used to encrypt the data. In this system, a public and private key
are created simultaneously by a certifying authority (CA). The private key is given only to the
requesting party (in Figure 2, the receiver) and the public key is made available as part of a digital
certificate in a directory that all parties can access. The private key is never shared and cannot be
accessed via the Internet. Thus, as per Figure 2 the sender accesses the public key from the


central directory and encrypts the data using this key. The receiver then authenticates that the
sender is a valid one from the CA and then decrypts the data with their private key.

One advantage PKI systems have over their Symmetric Key counterparts is that there is no
requirement for a key server to be contacted for each message sent. However, key recovery is
difficult as the recipient generates the private keys him/herself. In addition, a sender must locate
a public key for every recipient and authenticate its validity – this is not always possible as the
directory may not be able to supply public keys for all recipients.

Limitations with both key management systems are apparent when we consider the issue of
mobility. In the case of Symmetric Key Management systems, a very large key management
database would be required when mobile commerce transactions are factored in. We would also
need to consider the fact that the transactions would exponentially increase the number of
operations the key server needs to handle. In the case of PKI Key Management systems the
complexity of its operation would seem to make its practical implementation for Mobile
Commerce systems difficult especially given that the issue of key recovery would be exacerbated
with mobile recipients.



Figure 1: Symmetric Key Management



Figure 2: PKI Key Management System



3. Identity Based Encryption



Figure 3 illustrates the operation of an Identity Based Encryption (IBE) system. The encryption
key is derived mathematically from the receiver’s identity. Thus, when the sender specifies the
identity of the receiver(s) an encryption key is derived. The data is then encrypted and sent to the
receiver who authenticates the data with a key server. Once authenticated, the key server sends
the decryption key to the receiver and the data can be decrypted.

With IBE the sender does not need to contact the key server at all while the receiver only needs
to contact the key server once to authenticate and receive the decryption key. There is no need
for a key database as the server can construct the receiver’s decryption key mathematically.

Encrypting information is also straightforward as the sender can dictate which key server can be
used to protect data. The location of the key server can be in the sender’s or receiver’s
organisation or indeed can be managed by a third party.

Voltage Corporation’s White Paper on IBE [3] outlines how IBE meets the requirements for key
management in an enterprise environment.

1. As the keys are derived mathematically from the recipient’s identity, keys are always
available for recipients.

2. Existing authentication resources such as directories or web authentication can be
reused.

3. Partners can manage keys jointly as IBE facilities the selection of a local key server, a
partner’s key server or a service to protect the data.

4. The server can regenerate keys for different infrastructure components as needed.

5. As all keys are generated from a base secret stored at the key server any key can be
securely regenerated and recovered as long as this base secret can be retrieved.

6. Since we don’t need a database or a per–transaction connection to the key server
additional applications and transactions are easy to add to the system.

This last point is an important one in relation to mobile computing applications given the
exponential growth that can occur when a mobile commerce capability is introduced into an
enterprise. The comparative simplicity of the system vis-à-vis symmetric or PKI systems is
another benefit for mobile computing systems as querying a key server from a mobile device
could potentially slow a transaction down significantly.



Figure 3: Identity Based Encryption

Figure 4 illustrates how a secure email is sent using IBE. Assuming we have a sender User 1 who
sends a secure email to a recipient User 2, the latter’s email address being user2@company.com,
the following steps take place:


1. User 1 encrypts the email using User 2’s email address (user2@company.com) as the
public key.

2. When User 2 receives the message he/she contacts the key server. The key server
contacts a directory or other external authentication source to authenticate User 2’s
identity.

3. After authenticating User 2, the key server then returns his/her private key, with which
User 2 can decrypt the message. This private key can be used to decrypt all future
messages received by User 2.

Private keys only need to be generated once, upon initial receipt of an encrypted
message. All subsequent communications corresponding to the same public key can be
decrypted using the same private key, even if the user is offline. Also, because the public
key is generated using only User 2's email address, User 2 does not need to have
downloaded any software before User 1 can send him a secure message.

Figure 4: Sending an Email using Identity Based Encryption



4. Literature & Academic Research

The most significant papers on Identity Based Encryption are by Shamir [1] and Boneh and
Franklin [2]. In [1], Shamir proposed that a receiver’s public key be calculated mathematically
from their identity. The key server calculates the private key. The IBE algorithm removes the
need for public key queries or certificates. However, while Shamir constructed an Identity Based
Signature (IBS) scheme he was unable to construct an IBE scheme. In [2] Boneh and Franklin
solved this mathematical problem and constructed the first practical implementation of the IBE
system.

While Boneh and Franklin’s implementation is perhaps the most well known, there are in fact
multiple implementations of the IBE system. Baek, Newmarch, Safavi-Naini and Susilo [4] point
out that many IBE schemes are based on the Bilinear Diffie-Hellmann (BDH) assumption. BDH
is a computational hardness assumption that is used to prove the security of cryptographic
systems. Cha and Cheon have devised an IBS scheme based on bilinear pairing. Other schemes
similar to IBE include a Certificate-Based Encryption (CBE) scheme, where a user needs both a
private key and an up to date certificate from a CA, and the Public Key Encryption with
Keyword Search (PEKS) where the body of the encrypted data contains a keyword so that, for
example, an email gateway can test for this keyword without reading the rest of the message.

Gagné [5] describes Authenticated ID-Based Encryption where message authentication is
provided at no additional computational cost. In other words, the receiver verifies the identity of
the sender and whether or not the message has been tampered with, thus removing the need for
digital signatures when authentication is required. Thus, secure authenticated conversation is
possible.

Gagné [5] also cites the Hierarchical ID-Based Encryption (HIBE) scheme. One disadvantage of
IBE is that the private key generator (PKG) has a demanding task in a large network. With the
Hierarchical ID-Based Encryption Scheme, however, a hierarchy of PKGs is used. Under this
scheme, PKGs only compute private keys for entities immediately below them in the hierarchy.

Figure 5 illustrates a hierarchy of PKGs. In an IBE system each user is represented by a string
ID. In this diagram we see how, for example, the root PKG computes a private key for ID1 using
the make key formula, mk. In this system the user is no longer represented by a string ID but by
a tuple of IDs containing the IDs of the ancestors in the hierarchy. For example, in

Figure 5 the user in the third level of the hierarchy below the root is not represented by a string
ID3 but by a combination of strings ID1, ID2 and ID3.

Boneh, Goh and Boyen [6] present the HIBE scheme in more detail and cite its potential
application in forward-secure encryption which provides a guarantee that all messages encrypted
before a secret key is compromised remain secret. HIBE is also appropriate for broadcast


encryption schemes where data can be broadcast efficiently to a dynamic group of users
authorised to receive the data. Finally, Boneh, Goh and Boyen [6] outline the role HIBE can play
in encrypting to the future where a trusted server publishes the private key corresponding to a
particular day, thus enabling all messages encrypted for that day to be decrypted.

Boneh and Hamburg [7] propose a Generalized Identity Based and Broadcast Encryption
Scheme (GIBE) where different encryption properties can be combined using a product rule.
This enables the construction of encryption schemes with multiple properties. For example, a
multi-authority, forward-secure, broadcast encryption system can be derived using this product
rule. Boneh and Hamburg [7] also outline a spatial encryption system, a specific instance of
GIBE which enables the construction of encryption systems with specific properties.

Goyal [8] introduces the concept of Accountable Authority Identity Based Encryption (A-IBE)
which attempts to overcome the key escrow problem inherent in IBE. Simply put, a PKG has to
be completely trusted as it is able to compute the private key corresponding to any identity.
Goyal [8] cites arguments that, for this reason, IBE is still restricted to small closed groups where
a trusted central authority is available. On the other hand, under the scheme proposed by Goyal
[8], a user gets the decryption key from the PKG using a secure key generation protocol. Under
this scheme the PKG has no knowledge of the key the user obtained. Ho Au, Huang, Liu,
Susilo, Wong and Yang [9] extend the concept of A-IBE by having the PKG’s master secret key
retrieved automatically if more than one user secret key are released thus providing the user with
concrete proof of misbehaviour on the part of the PKG.



Root PKG

mk<ID1> mk<ID’1>

<ID1> <ID’1>

mk<ID1,ID2> mk<ID1,ID’2>

<ID1,ID2,> <ID1,ID’2,>

mk<ID1,ID2,ID3> mk<ID1,ID2,ID’3>

<ID1,ID2,ID3> <ID1,ID2,ID’3>

Figure 5: Hierarchy of Private Key Generators



5. Applications

Gagné [5] outlines several applications for IBE. These include:

 The previously discussed forward-secure encryption.

 The revocation of public keys whereby the current date can be included in the
construction of the public key, thus providing a preset expiration date.

 The management of user credentials where the inclusion of a clearance level in the public
key means that a receiver will only be able to decrypt the message if he/she has the
appropriate clearance level.

 Delegations of decryption keys whereby management can give subordinates private keys
corresponding to their responsibilities so that subordinates can only decrypt messages
which fall within their responsibilities.

Voltage Corporation’s White Paper on Email Security [10] outlines how IBE provides better
performance than its symmetric and asymmetric key management counterparts. With the former,
the need for a central server to manage each transaction means that the server gets busier the
more email users are added to the system and there is no offline capability. There is a similar lack
of offline capability with asymmetric key management systems. Moreover, the performance of
asymmetric key management systems is affected by the difficulties that can be encountered in
locating certificates and the administrative problems in validating these certificates. By contrast,
messages can be encrypted and decrypted using IBE even when offline. Ad-hoc communication
is also possible as no pre-enrolment of users is required. Penn and Sage [11] expand on these
advantages to explore how IBE is easier to integrate into other products and how better key
usage and management is facilitated.

IBE has other applications other than secure email. Voltage Corporation’s White Paper on
Secure Messaging for Financial Services [12] explains how financial services institutions can use
IBE to exchange sensitive information without a plug-in or software download. [13] argues how
IBE would seem to be the only practical means of providing security for Wireless Sensor
Networks (WSNs). In the research carried out by Oliveira, Aranha, Morais, Daguano, Lopez and
Dahab [13] an implementation of the Tate pairing, dubbed TinyTate, is introduced and the use
of IBE to solve the key distribution problem in WSNs is proposed.



6. Implementations of IBE

The main commercial player in the field of IBE is Voltage Security [14]. It offers products to
secure email and disks and provides key management systems using IBE as the encryption
standard. Voltage Security was founded in 2002 in California and has customers in diverse
industries including Kodak, ING Canada and Domino’s Pizza. Voltage Security was co-founded
by Dan Boneh, the co-author of the first practical implementation of IBE as outlined in Boneh
and Franklin’s paper [2]. Shamus Software’s MIRACL library [15] contains experimental
implementations of IBE. PerlMonks [16] have demonstrated how IBE can be implemented in
the Perl scripting language. WareSeeker [17] lists IBE freeware and shareware while NUI
Maynooth’s Cryptography Group [18] presents a Java implementation of IBE1. One Java
implementation of Cryptographic techniques is the BouncyCastle Crypto API [19]. However,
this does not contain an implementation of IBE. Sun also provide a Java Cryptography
Architecture (JCA) [20] which is a framework for using and extending cryptographic
functionality for the Java platform while the Java Cryptography Extension (JCE) [21] provides a
framework and implementations for encryption, key generation and key agreement, and Message
Authentication Code (MAC) algorithms. JCE also supports the Elliptic Curve Cryptography
(ECC) algorithm. IBE used a variant of Elliptic Curves so there is potential for code reuse or
modification here.

Aside from Voltage Security [14], the implementations cited are either freeware or shareware.

1
Note that this website is not available as of January 2009.



7. Open Problems & Future Work

Baek, Newmarch, Safavi-Naini and Susilo [4] outline the principal issue regarding IBE. The key
escrow problem occurs as the PKG issues private keys for users using its master secret key
which means that the PKG can decrypt or sign any message in the network. This is essentially a
violation of the non-repudiation property of digital signature schemes.2

Another issue with IBE is the revocation problem. Given that the essential property of IBE is
that users encrypt their data using, typically, their email address as the public key there is a
potential issue if the private key is compromised. In theory, this means that a user cannot use
their email address as a public key any longer. However, there are mechanisms to overcome this
as, for example, a time period can be attached to the string that is used as a public key.

As well as these issues, future work could include the further exploration of the use of IBE in
WSNs. Boyen, Dodis, Katz, Ostrovsky and Smith [22] outlines how biometric data can be used
for secure authentication. Biometrics and IBE would appear to be two technologies which can
offer synergy as conceivably, a user could provide biometric data such as a thumbprint and this
data may be used to form a public key.

The other key area of future work is the use of IBE in mobile computing and m-commerce.

2
Non-repudiation means that only an entity which possesses a signing key can create a valid signature.


9. Digital Signatures & Identity Based Signature Schemes

A digital signature is a digital code that can be attached to an electronically transmitted message
that uniquely identifies the sender. Like a written signature, the purpose of a digital signature is to
guarantee that the individual sending the message really is who he or she claims to be. A digital
signature scheme then is a method of using encryption to certify the source and integrity of a
particular electronic document. VeriSign [24] provide an overview of digital signatures.

The recipient of a digitally signed message can verify both that the message originated from the
person whose signature is attached and that the message has not been altered either intentionally
or accidentally since it was signed. Furthermore, secure digital signatures cannot be repudiated;
the signer of a document cannot later disown it by claiming the signature was forged.

Sender Receiver

1. Enter/Select Plaintext Message

2. Use Signature Algorithm to Encrypt Message with Private Key

3. Attach Digital Signature To Message

4. Send Message

5. Use Validation Algorithm to Verify Message Source with Public Key

6. Determine Validity of Signature

7. Read Message if Signature is Valid

Figure 6: A Typical Digital Signature Scheme

Digital signatures are generated by using public key signature algorithms. A private key encrypts
and generates the signature, and the corresponding public key must be used to decrypt and thus
validate the signature. This process is shown in the following illustration. Figure 6 illustrates the


operation of a typical digital signature scheme. The sender enters or selects a plaintext message a
signature algorithm encrypts the message using the private key. The digital signature is then
attached to the message which is then sent. On receipt of the message a validation algorithm is
used to verify the signature. If the signature is valid the message can then be read.

Figure 7: Creating a Digital Signature

Figure 7 shows how a digital signature is created. The first step involves creating a hash value or
message digest from the message by applying a hashing algorithm. The hash value is a fixed-size
result obtained by applying a mathematical function called the hashing algorithm to an arbitrary
amount of data. It typically consists of about 160 bits of binary data. Once the hash value is


computed it is then signed, using the signer's private key. Once the digital signature is computed
it is attached to the plaintext message.

Unverified Message

Apply Hashing Algorithm

Hash Value Obtained

Obtain Digital Signature & Public Key

Verify Hash Value Against Signature

Validation Bit Obtained Signature is Valid?

Validated Message

Figure 8: Verifying a Digital Signature

Figure 8 shows how a digital signature is verified. To verify a signature, both the message and the
signature are required. First, a hash value must be created from the message in the same way the
signature was created by applying the hashing algorithm. The signature and public key are then
retrieved and the hash value is then verified against the signature by using the public key of the
signer. If the hash value and the signature match, the message is the one the signer originally
signed and has not been tampered with. The message is thus validated.



There are many different hashing algorithms. However, regardless of the algorithm used hash
values have a number of common properties:

 The length of the hash value is determined by the type of algorithm used, and its length
does not vary with the size of the message. The most common hash value lengths are
either 128 or 160 bits.
 Every pair of non-identical messages translates into a completely different hash value,
even if the two messages differ only by a single bit. Using current technology, it is not
feasible to discover a pair of messages that translate to the same hash value without
breaking the hashing algorithm.
 The same hash value is produced each time a particular message is hashed using the same
algorithm.
 All hashing algorithms are one-way. Given a hash value, it is not possible to recover the
original message. In fact, none of the properties of the original message can be
determined given the hash value alone.

The principles of Identity Based Signature Schemes (IBS) are the same as that of IBE. The
private key is derived from the recipient’s identity and the receiver obtains the key for verifying
the signature from a key server. The operation is similar to other digital signature schemes such
as Figure 6.

IBE Schemes have existed for many years but often have lacked proofs as to their security.
However, as Libert and Quisquater [25] point out this is gradually improving. And Bellare,
Namprempre and Neven [26] provide proofs in the area of IBS. There are also several
implementations of IBS. For example, Cha Choon and Hee Cheon [27] outline an IBS Scheme
constructed using Gap Diffie-Hellman Groups.



11. Conclusion

Identity Based Cryptography is a promising solution for overcoming the issues associated with
symmetric and asymmetric key management schemes. While there are issues, the comparative
simplicity of its architecture makes IBE an attractive proposition for diverse computer systems
including mobile computing. Moreover, Network World [28] points how the significantly lower
the total cost of ownership of IBE systems is in comparison to a typical public key system.



References

[1] Adi Shamir, “Identity-based cryptosystems and signature schemes”, Advances in
Cryptology—Crypto 1984, Lecture Notes in Computer Science, vol. 196, Springer-Verlag, pp.
47-53, 1984.

[2] D. Boneh and M. Franklin , “Identity based encryption from the Weil pairing”,
SIAM J. of Computing, Vol. 32, No. 3, pp. 586-615, 2003.
Advances in Cryptology - Crypto 2001, Springer-Verlag, pp. 213-229, 2001.

[3] “The Voltage Identity Based Encryption Advantage”, http://www.voltage.com

[4] J Baek, J Newmarch, R Safavi-Naini and W. Susilo, “A Survey of Identity-Based
Cryptography”, School of Information Technology and Computer Science, University of
Wollongong, http://jan.netcomp.monash.edu.au/publications /auug—id—survey.pdf, pp. 1-10.

[5] M. Gagné, “Identity Based Encryption: A Survey”, RSA Laboratories Cryptobytes
Volume 6, No.1 — Spring 2003

[6] D Boneh, E. Goh and X. Boyen, “Hierarchical Identity Based Encryption with Constant Size
Ciphertext”, Advances in Cryptography - Eurocrypt 2005, pp. 440-456

[7] D. Boneh and M. Hamburg, “Generalized Identity-Based and Broadcast Encryption
Schemes”, AsiaCrypt 2008.

[8] V. Goyal, “Reducing Trust in the PKG in Identity Based Cryptosystems”,
Advances in Cryptology - Crypto 2007

[9] M. Ho Au, Q. Huang, J. K. Liu, W. Susilo, D. S. Wong and G. Yang,” Traceable and
Retrievable Identity-Based Encryption”, Proceedings of Applied Cryptography and Network
Security: 6th International Conference, ACNS 2008, New York, NY, USA, June 3-6, 2008

[10] “Email Security – The Identity-Based Encryption Advantage”, http://www.voltage.com

[11] “FORRESTER: Voltage Security Tries To Put The Spark Back Into Secure Email”,
Jonathan Penn with Adele Sage. June 28 2004, http://www.voltage.com

[12] “Secure Messaging for Financial Services: Conforming to GLBA Safeguards”,
http://www.voltage.com

[13] L. B. Oliveira, D. Aranha, E Morais, F. Daguano, J. Lopez and R. Dahab,” TinyTate:
Identity-Based Encryption for Sensor Networks”, Cryptology ePrint Archive: Report 2007/020

[14] Voltage Security Website, http://www.voltage.com

[15] Shamus Software Website, http://www.shamus.ie/


[16] “Identity Based Encryption using Pairings and Crypt::PBC”,
http://www.perlmonks.org/?node_id=589279

[17] WareSeeker, http://wareseeker.com/free-identity-based-encryption/

[18] Computer Security and Cryptography Group, NUI Maynooth,
http://www.crypto.cs.nuim.ie/

[19] Bouncy Castle Crypto API, http://www.bouncycastle.org/

[20] Java Cryptography Architecture API Specification & Reference
http://java.sun.com/j2se/1.4.2/docs/guide/security/CryptoSpec.html

[21] Java Cryptography Extension (JCE) Reference Guide
http://java.sun.com/j2se/1.5.0/docs/guide/security/jce/JCERefGuide.html
[
[22] X. Boyen, Y. Dodis, J. Katz, R. Ostrovsky and A. Smith, “Secure Remote Authentication
Using Biometric Data”, Advances in Cryptography – EuroCrypt 2005

[23] Y. Kawahara, T. Takagi, and E. Okamoto, “Efficient Implementation of Tate Pairing on a
Mobile Phone Using Java”, Computational Intelligence and Security 2007

[24] VeriSign Repository, http://www.verisign.com.au/repository/tutorial/digital/intro1.shtml

[25] B. Libert, J.J. Quisquater, “The Exact Security of an Identity Based Signature and its
Applications”, Cryptology ePrint Archive, Report 2004/102 (2004)

[26] M. Bellare, C. Namprempre and G. Neven, “Security Proofs for Identity-Based
Identification and Signature Schemes”, Advances in Cryptography - Eurocrypt 2004

[27] J. Cha Choon and J. Hee Cheon “An Identity-Based Signature from Gap Diffie-Hellman
Groups”, Public Key Cryptography — PKC 2003

[28] Network World Website, http://www.networkworld.com/news/2008/111708-identity-
based.html?page=1


An Overview of Identity Based Encryption

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a An Overview of Identity Based Encryption

Similar a An Overview of Identity Based Encryption (20)

Más de Vertoda System

Más de Vertoda System (6)

Último

Último (20)

An Overview of Identity Based Encryption