UNIDIRECTIONAL MULTI-USE PROXY RE-SIGNATURE PROCESS

Abstract

A “proxy re-signature system” provides various techniques for transforming a delegatee's signature on a message m into a delegator's on the same message m. Various embodiments of non-interactive re-signature generation processes are described. Various embodiments to aggregate part of signatures to reduce the size of re-signed signatures are also described. Various combinations of the proxy re-signature process and the re-signature conversion process result in an overall process that is unidirectional, multi-use, private, and non-interactive. As such, the proxy re-signature system is applicable for use with a wide range of applications.

Description

BACKGROUND

1. Technical Field

A “proxy re-signature system” provides a mechanism that allows secure proxy re-signatures, and in particular, various techniques for enabling secure, multi-use, unidirectional, and private proxy re-signatures in combination with various techniques for converting any secure proxy re-signature into one that is collusion-resistant with flexible temporary delegations without the need to involve a trusted third party.

2. Related Art

Conventionally, “proxy re-signature” techniques, as are well known to those skilled in the art, involve a cryptography technique in which a semi-trusted proxy acts as a translator between a delegatee (typically referred to as “Alice” or simply as “A”) and a delegator (typically referred to as “Bob” or simply as “B”). Such techniques are used to convert a signature (i.e., a “signing key”) from A into a signature from B on the same message.

However, for purposes of security, conventional proxy re-signature techniques ensure that the proxy does not actually learn the signing key of either Alice or Bob during the re-signature process, and cannot sign arbitrary messages on behalf of either Alice or Bob. In other words, in a conventional proxy re-signature scheme, a semi-trusted proxy is given some information which allows it to transform Alice's signature on a message m into Bob's signature on m, but the proxy cannot, on its own, generate signatures for either Alice or Bob. Note that in some unsecure signature schemes, an adversary may fake a signature by using the signatures he/she already has without knowing the signing key.

There are a number of properties that have been identified as desirable for use in various types of conventional proxy re-signature schemes. For example, these properties include the following:

• • 1. Directionality: In a unidirectional scheme, a re-signature key allows the proxy to transform A's signature to B's but not vice versa. Conversely, in a bidirectional scheme, on the other hand, the re-signature key allows the proxy to transform A's signature to B's as well as B's signature to A's.
  • 2. Uses: In a multi-use scheme, a transformed signature can be re-transformed again. Conversely, in a single-use scheme, the proxy can transform only signatures that have not already been transformed.
  • 3. Private vs. Public Proxy: The re-signature key can be kept as a secret in a private proxy scheme, but can be recomputed by observing the proxy passively in a public proxy scheme.
  • 4. Transparent: In a transparent scheme, a signature transformed by a proxy is computationally indistinguishable from a signature on the same message signed by the delegator.
  • 5. Key-Optimal: In a key-optimal scheme, a user is required to protect and store only a small constant amount of secrets no matter how many signature delegations the user gives or accepts.
  • 6. Non-interactive: The delegatee is not required to participate in delegation process.
  • 7. Non-Transitive: A re-signing right cannot be re-delegated by the proxy alone.
  • 8. Temporary: A re-signing right is temporary. Typically, this is accomplished by revoking the right after some temporary period or expiring the right.

Many applications have been proposed for using proxy re-signatures, including, for example, providing a proof for a path that has been taken; managing group signatures; simplifying certificate management; simplifying key management; Digital Rights Management (DRM) interoperable systems; privacy for public transportation; “fair exchange” proxy re-signature based contract signing protocols; etc.

Proxy re-signatures were originally introduced 1998 as a bidirectional, multi-use, and public proxy scheme. This original proxy re-signature required the calculation of k exponentiations in both the delegatee's signature generation and the proxy's transformation, where k is a security parameter input, which is suggested to be at least 160 bits for discrete logarithm-based schemes. Unfortunately, this original proxy re-signature scheme is considered to be inefficient, and, as such, it is generally considered to be unsuitable for many practical applications.

More recent proxy re-signature schemes have been based on bilinear maps, and are generally considered to be more suitable for various practical applications. For example, one such proxy re-signature scheme is both multi-use and bidirectional, while another such scheme is single-use and unidirectional. Both schemes are more efficient than the original proxy re-signature scheme. However, these proxy re-signature have several disadvantages that generally limit their utility for various applications.

For example, typical proxy re-signature schemes are not proven to be secure, unidirectional, and private. One proxy re-signature scheme is proven secure and unidirectional, but it is of public proxy. Unfortunately, many applications such as contract signing protocols require the underlying proxy re-signature scheme to be a private proxy. Further, none of the aforementioned proxy re-signature schemes is both unidirectional and multi-use simultaneously. Unfortunately, applications such as the proof of a taken path mentioned require the underlying proxy re-signature scheme to be simultaneously unidirectional and multi-use.

SUMMARY

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

In general, a “proxy re-signature system,” as described herein, provides a multi-use unidirectional proxy re-signature process, denoted as S_mu, where a signature can be transformed in only one direction and can be re-transformed multiple times. In various embodiments, the proxy re-signature system provides either secure random oracle based re-signatures or secure re-signatures that do not rely on random oracles.

More specifically, in various embodiments, the proxy re-signature system provides various techniques for transforming a delegatee's signature on a message m into a delegator's on message m. In other words, assuming Bob's permission, the re-signature capability provided by the proxy re-signature system allows a message signed by Alice to be automatically re-signed using Bob's signature. Various combinations of the proxy re-signature techniques enabled by the proxy re-signature system provide an overall process that is unidirectional, multi-use, private, and non-interactive. As such, the proxy re-signature system is applicable for use with a wide range of applications.

The proxy re-signature system takes one of three basic forms, with various embodiments and modifications of each of the three basic forms. However, one important feature of all of these basic forms, is that the proxy re-signature system is collusion-resistant. In other words, the delegator (or delegatee) cannot collude with the proxy to produce the signatures that they have no privilege or are not authorized to produce. This property is advantageous since, in some applications, the secret keys of encryption and signature are the same, and, if this property is held, Alice can delegate signing rights to either the proxy or to Bob while keeping the decryption rights.

For example, one of the three basic forms of the proxy re-signature system provides various non-interactive message re-signature techniques under a random oracle model. In this first basic form of the proxy re-signature system, only the delegator, i.e., Bob, is required use his secret key with the public key of the delegatee, i.e., Alice, to generate the re-signature key and delegates the re-signature key to the proxy to transform the signature of the delegatee on some message to the signature of the delegator on that same message.

A second basic form of the proxy re-signature system provides various non-interactive message re-signature techniques under a random oracle model. In this second basic form of the proxy re-signature system, only the delegator (e.g., Bob) is required to use his secret key to generate the re-signature key to transform the delegatee's signature on some message to the delegator's on that same message, while only a public key is required from the delegatee (e.g., Alice). In this case, assuming Bob's permission, Alice's signature is transformed on the message into Bob's signature using Bob's private key and Alice's public key.

Finally, a third basic form of the proxy re-signature system provides various non-interactive message re-signature techniques under the standard model (i.e., no random oracles). In this third basic form of the proxy re-signature system, the re-signature key is generated in a similar way as the other two basic forms: delegator Bob uses his private key and the public key of delegatee Alice to generate the re-signature key and delegates the re-signature key to the proxy to transform the signature of the delegatee (i.e., Alice) on some message to the signature of the delegator (i.e., Bob) on that same message.

Note that as is well known to those skilled in the art of cryptography, a “random oracle” is a theoretical black box (typically implemented as a mathematical algorithm) that responds to every query with a random response chosen uniformly from its output domain, except that for any specific query, it responds the same way every time it receives that query. In other words, a random oracle is a mathematical function mapping every possible query to a random response from its output domain.

In view of the above summary, it is clear that the proxy re-signature system described herein provides various unique techniques for automatically and securely re-signing messages by transforming the signature of a delegatee to that of a delegator using collusion resistant re-signature processes. In addition to the just described benefits, other advantages of the proxy re-signature system will become apparent from the detailed description that follows hereinafter when taken in conjunction with the accompanying drawing figures.

DESCRIPTION OF THE DRAWINGS

The specific features, aspects, and advantages of the claimed subject matter will become better understood with regard to the following description, appended claims, and accompanying drawings where:

FIG. 1 provides an exemplary architectural flow diagram that illustrates program modules for implementing various embodiments of a “proxy re-signature system” as described herein.

FIG. 2 provides a general system flow diagram that illustrates exemplary methods for implementing a random oracle model embodiment of the proxy re-signature system, as described herein.

FIG. 3 provides a general system flow diagram that illustrates exemplary methods for implementing an alternative random oracle embodiment of the proxy re-signature system, as described herein.

FIG. 4 provides a general system flow diagram that illustrates exemplary methods for implementing a standard model embodiment of the proxy re-signature system, as described herein.

FIG. 5 is a general system diagram depicting a simplified general-purpose computing device having simplified computing and I/O capabilities for use in implementing various embodiments of the proxy re-signature system, as described herein.

DETAILED DESCRIPTION OF THE EMBODIMENTS

In the following description of the embodiments of the claimed subject matter, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration specific embodiments in which the claimed subject matter may be practiced. It should be understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the presently claimed subject matter.

1.0 Introduction

The first known proxy re-signature scheme in was introduced 1998, and was a bidirectional, multi-use, and public proxy scheme. The definition for security in proxy re-signature schemes was first formalized in a well known publication in 2005 entitled “Proxy re-signatures: new definitions, algorithms, and applications,” by G. Ateniese, S. and Hohenberger, in Proceedings of the 12th ACM Conference on Computer and Communications Security (Alexandria, Va., Nov. 7-11, 2005), ACM CCS 2005, pages 310-319.

In general, Ateniese and Hohenberger formalized the definition of security for a proxy re-signature (referred to herein as the “AH model”), and then proposed two proxy re-signature schemes of proven security based on bilinear maps and more applications of proxy re-signatures. The AH model describes both single-use unidirectional proxy re-signatures, denoted as “S_uni,” and multi-use bidirectional proxy re-signatures, denoted as “S_bi.” In conventional unidirectional proxy re-signature schemes, there are two types of signatures: the first-level signature produced only by the signer, and the second-level signature produced by either the signer or collaboration between the signer's proxy and a delegatee. However, in conventional bidirectional proxy re-signature schemes, there is only one type of signature.

The AH model generally covers two types of forgeries for multi-use bidirectional proxy re-signatures (i.e., S_bi schemes): (1) an outsider who is neither the proxy nor one of the delegation parties aims to produce signatures on behalf of either delegation party; and (2) the proxy aims to produce signatures on behalf of either delegation party. In contrast, for single-use unidirectional proxy re-signatures (i.e, S_uni schemes), the AH model includes the two types of forgeries noted above with respect to multi-use bidirectional proxy re-signatures, in addition to two additional types of forgeries, including: (3) the delegator colludes with the proxy to produce signatures on behalf of the delegatee; and (4) the delegatee colludes with the proxy to produce the first-level signatures.

Unfortunately, for unidirectional proxy re-signatures, the AH model does not cover all types of forgeries. For example, in a unidirectional proxy re-signature, the delegatee can attempt a forgery by fraudulently producing second-level signatures on behalf of the delegator. This type of forgery is not covered by the AH model, thereby making the AH model subject to attacks based on vulnerabilities relating to such forgery types.

Consequently, in various embodiments, a “proxy re-signature system,” as described herein provides a modified security model for proxy re-signatures that protects against additional forgery cases not covered by conventional proxy re-signature schemes. For example, the conventional AH model cannot cover attacks on unidirectional schemes in which the delegatee may attempt to produce a second-level signature on an arbitrary message on behalf of the delegator. This modified security model is referred to herein as the “proxy re-signature system security model.”

More specifically, given the following transformation path for a message: Alice→Proxy→Bob, Alice may fraudulently attempt to produce a second-level signature on the message on behalf of Bob. In this case, production of a second-level signature by Alice on behalf of Bob is fraudulent since Bob has delegated his signing rights to Proxy but not to Alice. While conventional proxy re-signature schemes are vulnerable to such attacks, the proxy re-signature system described herein provides an improved security model that is resistant to such attacks in the case of unidirectional proxy re-signatures.

In addition, in various embodiments, the proxy re-signature system provides a proven secure, multi-use, non-interactive, and unidirectional proxy re-signature scheme, denoted as “S_mu”. In particular, a random oracle based security proof for S_mu is provided based on various assumptions, including the well known “Computational Diffie-Hellman” (CDH) assumption and the well known “weaker Computational Diffie-Hellman” (wCDH) assumption. In related embodiments, the S_mu proxy re-signature process is further modified to produce an additional proxy re-signature process, denoted as S_mu*,” which is proved to be secure without relying on random oracles. The underlying assumptions used in proving the security of the S_mu * proxy re-signature process include the aforementioned CDH assumption and the well known “Extended Computational Diffie-Hellman” (ECDH) assumption.

Note that as is well known to those skilled in the art of cryptography, a “random oracle” is a theoretical black box (typically implemented as a mathematical algorithm) that responds to every query with a random response chosen uniformly from its output domain, except that for any specific query, it responds the same way every time it receives that query. In other words, a random oracle is a mathematical function mapping every possible query to a random response from its output domain.

1.1 System Overview:

As noted above, the proxy re-signature system provides various techniques for automatically and securely re-signing messages by transforming the signature of a delegatee to that of a delegator using various collusion resistant re-signature processes. The processes summarized above are illustrated by the general system diagram of FIG. 1. In particular, the system diagram of FIG. 1 illustrates the interrelationships between program modules for implementing various embodiments of the proxy re-signature system, as described herein. Furthermore, while the system diagram of FIG. 1 illustrates a high-level view of various embodiments of the proxy re-signature system, FIG. 1 is not intended to provide an exhaustive or complete illustration of every possible embodiment of the proxy re-signature system as described throughout this document.

In addition, it should be noted that any boxes and interconnections between boxes that are represented by broken or dashed lines in FIG. 1 represent alternate embodiments of the proxy re-signature system described herein, and that any or all of these alternate embodiments, as described below, may be used in combination with other alternate embodiments that are described throughout this document.

In general, as illustrated by FIG. 1, the proxy re-signature system consists of three major parts: a signer 102, a signature verifier 104, and re-signature proxy 100. The signer 102 signs messages with its private key. The signer 102 can be a delegatee, referred to herein as Alice 105, or a delegator, referred to herein as Bob 110. The signature verifier 104 verifies authenticity of signed messages. The re-signature proxy 100 transforms the delegatee's signature on a message to a delegator's signature on that same message. It begins operation by the delegator Bob 110 to use his private key and the delegate Alice's 105 public key to generate a re-signature key, and then to communicate with the proxy to delegate the re-signature key to the proxy to transform Alice's signature on a message to Bob's signature on that same message.

In various embodiments, as described in further detail in Section 3, the transformation from Alice's 105 signature to Bob's 110 signature depends only on the re-signature key, and does not directly require one or more of Alice's and/or Bob's private keys. In re-signature key generation module 175, delegator Bob 110 uses his private key and delegatee Alice's 105 public key to generate the re-signature key and delegates the re-signature key to proxy 100.

In general, as described with respect to various embodiments of a “KeyGen” algorithm in Section 3.1, Section 3.4 and Section 3.5, the signer 102 first uses a key pair generation module 125 to generate a pair of keys (public key and private key), pk=g^a and sk=a, from the input of a security parameter, 1^k, which is used to select a random number a ε Z_q* using a conventional discrete logarithm-based key generation algorithm. Note that in some embodiments, the resulting key pair is used for a long time, while in other embodiments, the resulting key pair is temporary, and will expire after some predetermined period of time, or after one or more uses, as desired, in order to provide enhanced security.

Next, assuming that an unsigned message 120 is received by Alice 105, a message signing module 130 is used to securely sign the unsigned message 120 with Alice's signature. Note that depending upon the particular form of the proxy re-signature system (i.e., random-oracle model, alternative random-oracle model, or standard model, as described in further detail below), the signature is determined in different ways, which require either private or public keys. Specifically, the various forms of the signature produced on the message 120 by the message signing module 130 are described with respect to various embodiments of a “Sign” algorithm in Section 3.1, Section 3.4 and Section 3.5. Further, it should be noted that each signature can be either an owner-type signature, or a non-owner-type signature. See Section 2.1.2 for a discussion of signature types.

Next in the signature verifier 104, a signature verification module 155 evaluates signed messages. This signed message can be a message 140 signed directly by the signer, such as delegatee Alice 105 or delegator Bob 110, or a re-signed message 190 provided by the re-signature proxy 100. and the signature verification module 155 determines 160 whether that signature is valid. Note that depending upon the signature type and the particular embodiment of the proxy re-signature system, different signature validation techniques are required. For example, several of the various signature validation embodiments are described with respect to various embodiments of a “Verify” algorithm in Section 3.1, Section 3.4 and Section 3.5. In any case, if the signature is determined to be invalid 160, then a forgery alert module 165 terminates the verification process. Note that, if desired, the forgery alert module 165 can perform additional actions such as notifying the signer and/or one or more third parties of the attempted forgery, etc.

In one embodiment, the re-signature proxy 100 consists of three modules: the re-signature key generation module 175, the optional signature verifier 104, and re-signature module 180. In the re-signature key generation module 175 delegator Bob 110 uses his private key and delegatee Alice's 105 public key to generate a re-signature key using a “ReKey” algorithm, and then delegates this re-signature key to proxy 100. More specifically, in various embodiments, as described with respect to various embodiments of a “ReKey” algorithm in Section 3.1, Section 3.4 and Section 3.5, the re-signature key generation module 175 constructs the re-signature key non-interactively using various combinations of Alice's 105 public key and Bob's 100 private key.

For a message 170 signed by Alice 105, the signature verifier 104 inside the re-signature proxy 100 can optionally verify Alice's signature on the message before passing it to the re-signature module 180. If Alice's 105 signature is determined 160 to be invalid, forgery alert module 165 inside the signature verifier 104 terminates the re-signature process, and may send alert relevant parties of the forgery. However, assuming that the signature verifier 104 determines 160 that the signature on the message is valid, the re-signature module 180 then acts to transform Alice's 105 signature on the signed message 170 into Bob's 110 signature, resulting in message 190 signed by Bob. Note that Alice's 105 signed message 170 can be a message 140 signed directly by Alice or re-signed by a proxy to transform somebody else's signature into Alice's signature on a message. Again, depending upon the signature type and the particular embodiment of the proxy re-signature system, different signature transformation techniques are required. For example, several of the various signature transformation embodiments are described with respect to various embodiments of a “ReSign” algorithm in Section 3.1, Section 3.4 and Section 3.5.

Next, having transformed Alice's 105 signature 170 on a message 120 into Bob's 110 signature on that message, the re-signature proxy 100 outputs the re-signed message 190 for use as desired.

Finally, it should be noted that having transformed Alice's 105 signature 170 on a message 120 into Bob's 110 signature on that message, the resulting message 190, having Bob's signature, can be processed to transform Bob's signature to that of another party. For example, in this case, Bob 110 would act as the delegatee with respect to the signed message 190. That message 190 would then be processed in the manner described above with respect to message 140 or 170 to transform Bob's signature to that of some third party delegator.

2.0 General Definitions and Considerations

The following paragraphs describe various considerations, definitions, and proofs used to provide a detailed description of the proxy re-signature system.

2.1 Unidirectional Proxy Re-Signature (Definition 1)

A unidirectional proxy re-signature process S consists of the following five random algorithms: KeyGen, ReKey, Sign, ReSign, and Verify where:

• • 1. KeyGen: The KeyGen algorithm provides conventional random generation of signature keys. Note that such techniques are well known to those skilled in the art, and will not be described in detail herein.
  • 2. Sign: The Sign algorithm provides conventional message signing techniques for attaching a signature to a message. Note that such techniques are well known to those skilled in the art, and will not be described in detail herein.
  • 3. Verify: The Verify algorithm provides conventional signature verification techniques. Note that such techniques are well known to those skilled in the art, and will not be described in detail herein.
  • 4. ReKey: The ReKey algorithm takes as input delegatee Alice's key pair (pk_A,sk_A), where pk_A is Alice's public key and sk_A is Alice's private or secure key, and delegator Bob's key pair (pk_B,sk_B), where pk_B is Bob's public key and sk_B is Bob's private or secure key. Note that in various embodiments, Alice's private key, sk_A is optional. Then, given the input of (pk_A,sk_A) and (pk_B,sk_B), the ReKey algorithm returns a re-signing key “rk_A→B” for the proxy. In other words, the ReKey algorithm can be denoted as illustrated by Equation 1, where:

rk_A→B←ReKey(pk_A,sk_A,pk_B,sk_B)   Equation 1

• • 5. ReSign: The ReSign algorithm takes as input a re-signature key rk_A→B and a signature σ_A (from Alice) on a message m corresponding to pk_A, and returns the signature σ_B (from Bob) on the same message m corresponding to pk_B as long as Alice's signature, σ_A, can be verified for the message m using Alice's private key pk_A, (i.e., as long as Verify(pk_A,m,σ_A)=1). If Alice's signature cannot be verified, then the ReSign algorithm returns a failure case denoted by “⊥” (i.e., message m will not be resigned using Bob's signature, σ_B). In other words, the ReSign algorithm can be denoted as illustrated by Equation 2, where:

σ_B←ReSign(rk_A→B,pk_A,m,σ_A)   Equation 2

2.1.1 Correctness

In general, the idea of “correctness” is a conventional concept for determining whether a proxy re-signature is correct. In particular, for any message m in the message space and any two key pairs (pk_A,sk_A) and (pk_B,sk_B), let σ_A be a signature on message m corresponding to pk_A either from Sign or ReSign (see Section 2.1) Then, in order to guarantee that all signatures produced by either Sign or ReSign pass verification for correctness, the following two equations must both hold:

Verify(pk_A,m,σ_A)=1   Equation 3

Verify(pk_B,m,ReSign(rk_A→B,pk_A,m,σ_A))=1   Equation 4

2.1.2 Types of Signatures

In conventional unidirectional proxy re-signature schemes, a signature may manifest in two types: the owner-type (also conventionally referred to as the “first-level” signature) and the non-owner-type (also conventionally referred to as the “second-level” signature). An owner-type signature can be computed only by the owner of the secret key, while a non-owner-type signature can be computed not only by the owner of the secret key, but also by collaboration between his proxy and delegatee.

2.2 Security of Unidirectional Proxy Re-Signature

In general, the proxy re-signature system provides a security model that improves over conventional proxy re-signature techniques by ensuring that various forgery cases that were unprotected using conventional techniques are prevented by the improved security model of the proxy re-signature system. In other words, the security model of the proxy re-signature system provides improved delegator security for unidirectional proxy re-signatures. Specifically, the improved security model ensures that a signature on a particular message cannot be modified to become another signature on the same message.

2.2.1 External Security

External security deals with “adversaries” (e.g., those who are attempting to perpetrate a forgery) other than the proxy and any delegation parties. In general, a unidirectional proxy re-signature scheme has external security if and only if for security parameter k, any non-zero n ε poly(k), and all probabilistic polynomial time (PPT) algorithms A, the following probability is negligible:

Pr[{pk_i,sk_i}←KeyGen(1^k)}_iε[1,n],

(t,m,σ)←A^{Osign(•,•),Oresign(•,•,•,•)}({pk_i}_iε[1,n]):

Verify(pk_t,m,σ)=1(t,m) ∉ Q]  Equation 5

where oracle, O_sign, takes as input a public key pk_i and a message m ε M, and produces an output Sign(sk_i,m); oracle “O_resign” takes as input two distinct public keys pk_i and pk_j, a message m, and a signature σ, and produces an output ReSign(ReKey(pk_i,sk_i,pk_j,sk_i),pk_i,m,σ); and Q denotes the set of (index,message) pairs (i,m) that A (i.e., Alice) obtains a signature on an message m under the public key pk_i by querying O_sign on (pk_i,m) or querying O_resign on (•,pk_i,m,•)

2.2.2 Internal Security

Internal security protects a user from inside adversaries who can be any parties, i.e., the proxy, the delegatee, and the delegator, in a proxy re-signature. Internal security can be classified into the following three types:

Limited Proxy: In the case of a limited proxy, the adversary is considered to be user A (i.e., Alice). The proxy re-signature system must guarantee that the proxy cannot produce signatures on behalf of either the delegator or the delegatee except the signatures produced by the delegatee and delegated to the proxy to re-sign. Internal security in this case is very similar to the external security described above, except that A queries a rekey oracle O_rekey instead of a re-signing oracle O_resign. A unidirectional proxy re-signature scheme is said to have limited proxy security if and only if for security parameter k, any non-zero n ε poly(k), and all PPT algorithms A, the following probability is negligible:

Pr[{pk_i,sk_i}←KeyGen(1^k)}_iε[1,n],

(t,m,σ)←A^{Osign(•,•),Orekey(•, •)}({pk_i}_iε[1,n]):

Verify(pk_i,m,σ)=1(t,m) ∉ Q],   Equation 6

where O_sign is the same as those in external security, oracle O_rekey takes as input two distinct indices 1≦i,j≦n and returns the output of ReKey(pk_i,sk_i,pk_j,sk_j); and Q denotes the set of (index,message) tuples (i,m) that A obtained a signature on m under public key pk_t or one of its delegatees' keys by querying oracle O_sign.

Delegatee Security: In the case of delegatee security, it is assumed that the proxy and delegator may collude with each other to perpetrate a forgery. Thus, delegatee security guarantees that any attempted collusion between the proxy and delegator cannot produce any unauthorized signatures on behalf of the delegatee. A unidirectional proxy re-signature scheme is said to have delegatee security if and only if for security parameter k, any non-zero n ε poly(k), and all PPT algorithms A, the following probability is negligible:

Pr[{pk_i,sk_i}←KeyGen(1^k)}_iε[0,n],

(m,σ)←A^{Osign(0,•),Orekey(ω,Λ)}(pk₀,{pk_i,sk_i}_iε[1,n]):

Verify(pk₀,m,σ)=1(0,m) ∉ Q],   Equation 7

where index 0 denotes the delegatee, Λ≠0, and Q is the set of pairs (0,m) that A obtains a signature by querying oracle O_sign on (0,m).

Delegator Security: There are several considerations with respect to delegator security. As such, several terms are first defined before describing delegator security concerns:

• • 1. Delegation Chain: If user A delegates his signing rights to user B via a proxy P, then both user A and user B are said to be in a delegation chain, denoted as (B,A).
  • 2. Delegation Predecessor: User B is called user A's delegation predecessor in the case that user A delegates his signing rights to user B.
  • 3. Delegation Pair: The combination of the proxy and a user, either the delegatee B or the delegator A, is called a delegation pair. Therefore, user A and proxy P is a delegation pair. Similarly, user B and proxy P are also a delegation pair.

If user A delegates his signing rights to user B via a proxy P, and user B delegates his signing rights to user C via a proxy P′, then user A and user C are said to be in a delegation chain too. User C is also called user A's delegation predecessor. In this case, users A,B,C are in a delegation chain (C,B,A). The delegation chains (B,A) and (C,B) are delegation subchains of the delegation chain (C,B,A). A delegation chain is also its own subchain. The ending user of a delegation subchain is called the terminal of that delegation subchain. For example, user A is the terminal of the delegation subchain (C,B,A). If two users A and B are in a delegation chain and B is A's delegation predecessor, then B's signature can be transformed by a proxy or proxies into A's signature.

In terms of delegator security, there are two cases in which the proxy and the delegatee may collude with each other to perpetrate a forgery. These two cases are described in the following paragraphs.

• • 1. All Proxies and Users (APU): In this case, all the proxies and delegation predecessors in every delegation subchain of which a target user is the terminal are considered to be malicious. The goal of this security is to guarantee that collusion among all these proxies and the delegation predecessors cannot produce any owner-type signatures on behalf of the target user. Note that if the owner-type signature and the non-owner-type signature are of the same form, then there is no such security. A unidirectional proxy re-signature scheme is said to have APU security if and only if for security parameter k, any non-zero n ε poly(k), and all PPT algorithms A, the following probability is negligible:

Pr[{pk_i,sk_i}←KeyGen(1^k)}_iε[0,n],

(m,σ)←A^{Osign(•,•),Orekey(•,•)}:

Verify(pk₀,m,σ)=1(0,m) ∉ Q],   Equation 8

• • • where index 0 denotes the target user (delegator), σ is an owner-type signature, and Q is the set of pairs (0,m) that A obtains a signature by querying oracle O_sign on (0,m). Note that, by working together, all the proxies and all the delegation predecessors in a delegation subchain of which a target user is the terminal can always produce the target user's non-owner-type signatures since the target user (delegator) delegates his signing rights to his delegation predecessor(s) via one or more proxies.
  • 2. Not all Proxies and Users (NAPU): In this case, for every delegation subchain of which a target user is the terminal, if there is a corrupted delegation predecessor, then there is at least one uncorrupted delegation pair between the corrupted user and the target user. An uncorrupted delegation pair can be the target user and his proxy. Thus, this security guarantees that collusion among all the proxies and all the delegation predecessors except one delegation pair between corrupted users and the target user in every delegation subchain of which the target user is the terminal cannot produce any signatures, either owner-type or non-owner-type, on behalf of the target user. NAPU security will exist for a unidirectional proxy re-signature scheme if and only if for security parameter k, any non-zero n ε poly(k), and all PPT algorithms A, the following probability is negligible:

Pr[{pk_i,sk_i}←KeyGen(1^k)}_iε[0,n],

(m,σ)←A^{Okey(•),Osign(•,•),Orekey(•,•),O}_resign^{(•,•,•,•)}

(pk₀,{pk_i}_iε[1,n]): Verify(pk₀,m,σ)=1m ∉ Q],   Equation 8

• • • where index 0 denotes the target user (delegator), the key generation oracle O_key(•) takes i (i ε [1,n]) as input, and outputs the secret key sk_i corresponding to pk_i, and Q is the set of messages m that A obtains a signature by querying oracle O_sign on (0,m), and a signature by querying oracle O_resign on (pk_i,pk_j,m,•), where pk_i or pk_j is in the uncorrupted delegation pair {circumflex over (P)}_d which is described below. Furthermore, there are two constraints on oracle O_key(•) and oracle O_rekey(•,•). As mentioned above, there exists at least one uncorrupted delegation pair {circumflex over (P)}_d between corrupted users and the target user in every delegation subchain of which the target user is the terminal. Thus, the first constraint is that the user in the uncorrupted delegation pair {circumflex over (P)}_d cannot be taken as an input to O_key(•). The second constraint is that the user in {circumflex over (P)}_d and the user who forms a delegation relationship with the user and the proxy in the delegation pair {circumflex over (P)}_d cannot be taken as an input to O_rekey(•,•). The combination of these two constraints does not allow the input to O_rekey(•,•) to form a delegation subchain ending with the target user. Otherwise by working together they can produce the target user's non-owner-type signatures, which is the goal of proxy re-signature. Note that the aims of the adversary in the APU security and the NAPU security are different.

2.3 Bilinear Groups

Conventional bilinear maps and bilinear map groups are briefly reviewed in the following paragraphs for purposes of explanation. However, it should be noted that bilinear maps and bilinear map groups, as such, these concepts will not be discussed in detail. In particular, bilinear maps and bilinear map groups can be described in terms of the following definitions:

• • 1. G and G_T are two (multiplicative) cyclic groups of prime order q;
  • 2. g is a generator of G;
  • 3. e is a bilinear map, e: G×G→G_T.

Let G and G_T be two groups as above. Then, an admissible bilinear map is a map e: G×G→G_T with the following properties:

• • 1. Bilinearity: For all P,Q,R ε G, e(P·Q,R)=e(P,R)·e(Q,R) and e(P,Q·R)=e(P,Q)·e(P,R).
  • 2. Non-degeneracy: If e(P,Q)=1 for all Q ε G, then P=O, where O is a point at infinity.

G is said to be a bilinear group if the group action in G can be computed efficiently and there exists a group G_T and an efficiently computable bilinear map as above. The term “BSetup” is used to denote an algorithm that, given an input of security parameter, 1^k, outputs parameters for a bilinear map as (q,g,G,G_T,e), where q ε Θ(2^k).

2.4 Complexity Assumptions

The security of the various embodiments of the proxy re-signature system is based on the Computational Diffie-Hellman (CDH) assumption, the Strong Computational Diffie-Hellman (wCDH) assumption, and the Extended Computational Diffie-Hellman (ECDH) assumption.

2.4.1 CDH Problem

The CDH problem in a finite cyclic group G with prime order q is as follows: Given g, g^a, g^b for some a, b ε Z_q*, compute g^ab. An algorithm A has an advantage ε in solving the CDH problem if:

Pr[A(g,g^a,g^b)=g^ab]≧ε,   Equation 9

where the probability is over random choices of a,b in Z_q*, a random choice of g ε G*, and the random bits of A.

CDH Assumption (Definition 2): The ε-CDH assumption is true if no PPT algorithm has an advantage of at least ε in solving the CDH problem.

2.4.2 wCDH Problem:

The wCDH problem in a finite cyclic group G with prime order q is as follows: Given g,g^a,g^b,g^c for some a,b,c ε Z_q*, compute g^ab/c. An algorithm A has advantage ε in solving wCDH problem if:

Pr[A(g,g^a,g^b,g^c)=g^ab/c]≧ε,   Equation 10

where the probability is over random choices of a,b,c in Z_q*, a random choice of g ε G*, and the random bits of A.

wCDH Assumption (Definition 3): The ε-wCDH assumption is true if no PPT algorithm has an advantage of at least ε in solving the wCDH problem.

Note that the wCDH assumption is a weaker version of the CDH assumption. If c=1, then it can be easily seen that the wCDH assumption is equivalent to the CDH assumption. Therefore, if the wCDH problem can be solved, than the CDH problem can also be solved.

2.4.3 ECDH Problem:

The ECDH problem in a finite cyclic group G with prime order q is as follows: Given g,g^a,g^b,g^c for some a,b,c ε Z_q*, compute g^ab/c. An algorithm A has advantage ε in solving ECDH problem if:

Pr[A(g,g^a,g^b,g^c,g^b/c)=g^ab/c]≧ε,   Equation 11

where the probability is over random choices of a,b,c in Z_q*, a random choice of g ε G*, and the random bits of A.

ECDH Assumption (Definition 4): The ε-ECDH assumption is true if no PPT algorithm has an advantage of at least ε in solving the ECDH problem.

2.5 A Conventional Short Signature Scheme

A conventional short signature scheme for securely signing messages was proposed by authors Boneh, Lynn, and Shacham in two well known publications entitled:

• • 1. “Short signatures from the Weil pairing” by D. Boneh, B. Lynn, and H. Shacham, in ASIACRYPT 2001, volume 2248 of LNCS, pages 514-532, 2001.
  • 2. “Short signatures from the Weil pairing” by D. Boneh, B. Lynn, and H. Shacham, in J. Cryptol. 17, 4 (September 2004), 297-319.

In general, the authors of these two publications introduced a “short signature” scheme for use in secure signature applications. This short signature scheme is referred to herein as the “BLS” scheme. The public parameters of the BLS scheme are (q,g,G,G_T,e), where (q,g,G,G_T,e)←BSetup(1^k), and H is a cryptographic hash function: {0,1}*→G.

The BLS scheme generally makes use of three basic algorithms, including a KeyGen algorithm, a Sign, and a Verify algorithm, where:

• • 1. KeyGen: The BLS-based KeyGen algorithm picks a random x from Z_q*, and computes y=g^x. The pubic key is y ε G and the private key is x.
  • 2. Sign: The BLS-based Sign algorithm uses a key x and a message m ε [0,1}*, to generate a signature σ=H(m)^x. In other words, the BLS-based Sign algorithm can be denoted as illustrated by Equation 13, where:

σ←BLS.Sign(x,m)   Equation 13

• • 3. Verify: The BLS-based Verify algorithm Given a public key y ε G, a message m ε {0,1}*, and a signature σ, outputs 1 if e(y,H(m))=e(g,σ), or 0 otherwise. In other words, the BLS-based Verify algorithm can be denoted as illustrated by Equation 14, where:

BLS.Ver(σ,y,m)   Equation 14

Theorem 1: If the CDH assumption is true for G, the BLS scheme is secure under adaptive chosen-message attacks in the random oracle model.

2.6 Modified Short Signature Process

In various embodiments, the proxy re-signature system provides a unique modification of the BLS scheme, referred to herein as the “mBLS” process. The public parameters of the mBLS process are the same as defined above for the BLS scheme. As with the BLS scheme, the mBLS process includes three basic algorithms, including a KeyGen algorithm, a Sign, and a Verify algorithm, where:

• • 1. KeyGen: The mBLS-based KeyGen algorithm picks two random numbers x₁,x₂ from Z_q* (note that the BLS scheme used only a single random number) and computes y₁=g^x1 and y₂=g^x2. The pubic key is y₁,y₂ ε G and the private key is x₁/x₂.
  • 2. Sign: The mBLS-based Sign algorithm uses a key pair (x₁,x₂) and a message m ε {0,1}* to generate a signature σ=(H(m)^x1/x2). In other words, the mBLS-based Sign algorithm can be denoted as illustrated by Equation 15, where:

σ←mBLS.Sign(x₁/x₂,m)   Equation 15

• • 3. Verify: The mBLS-based Verify algorithm receives the public key y₁,y₂ ε G, a message m ε {0,1}*, and a signature σ. Given these inputs, the algorithm outputs “1” if e(y₁,H(m))=e(y₂,σ), or “0” otherwise (i.e., verified (1), or not verified (0)). In other words, the mBLS-based Verify algorithm can be denoted as illustrated by Equation 16, where:

mBLS.Ver(σ,(y₁,y₂),m)   Equation 16

Theorem 2: If the wCDH assumption is true for G, the mBLS process is secure under adaptive chosen-message attacks in the random oracle model.

2.7 A Conventional Signature Scheme Without Random Oracles

A conventional signature scheme that does not require the use of random oracles was introduced in a publication entitled “Efficient identity-based encryption without random oracles,” by B. Waters, in Advances in Cryptology, Eurocrypt 2005, volume 3494 of LNCS 3494, pp. 114-127, Springer-Verlag, 2005. This conventional identity-based encryption scheme, referred to herein as the “Waters scheme,” provides an efficient identity-based encryption scheme that is secure in the full model, without random oracles. The security of the Waters scheme was proved by reducing it to a decisional Bilinear Diffie-Hellman problem.

In various embodiments, the proxy re-signature system provides a unique modification (identified using the notation “S_mu*”) of the Waters scheme for use in providing proxy re-signatures. Consequently, the following paragraphs will generally describe the Waters scheme prior to introducing the unique modification to the Waters scheme.

In general, the public parameters of the Waters scheme are (q,g,G,G_T,e), where (q,g,G,G_T,e)←BSetup(1^k). The following terminology is used through the remainder of the detailed description: H_w(m)=u′·Π_iεUu_i, where U ⊂ {1, . . . ,n_m} is the set of indices i such that m[i]=1, and m[i] is the i-th bit of m. As with other conventional secure signature schemes, the Waters scheme includes three basic algorithms, including a KeyGen algorithm, a Sign, and a Verify algorithm, where:

• • 1. KeyGen: The KeyGen algorithm of the Waters scheme first selects a random number a from Z_q*, and n_m+2 random numbers (g₂,u′,u₁, . . . ,u_nm) from G, and outputs the key pair pk=g₁=g^a and sk=a, and the public parameters (G,G_T,e,g₂,u′,u₁, . . . ,u_nm).
  • 2. Sign: The Sign algorithm of the Waters scheme receives an input of a secret key sk=a and a n_m-bit message m. This Sign algorithm then outputs a signature σ=(A,B)=(g₂^a·H_w(m)^r,g^r), where r is chosen randomly from Z_q*. In other words, the Sign algorithm of the Waters scheme can be denoted as illustrated by Equation 17, where:

σ←Waters.Sign(sk,m)   Equation 17

• • 3. Verify: The Verify algorithm of the Waters scheme receives an input of a public key, pk, a n_m-bit message m, and a test signature σ=(A,B). The Verify algorithm of the Waters scheme then outputs “1” (i.e., true) if e(pk,g₂)e(B,H_w(m))=e(A,g), or 0 (i.e., false) otherwise. In other words, the Verify algorithm of the Waters scheme can be denoted as illustrated by Equation 18, where:

Waters.Ver(σ,pk,m)   Equation 18

Theorem 3: If the CDH assumption is true for G, the Waters scheme is secure under adaptive chosen-message attacks in the standard model, without the use of random oracles

2.8 mWat Process

A process referred to herein as the “mWat” process of the proxy re-signature system provides a novel modification of the Waters scheme described in Section 2.7. The mWat process provides a secure process that enables various embodiments of the proxy re-signature system to perform proxy re-signature operations without the use of random oracles. As with other secure signature processes, the mWat process includes three basic algorithms, including a KeyGen algorithm, a Sign, and a Verify algorithm, where:

• • 1. KeyGen: The KeyGen algorithm of the mWat process first selects a random number a from Z_q*, and n_m+2 random numbers (g₂,u′,u₁, . . . ,u_nm) from G. The KeyGen algorithm of the mWat process then outputs a key pair pk₁=g^a, pk₂=g^b, pk₃=g^a/b and sk=a/b, and the public parameters (G,G_T,e,g₂,u′,u₁, . . . ,u_nm).
  • 2. Sign: The Sign algorithm of the mWat process receives an input of a secret key sk=a/b and a n_m-bit message m. The Sign algorithm of the mWat process then outputs signature σ=(A,B,C)=(g₂^a/b·II_w(m)^r,g^r,g^rb), where r is chosen randomly from Z_q*. In other words, the Sign algorithm of the mWat process can be denoted as illustrated by Equation 19, where:

σ←mWat.Sign(sk,m)   Equation 19

• • 3. Verify: The Verify algorithm of the mWat process receives an input of a public key pk, a n_m-bit message m, and a test signature σ=(A,B,C). The Verify algorithm of the mWat process then outputs “1” (i.e., true) if e(A,g)=e(H_w(m),B)e(g₂,pk₃), e(pk₂,B)=e(C,g), or “0” (i.e., false) otherwise. In other words, the Verify algorithm of the mWat process can be denoted as illustrated by Equation 20, where:

mWat.Sign(σ,(pk₁,pk₂,pk₃),m)   Equation 20

Theorem 4: If the ECDH assumption is true for G, the mWat process is secure under adaptive chosen-message attacks in the standard model without the use of random oracles.

2.9 Security Failure Case for the AH Model

The following paragraphs describe an example of a proxy re-signature scheme that is proven to be secure under the AH model, but is proven to be insure under the proxy re-signature system security model described herein. In other words, the proxy re-signature system security model provides enhanced security relative to the conventional AH model.

In particular, the following paragraphs describe a unidirectional multi-use proxy re-signature process referred to herein as “S_umu.” The S_umu process is secure under the conventional AH model but insecure in the proxy re-signature system security model. This fact shows that the proxy re-signature system security model is more secure than the AH model.

The public parameters of scheme S_umu are almost the same as those of the aforementioned BLS scheme, except that there are two hash functions in S_umu: H₁,H₂: {0,1}*→G. As with other proxy re-signature schemes, the S_umu scheme includes five basic algorithms, including: KeyGen, ReKey, Sign, ReSign, and Verify where:

• • 1. KeyGen: Given an input of a security parameter, 1^k, the KeyGen algorithm of the S_umu scheme selects a random number a ε Z_q*, and outputs the key pair pk=g^a and sk=a.
  • 2. Re-Signature Key Generation (ReKey): Given an input of Alice's public key, pk_A=g^a, and Bob's private key sk_B=b, the ReKey algorithm of the S_umu scheme outputs the re-signature key rk_A→B=(r,pkr_A^r,H₂(pk_A^r)^b), where r is a random number in Z_q* determined by Bob. Note that the re-signature key is generated by Bob and then delegated by Bob to the proxy. Due to the inherent security of the BLS scheme, no one expect Bob can generate a valid re-signature key to transform Alice's signature on a message to Bob's signature on that same message.
  • 3. Sign: Given the input of a secret key sk=a and a message m, the Sign algorithm of the S_umu scheme outputs an owner-type signature σ=H₁(m)^a or a non-owner-type signature σ=(s,A₁,B₁,A₂,B₂, . . . ,A_i,B_i), where s=H₁(m)^r1, A_j=g^rj(1≦j≦i), B_j=H₂(A_j)^rj(1≦j<i), B_i=H₂(A_i)^a, and r_j (1≦j≦i) are random numbers in Z_q*.
  • 4. ReSign: Given a re-signature key rk_A→B=(rk_A→B⁽¹⁾,rk_A→B⁽²⁾,rk_A→B⁽³⁾), a public key pk_A, a signature σ, and a message m, the ReSign algorithm of the S_umu scheme first checks to determine whether Verify

$\mathrm{Verify}\left(pk_A,m,\sigma \right)\stackrel{?}{=}1.$

If the verification fails (i.e, Verify(pk_A,m,σ)≠1), then the ReSign algorithm outputs ⊥; otherwise:

• • • a. if σ is an owner-type signature, the ReSign algorithm outputs:

$\begin{array}{c}{\sigma }^{\prime }=\left({\sigma }^{{\mathrm{rk}}_{A\to B}^{\left(1\right)}},{\mathrm{rk}}_{A\to B}^{\left(2\right)},{\mathrm{rk}}_{A\to B}^{\left(3\right)}\right)\\ =\left({H_1\left(m\right)}^{\mathrm{ra}},pk_A^r,{H_2\left(pk_A^r\right)}^b\right).\end{array}$

• • • b. if σ is a non-owner-type signature, outputs:

$\begin{array}{c}{\sigma }^{\prime }=\left(s,A_1,B_1,\dots ,A_i,{\left(B_i\right)}^{{\mathrm{rk}}_{A\to B}^{\left(1\right)}},{\mathrm{rk}}_{A\to B}^{\left(2\right)},{\mathrm{rk}}_{A\to B}^{\left(3\right)}\right)\\ =\left(s,A_1,B_1,\dots ,A_i,{H_2\left(A_i\right)}^{\mathrm{ra}},pk_A^r,{H_2\left(pk_A^r\right)}^h\right)\end{array}$

• • 5. Verify: Given the input of a public key, pk, a message m, and a signature σ, the Verify algorithm of the S_umu scheme outputs one of the following:
    • a. if σ is an owner-type signature, the Verify algorithm checks

$e\left(\sigma ,g\right)\stackrel{?}{=}e\left(H_1\left(m\right),pk_A\right).$

If the equation is true, the Verify algorithm outputs 1; otherwise, the Verify algorithm outputs 0.

• • • b. if σ is a non-owner-type signature, the Verify algorithm evaluates the following conditions:

$e\left(s,g\right)\stackrel{?}{=}e\left(H_1\left(m\right),A_1\right),e\left(B_j,g\right)\stackrel{?}{=}e\left(H_2\left(A_j\right),A_{j+1}\right)\left(1\le j<i\right),e\left(B_i,g\right)\stackrel{?}{=}e\left(H_2\left(A_i\right),pk_A\right)$

• • • • then, if all the above conditions are true, the Verify algorithm outputs 1 (i.e., true, signature verified); otherwise, the Verify algorithm outputs 0 (i.e., false, signature not verified).

2.9.1 Security Considerations

Since the S_umu scheme is implemented using the BLS scheme, conventional BLS proofs, including the oracles in the proof of the BLS scheme can be used to validate the security of the S_umu scheme. In particular, a forgery under the BLS scheme can be identified when the adversary, attacking on scheme S_umu, outputs a forgery of scheme S_umu. As a result, the S_umu scheme is secure in the AH model.

However, consider the following case: Alice→Proxy→Bob. First, Alice can produce a non-owner-type signature on m: σ_a=(H₁(m)^r,g^r,H₂(g^r)^a), where Alice knows the value of r. Then, Proxy can transform Alice's signature, σ_a, into Bob's signature σ_b=(H₁(m)^r,g^r,H₂(g^r)^arA>B,pk_A^rA>B,H₂(pk_A^rA>B)^b). In this case, Alice can generate signatures on any message, simply by changing m to m′, since Alice knows the value of r. This attack is defined in the security notion of NAPU (see the discussion regarding delegator security in Section 2.2.2). As a result, the S_umu scheme is insecure under the proxy re-signature system security model.

In other words, while the S_umu scheme appears to be secure under the conventional AH model, the proxy re-signature system security model shows that the S_umu scheme is actually insecure. As such, the proxy re-signature system security model provides improved security for proxy re-signature operations.

3.0 Operational Details of the Proxy Re-Signature System

As noted above, the proxy re-signature system provides various techniques for automatically and securely re-signing messages by transforming the signature of a delegatee to that of a delegator using various collusion resistant re-signature processes. The following sections provide a detailed discussion of the operation of various embodiments of the proxy re-signature system, and of exemplary methods for implementing the program modules described in Section 1 with respect to FIG. 1, in view of the definitions and general considerations described in Section 2. In particular, the following sections describe examples and operational details of various embodiments of the proxy re-signature system, including: various non-interactive embodiments of the proxy re-signature system under the random oracle model; a security analysis and security considerations of the proxy re-signature system; reducing of re-signature size; various non-interactive embodiments of the proxy re-signature system with more efficiency under the random oracle model; and various non-interactive embodiments of the proxy re-signature system under the standard model (without the use of random oracles).

3.1 Random Oracle Model Version of Proxy Re-Signature System S_mu:

A random oracle-based embodiment of the proxy re-signature system, referred to herein as “S_mu” provides an improved version of S_umu scheme that is proven to be secure under the proxy re-signature system security model (as well as being secure under other security models, such as the AH model). The pubic parameters of the S_mu process are almost the same as those of the S_umu scheme, except for an additional hash function: H₃:{0,1}*→G. As with other proxy re-signature schemes, the S_mu proxy re-signature process includes five basic algorithms, including: KeyGen, ReKey, Sign, ReSign, and Verify where:

• • 1. KeyGen: Given an input of a security parameter, 1^k, the KeyGen algorithm of the S_mu proxy re-signature process selects a random number a ε Z_q*, and outputs the key pair pk=g^a and sk=a.
  • 2. Re-Signature Key Generation (ReKey): Given an input of Alice's public key pk_A=g^a and Bob's private key sk_B=b, the ReKey algorithm of the S_mu proxy re-signature process outputs the re-signature key rk_A→B=(r,pk_A^r,II₃(pk_A^r∥pk_A)^b), where r is a random number in Z_q* determined by Bob. This re-signature key is generated by Bob and then delegates to the proxy. Due to the inherent security of BLS scheme, no one expect Bob can generate a valid re-signature key to transform Alice's signature on a message to Bob's signature on that same message. Note that this ReKey algorithm can be described in terms of a unique modification to the BLS scheme as illustrated by Equation 21, where:

rk _A→B=(r,pk_A^r,BLS.Sign(b,pk_A^r∥pk_A)).   Equation 21

• • 3. Sign: Given the input of a secret key, sk=a (from either Alice or Bob) and a message, m, the Sign algorithm of the S_mu proxy re-signature process outputs an owner-type signature, σ=H₁(m)^a, or a non-owner-type signature σ=(s,A₁,B₁,C₁,D₁, . . . ,A_i,B_i,C_i,D_i), where A_j=g^aj, B_j=g^bj, C_j=H₂(s)^aj/bj for 1≦j≦i, and D_j=H₃(g_j^a∥g_j^b)^aj+1 for 1≦j<i, and D_i=II₃(g_i^a∥g_i^b)^a, and a_j and b_j (1≦i) are random numbers in Z_q* and s=H₁(m)^a1. Note that this Sign algorithm can be described in terms of a unique modification to the BLS scheme which uses the above-described mBLS process as illustrated by Equation 22, where:

C _j =mBLS.Sign(a_j/b_j,s)(1≦j≦i),

D _j =BLS.Sign(a_j+1,g^aj∥g^bj)(1≦j<i),

D _i =BLS.Sign(a,g^ai∥g^bi).   Equation 22

• • 4. Re-Sign: Given a re-signature key rk_A→B=(rk_A→B⁽¹⁾,rk_A→B⁽²⁾,rk_A→B⁽³⁾), a public key pk_A, the signature a generated by the above Sign algorithm, and the message m, the ReSign algorithm of the S_mu proxy re-signature process first determines whether the signature is valid by determining whether

$\mathrm{Verify}\left(pk_A,m,\sigma \right)\stackrel{?}{=}1.$

If the verification fails (i.e, Verify(pk_A,m,σ)≠1), then the ReSign algorithm outputs ⊥; otherwise:

• • • a. if σ is an owner-type signature, σ=H₁(m)^a, the ReSign algorithm outputs a transformed signature, σ′, in the form of σ′=(s,A,B,C,D), where:

$s={\sigma }^{{\mathrm{rk}}_{A->B}^{\left(1\right)}}={H_1\left(m\right)}^{\mathrm{ra}},A={\mathrm{rk}}_{A->B}^{\left(2\right)}=pk_A^2,B=pk_A=g^a,C={H_2\left(s\right)}^{{\mathrm{rk}}_{A->B}^{\left(1\right)}}={H_2\left({H_1\left(m\right)}^{\mathrm{ra}}\right)}^r,D={\mathrm{rk}}_{A->B}^{\left(3\right)}={H_3\left(pk_A^rpk_A\right)}^b.$

• • • b. if σ is a non-owner-type signature, σ=(s,A₁,B₁,C₁,D₁, . . . ,A_i,B_i,C_i,D_i), the ReSign algorithm outputs a transformed signature, σ′, in the form of

${\sigma }^{\prime }\left(s,A_1,B_1,C_1,D_1,\dots ,A_i,B_i,C_i,D_i^{{\mathrm{rk}}_{A->B}^{\left(1\right)}},{\mathrm{rk}}_{A->B}^{\left(2\right)},pk_A,{H_2\left(s\right)}^{{\mathrm{rk}}_{A->B}^{\left(1\right)}},{\mathrm{rk}}_{A->B}^{\left(3\right)}\right),\mathrm{where}\text{:}$ $D_i^{{\mathrm{rk}}_{A->B}^{\left(1\right)}}=H_3\left(g^{a_i}g^{b_i}\right),{\mathrm{rk}}_{A->B}^{\left(2\right)}=pk_A^2,{H_2\left(s\right)}^{{\mathrm{rk}}_{A->B}^{\left(1\right)}}={H_2\left(s\right)}^r,{\mathrm{rk}}_{A->B}^{\left(3\right)}={H_3\left(pk_A^rpk_A\right)}^b.$

• • • Note that the ReSign algorithm can be described in terms of a unique modification to the BLS scheme in view of the above described mBLS process as follows:
    • a. if σ is an owner-type signature, then:

C=mBLS.Sign(r,s),

D=BLS.Sign(b,pk_A^r∥pk_A)

• • • b. if σ is a non-owner-type signature, then:

$C_{i+1}={H_2\left(s\right)}^{{\mathrm{rk}}_{A->B}^{\left(1\right)}}=\mathrm{mBLS}·\mathrm{Sign}\left(r,s\right),D_{i+1}={\mathrm{rk}}_{A\to B}^{\left(3\right)}=\mathrm{BLS}·\mathrm{Sign}\left(b,pk_A^rpk_A\right).$

• • 5. Verify: Given the input of a public key, pk, the message m, and the signature σ, the Verify algorithm of the S_mu proxy re-signature process performs the following verifications:
    • a. if σ is an owner-type signature, the Verify algorithm determines whether

$e\left(\sigma ,g\right)\stackrel{?}{=}e\left(H_1\left(m\right),pk\right).$

If the equation is true, the Verify algorithm outputs 1; otherwise, the Verify algorithm outputs 0.

• • • b. if σ is a non-owner-type signature, the Verify algorithm checks the following conditions, such that if each of the following conditions is true, the Verify algorithm outputs a “1” (i.e., verification successful). If any of the conditions is not true, the Verify algorithm outputs a “0” (i.e., verification failed).

$e\left(s,g\right)\stackrel{?}{=}e\left(H_1\left(m\right),A_1\right),e\left(C_j,B_j\right)\stackrel{?}{=}e\left(H_2\left(s\right),A_j\right)\left(1\le j\le i\right),e\left(D_j,g\right)\stackrel{?}{=}e(H_3\left(A_jB_j),A_{j+1}\right)\left(1\le j<i\right),e\left(D_i,g\right)\stackrel{?}{=}e(H_3\left(A_iB_i),pk\right).$

Note that the Verify algorithm shown above can be described in terms of a unique modification of the BLS scheme and the mBLS process as shown below. Note that in each of the following two cases, if each of the following equations is true, the Verify algorithm outputs 1; otherwise, the Verify algorithm outputs 0:

• • 1. If σ is an owner-type signature, then BLS.Ver(σ,pk,m).
  • 2. If σ is a non-owner-type signature, then

BLS.Ver(s,A₁,m),

mBLS.Ver(C_j,(A_j,B_j),s) (1≦j≦i),

BLS.Ver(D_j,A_j+1,A_j∥B_j)(1≦j<i),

BLS.Ver(D_i,pk,A_i∥B_i).

3.2 Security Considerations of the Proxy Re-Signature System

Lemma 1: In the random oracle case, the S_mu proxy re-signature process is correct and secure if both the BLS scheme and the mBLS process are secure under adaptive chosen-message attacks.

Proof Summary: Since the S_mu proxy re-signature process is implemented by the BLS scheme and the mBLS process, security proofs of the S_mu proxy re-signature process can be achieved using the proofs of the BLS scheme and the mBLS process, as described above, particularly with respect to the oracles in the proofs of the BLS scheme and the mBLS process. Therefore, all oracles (with the exception of the rekey oracle, as discussed in Section 3.2.1) required by the proxy re-signature system security model can be answered. Furthermore, a forgery can always be identified with either the BLS scheme or the mBLS process when the adversary, attacking S_mu, outputs a forgery of S_mu. As a result, the S_mu proxy re-signature process is secure under the proxy re-signature system security model.

3.2.1 Re-Signature Key Generation Oracle

In view of Theorem 1 and Theorem 2 (see Section 2.5 and Section 2.6, respectively, there are several random oracles, as described below. As noted above, a random oracle is a theoretical black box (typically implemented as a mathematical algorithm) that responds to every query with a random response chosen uniformly from its output domain, except that for any specific query, it responds the same way every time it receives that query. In other words, a random oracle is a mathematical function that maps every possible query to a random response from its output domain.

• • 1. BLS.KeyGen: Given an input of the security parameter 1^k, the BLS.KeyGen oracle outputs a public key pk.
  • 2. BLS.H: Given an input of a string m, the BLS.H oracle outputs a random number R in G.
  • 3. BLS.Sign: Given an input of a public key, pk, and a message m, the BLS.Sign oracle outputs a BLS signature, σ.
  • 4. mBLS.KeyGen: Given an input of the security parameter 1^k, the mBLS.KeyGen oracle outputs a public key (pk₁,pk₂).
  • 5. mBLS.H: Given an input of a string, m, the mBLS.H oracle outputs a random number R in G.
  • 6. mBLS.Sign: Given an input of a public key (pk₁,pk₂) and a message m, the mBLS.Sign oracle outputs an mBLS signature σ.

Note that that running the BLS.KeyGen oracle twice is equivalent to running the mBLS.KeyGen oracle once. Note also that the following discussion uses the BLS.H oracle to answer the two random oracles O_H1 and O_H3, however, the proxy re-signature system requires that on the same input, the outputs of O_H1 and O_H3 are different in order to maintain security.

3.2.2 Limited Proxy

For each query on O_rekey on the input (pk_i,pk_j), the Challenger (either Alice or Bob, depending upon the circumstances) searches for the tuple (pk_i,pk_j,Λ₁,Λ₂,Λ₃) in table T_rk.

If this tuple, (pk_i,pk_j,Λ₁,Λ₂,Λ₃) does not exist, the Challenger chooses a random number r_ij from Z_q*, computes R_ij=(pk_i)^rij, and returns (r_ij,R_ij,BLS.Sign(pk_j,(R_ij∥pk_i)). The Challenger then records (pk_i,pk_j,r_ij,R_ij,BLS.Sign(pk_j,(R_ij∥pk_i))) into table T_rk. Note that R_ij ε {R|R←BLS.KeyGen(1^k)}, and BLS.Sign(pk_j,(R_ij∥pk_i)) are associated with the random oracle O_H3.

However, if this tuple, (pk_i,pk_j,Λ₁,Λ₂,Λ₃), does exist, the Challenger just returns (Λ₁,Λ₂,Λ₃) to the adversary (either Alice or Bob, depending upon the circumstances).

3.2.3 Delegatee Security

For each query to O_rekey on the input (pk_i,pk_j) (pk_j≠pk₀), the Challenger searches for the tuple (pk_i,pk_j,Λ₁,Λ₂,Λ₃) in table T_rk.

If this tuple, (pk_i,pk_j,Λ₁,Λ₂,Λ₃), does not exist, Bob chooses a random number r_p ε Z_q* and sends (r,pk_i^r,H₃(pk_i^r∥pk_i)^xj) to the proxy (also the adversary). If pk_i=pk₀, Alice (the challenger in this case) will record (pk₀,pk_j,r,pk_o^r,H₃(pk₀^r∥pk₀)^xj) into table T_rk.

Conversely, if this tuple, (pk_i,pk_j,Λ₁,Λ₂,Λ₃), does exist, the Challenger just returns (Λ₁,Λ₂,Λ₃) to the adversary.

3.2.4 Delegator Security

For each query to O_rekey on the input (pk_i,pk_j), the Challenger searches for the tuple (pk_i,pk_j,Λ₁,Λ₂,Λ₃) in table T_rk.

If this tuple does not exist, there are three cases:

• • 1. If pk_i=pk₀, then Bob (the adversary) chooses a random number r ε Z_q*, and sends (r,pk₀^r,H₃(pk₀^r∥pk₀)^xj) to the proxy (also the adversary). At last, Alice (the challenger) will record (pk₀,pk_j,r,pk₀^r,H₃(pk₀^r∥pk₀)^xj) into table T_rk.
  • 2. If pk_i≠pk₀ and pk_j≠pk₀, then the adversary can compute the rekeys by himself given the corresponding secret keys.
  • 3. If pk_i≠pk₀ and pk_j=pk₀, then the Challenger Bob chooses a random number r_p ε Z_q*, and sends (r,pk_i^r,BLS.Sign(pk₀,(pk_i^r∥pk_i))) to the proxy.

Conversely, if this tuple, (pk_i,pk_j,Λ₁,Λ₂,Λ₃), does exist, the Challenger just returns (Λ₁,Λ₂,Λ₃) to the adversary.

Combining Theorem 1, Theorem 2 and the Lemma 1, Theorem 5 is constructed, as follows:

Theorem 5: In the random oracle model, the S_mu proxy re-signature process is correct and secure under the Computational Diffie-Hellman (CDH) assumption and the weaker Computational Diffie-Hellman (wCDH) assumption in G (External and Internal Security).

3.3 Reduction of Re-Signature Size

In various embodiments, to reduce the size of re-signature, the proxy re-signature system applies aggregate signature techniques for aggregating D_j (1≦j≦i) into D=Π_j=1ⁱD_j. As a result, the verification equation of non-owner-type signatures changes to the construct illustrated by Equation 23, where:

$\begin{array}{cc}e\left(s,g\right)\stackrel{?}{=}e\left(H_1\left(m\right),A_1\right),e\left(C_j,B_j\right)\stackrel{?}{=}e\left(H_2\left(s\right),A_j\right)\left(1\le j\le i\right),e\left(D,g\right)\stackrel{?}{=}\prod _{j=1}^{i-1}e(H_3\left(A_jB_j),A_{j+1}\right)e(H_3\left(A_iB_i),pk\right).& \mathrm{Equation}23\end{array}$

In order to maintain the multi-use property, the last D_j (1≦j≦i), i.e. D_i is stored as part of the signature, since in the scheme S_mu, the re-sign process changes D_j into

$D_i^{{\mathrm{rk}}_{A\to B}^{\left(1\right)}}.$

The last D_j can be verified by checking

$e\left(D_i,g\right)\stackrel{?}{=}e(H_3\left(A_iB_i),pk\right).$

The new aggregated D after re-signature, denoted as D^′, changes into

$D·D_i^{{\mathrm{rk}}_{A\to B}^{\left(1\right)}}·{\mathrm{rk}}_{A\to B}^{\left(3\right)}/D_i.$

3.4 Alternative More Efficient Version of the Proxy Re-Signature System S_mu^′

This alternative version of proxy re-signature process, denoted as S_mu′, is more efficient than the previous described proxy re-signature process S_mu. It includes four basic algorithms (since a signed message is assumed to be already available), including: KeyGen, ReKey, ReSign, and Verifywhere:

• • 1. KeyGen: Given an input of a security parameter, 1^k, the KeyGen algorithm of the S_mu proxy re-signature process selects a random number a ε Z_q*, and outputs the key pair pk=g^a and sk=a. Note that this is the same as for the version S_mu described above.
  • 2. Re-Signature Key Generation (ReKey): Given an input of Alice's public key and Bob's private key pk_A and sk_B=b, respectively, this ReKey algorithm outputs a re-signature key rk_A→B=(r,g^r,H₃(g^r∥pk_A)^b), where r is a random number in Z_q* determined by Bob only. The form of this re-signature key means that the signing rights of pk_B are delegated to pk_A with the help of g^r.
  • 3. Re-Sign: Given the re-signature key, rk_A→B=(rk_A→B⁽¹⁾,rk_A→B⁽²⁾,rk_A→B⁽³⁾), described above, Alice's public key pk_A, and Alice's signature σ on message m, this ReSign algorithm first determines whether

$\mathrm{Verify}\left(pk_A,m,\sigma \right)\stackrel{?}{=}1$

is true (i.e., whether Alice's signature on message m is valid). If the verification check fails (i.e., Verify(pk_A,m,σ)≠1, the ReSign algorithm outputs ⊥; otherwise, if the verification check is true (i.e., Verify(pk_A,m,σ)=1), then:

• • • a. if σ is an owner-type signature, σ=H₁(m)^a, the ReSign algorithm outputs a transformed signature, σ′, in the form of σ′=(s,A,B,C,D), where s=σ, A=rk_A→B⁽²⁾=g^r, B=pk_A=g^a,

$C={H_2\left(s\right)}^{{\mathrm{rk}}_{A\to B}^{\left(1\right)}}={H_2\left({H_1\left(m\right)}^a\right)}^r$

and D=rk_A→B⁽³⁾=H₃(g^r∥g^a)^b.

• • • b. if σ is a non-owner-type signature, σ=(s,A₁,B₁,C₁,D₁, . . . ,A_i,B_i,C_i,D_i), the ReSign algorithm outputs a transformed signature, σ′, in the form of σ′=(s,A₁,B₁,C₁,D₁, . . . ,A_i,B_i,C_i,D_i,rk_A→B⁽²⁾,pk_A,

${H_2\left(s\right)}^{{\mathrm{rk}}_{A\to B}},$

rk_A→B⁽³⁾), where rk_A→B⁽²⁾=g^r,

${H_2\left(s\right)}^{{\mathrm{rk}}_{A\to B}^{\left(1\right)}}={H_2\left(s\right)}^r,$

and rk_A→B⁽³⁾=H₃(g^r∥pk_A)^b).

• • 4. Verify (Verify): Given the input of a public key, pk, a message m, and a corresponding signature σ, this Verify algorithm does the following:
    • a. if σ is an owner-type signature, the Verify algorithm determines whether

$e\left(\sigma ,g\right)\stackrel{?}{=}e\left(H_1\left(m\right),pk\right).$

If this equation is true, then the Verify algorithm outputs 1; otherwise, the Verify algorithm outputs 0.

• • • c. if σ is a non-owner-type signature, then the Verify algorithm evaluates the following conditions, such that if each of the following conditions is true, the Verify algorithm outputs a “1” (i.e., verification successful). If any of the conditions is not true, the Verify algorithm outputs a “0” (i.e., verification failed).

$e\left(s,g\right)\stackrel{?}{=}e\left(H_1\left(m\right),B_1\right),e\left(C_j,g\right)\stackrel{?}{=}e\left(H_2\left(s\right),A_j\right)\left(1\le j\le i\right),e\left(D_j,g\right)\stackrel{?}{=}e\left(H_3\left(A_jB_j\right),B_{j+1}\right)\left(1\le j<i\right),e\left(D_i,g\right)\stackrel{?}{=}e\left(H_3\left(A_iB_i\right),pk\right).$

The signature can be shortened by aggregating D_j into D=Π_j=1ⁱD_j, and aggregating C_j into C=Π_j=1ⁱC_j. The last C_j and D_j in this scheme do not need to be stored since re-signature does not change the last C_j and D_j in the old signature.

3.5 Standard Model Version of the Proxy Re-Signature System:

In various embodiments, the proxy re-signature system is further modified to convert the S_mu proxy re-signature process into an “S_mu*” proxy re-signature process that is proven secure in the proxy re-signature system security model without requiring the use of random oracles.

In general, the above-described S_mu proxy re-signature process is modified by replacing the BLS scheme with the Waters scheme, and replacing the mBLS process with the mWat process, respectively. Since both the Waters scheme and the mWat process are proven secure in the standard model, the S_mu* proxy re-signature process is also proven secure in the standard model.

In particular, the pubic parameters of the S_mu* proxy re-signature process are similar to those of the Waters scheme, except for the inclusion of three additional hash functions H₁:{0,1}*→{0,1}^nm, H₂:{0,1}*→{0,1}^nm, H₃:{0,1}*→{0,1}^nm. Specifically, as with other proxy re-signature techniques, the S_mu* proxy re-signature process includes: KeyGen, ReKey, Sign, ReSign, and Verify algorithms, where:

• • 1. Key Generation (KeyGen): Given the input of the security parameter 1^k, this KeyGen algorithm selects a random number a ε Z_q*. This KeyGen algorithm then outputs the key pair pk=g^a and sk=a.
  • 2. Re-Signature Key Generation (ReKey): Given the input of Alice's public key pk_A and Bob's private key sk_B=b, this ReKey algorithm outputs the re-signature key rk_A→B=(r,pk_A^r,g^r,g₂^bH_w(pk_A^r∥pk_A)^r′,g^r′), where r is a random number in Z_q* determined by Bob. The re-signature key is generated by Bob and then delegates to the proxy to transform Alice's signature on a message to Bob's signature on the same message. Due to the security of the Waters scheme, one except Bob can generate a valid re-signature key.
    • Note that the above described ReKey algorithm can also be described in terms of a unique modification to the Waters scheme as follows: given the input Alice's public key pk_A and Bob's private key sk_B=b, the ReKey algorithm outputs the re-signature key rk_A→B=(r,pk_A^r,g^r,Waters.Sign(b,pk_A^r∥pk_A)).
  • 3. Sign (Sign): Given the input of a secret key, sk=a, and a message m, this Sign algorithm outputs an owner-type signature σ=(g₂^aH_w(H₁(m))^r,g^r), where r is a random number from Z_q*, or a non-owner-type signature σ=(s⁽¹⁾,s⁽²⁾,A₁,B₁,C₁,D₁⁽¹⁾,D₁⁽²⁾,D₁⁽³⁾,E₁⁽¹⁾,E₁⁽²⁾ . . . ,A_i,B_i,C_i,D_i⁽¹⁾,D_i⁽²⁾,D_i⁽³⁾,E_i⁽¹⁾,E_i⁽²⁾), where A_j=g^aj, B_j=g^bj, C_j=g^aj/bj, D_j⁽¹⁾=g₂^aj/bjH_w(s)^rj, D_j⁽²⁾=g^rj, D_j⁽³⁾=g^ajrj for 1≦j≦i, E_j⁽¹⁾=g₂^aj+1H_w(g_j^a∥g_j^b)^r′j, and E_j⁽²⁾=g^r′j for 1≦j<i, and E_i⁽¹⁾=g₂^aH_w(g_i^a∥g_i^b)^ri, E_i⁽¹⁾=g^ri and a_j, b_j, r_j, and r_j (1≦j≦i) are random numbers in Z_q*, s₁⁽¹⁾=g₂^aH_w(m)^r and s₂⁽¹⁾=g^r. Note that this Sign algorithm can also be described in terms of a unique modification to the Waters scheme in combination with the mWat process as follows:

(D_j⁽¹⁾,D_j⁽²⁾,D_j⁽³⁾)=mWat.Sign(a_j/b_j,s)(1≦j≦i),

(E_j⁽¹⁾,E_j⁽²⁾)=Waters.Sign(a₂,g^a1∥g^b1)(1≦j<i),

(E_i⁽¹⁾,E_i⁽²⁾)=Waters.Sign(a,g^ai∥g^bi).

• • 4. Re-Sign (ReSign): Given a re-signature key, rk_A→B=(rk_A→B⁽¹⁾,rk_A→B⁽²⁾,rk_A→B⁽³⁾,rk_A→B⁽⁴⁾,rk_A→B⁽⁵⁾), a public key pk_A, a signature σ, and a message m, this ReSign algorithm first determines whether

$\mathrm{Verify}\left(pk_A,m,\sigma \right)\stackrel{?}{=}1$

is true. If the verification fails (i.e., Verify(pk_A,m,σ)≠1), then the ReSign algorithm outputs ⊥; otherwise, if the verification succeeds (i.e., Verify(pk_A,m,σ)=1), then the ReSign algorithm performs the following:

• • • a. if σ is an owner-type signature, σ=(g₂^aH_w(H₁(m))^r′,g^r′), then the ReSign algorithm outputs a transformed signature, σ′, in the form of σ′=(s⁽¹⁾,s⁽²⁾,A,B,C,D⁽¹⁾,D⁽²⁾,D⁽³⁾,E⁽¹⁾,E⁽²⁾), where:

$s^{\left(1\right)}={\left(g_2^a{H_w\left(H_1\left(m\right)\right)}^{r^{\prime }}\right)}^{{\mathrm{rk}}_{A\to B}^{\left(1\right)}},s^{\left(2\right)}={\left(g^{r^{\prime }}\right)}^{{\mathrm{rk}}_{A\to B}^{\left(1\right)}},A={\mathrm{rk}}_{A\to B}^{\left(2\right)},B=pk_A=g^a,C={\mathrm{rk}}_{A\to B}^{\left(3\right)},D^{\left(1\right)}=g_2^{{\mathrm{rk}}_{A\to B}^{\left(1\right)}}{H_w\left(H_2\left(s^{\left(1\right)}s^{\left(2\right)}\right)\right)}^{r^{″}},D^{\left(2\right)}=g^{r^{″}},D^{\left(3\right)}={\left(g^a\right)}^{r^{″}},E^{\left(1\right)}={\mathrm{rk}}_{A\to B}^{\left(4\right)},E^{\left(2\right)}={\mathrm{rk}}_{A\to B}^{\left(5\right)}.$

• • • b. if σ is a non-owner-type signature, σ=(s⁽¹⁾,s⁽²⁾,A₁,B₁,C₁,D₁⁽¹⁾,D₁⁽²⁾,D₁⁽³⁾,E₁⁽¹⁾,E₁⁽²⁾, . . . ,A_i,B_i,C_i,D_i⁽¹⁾,D_i⁽²⁾,D_i⁽³⁾,E_i⁽¹⁾,E_i⁽²⁾), then the ReSign algorithm outputs a transformed signature, σ′, in the form of:

${\sigma }^{\prime }=\left(s^{\left(1\right)},s^{\left(2\right)},A_1,B_1,C_1,D_1^{\left(1\right)},D_1^{\left(2\right)},D_1^{\left(3\right)},E_1^{\left(1\right)},E_1^{\left(2\right)}\dots ,A_i,B_i,C_i,D_i^{\left(1\right)},D_i^{\left(2\right)},D_i^{\left(3\right)},{\left(E_i^{\left(1\right)}\right)}^{{\mathrm{rk}}_{A\to B}^{\left(1\right)}},{\left(E_i^{\left(2\right)}\right)}^{{\mathrm{rk}}_{A\to B}^{\left(1\right)}},{\mathrm{rk}}_{A\to B}^{\left(2\right)},pk_A,{\mathrm{rk}}_{A\to B}^{\left(3\right)},g_2^{{\mathrm{rk}}_{A\to B}^{\left(1\right)}},g_2^{{\mathrm{rk}}_{A\to B}^{\left(1\right)}}{H_w\left(H_2\left(s^{\left(1\right)}s^{\left(2\right)}\right)\right)}^{r^{″}},g^{r^{″}},pk_A^{r^{″}},{\mathrm{rk}}_{A\to B}^{\left(4\right)},{\mathrm{rk}}_{A\to B}^{\left(5\right)}\right),\mathrm{where}\text{:}$ ${\left(E_i^{\left(1\right)}\right)}^{{\mathrm{rk}}_{A\to B}^{\left(1\right)}}={\left(g_2^a{H_w\left(H_3\left(g^{a_i}g^{b_i}\right)\right)}^{r^{\prime }}\right)}^{{\mathrm{rk}}_{A\to B}^{\left(1\right)}}$ ${\left(E_i^{\left(2\right)}\right)}^{{\mathrm{rk}}_{A\to B}^{\left(1\right)}}=\left(g^{r^{\prime }}\right){\mathrm{rk}}_{A->B}^{\left(1\right)}.$

• • • Note that the above-described ReSign algorithm can be described in terms of a unique modification to the Waters scheme and the mWat process as follows:
    • a. if σ is an owner-type signature, then:

(D₁⁽¹⁾,D₁⁽²⁾,D₁⁽³⁾)←mWat.Sign(r,H₂(s⁽¹⁾∥s⁽²⁾)),

(E₁⁽¹⁾,E₁⁽²⁾)←Waters.Sign(b,H₃(pk_A^r∥pk_A)).

• • • b. if σ is a non-owner-type signature, then:

(g₂^rkA→B(1)H_w(H₂(s⁽¹⁾∥s⁽²⁾))^r′,g^r′,pk_A^r′)←mWat.Sign(r,H₂(s⁽¹⁾∥s⁽²⁾,

(rk_A→B⁽⁴⁾,rk_A→B⁽⁵⁾)←Waters.Sign(b,H₃(pk_A^r∥pk_A)).

• • 5. Verify (Verify): Given the input of a public key, pk, a message m, and a signature σ, this Verify algorithm performs the following:
    • a. if σ is an owner-type signature (σ₁,σ₂), this Verify algorithm determines whether

$e\left({\sigma }_1,g\right)\stackrel{?}{=}e\left(H_w\left(H_1\left(m\right)\right),{\sigma }_2\right)e\left(g_2,pk\right)$

is true. If this condition is true, then the Verify algorithm outputs “1”; otherwise, the Verify algorithm outputs “0”.

• • • b. if σ is a non-owner-type signature, σ=(s⁽¹⁾,s⁽²⁾,A₁,B₁,C₁,D₁⁽¹⁾,D₁⁽²⁾,D₁⁽³⁾,E₁⁽¹⁾,E₁⁽²⁾ . . . ,A_i,B_i,C_i,D_i⁽¹⁾,D_i⁽²⁾,D_i⁽³⁾,E_i⁽¹⁾,E_i⁽²⁾), this Verify algorithm determines whether the following conditions are true, and if each of the following conditions are true, then the Verify algorithm outputs “1”; otherwise, the Verify algorithm outputs “0”.

$\mathrm{for}1\le j\le i\text{:}$ $e\left(s^{\left(1\right)},g\right)\stackrel{?}{=}e\left(H_w\left(H_1\left(m\right)\right),s^{\left(2\right)}\right)e\left(g_2,A_1\right),e\left(D_j^{\left(1\right)},g\right)=e\left(H_w\left(H_2\left(s^{\left(1\right)}s^{\left(2\right)}\right)\right),D_j^{\left(2\right)}\right)e\left(g_2,C_j\right),e\left(C_j,B_j\right)=e\left(A_j,g\right),e\left(B_j,D_j^{\left(2\right)}\right)=e\left(D_j^{\left(3\right)},g\right),\mathrm{for}1\le j<i$ $e\left(E_j^{\left(1\right)},g\right)=e\left(H_w\left(H_3\left(A_jB_j\right)\right),E_j^{\left(2\right)}\right)e\left(g_2,B_{j+1}\right),e\left(E_i^{\left(1\right)},g\right)=e\left(H_w\left(H_3\left(A_iB_i\right)\right),E_i^{\left(2\right)}\right)e\left(g_2,pk\right).$

Note that the above-described Verify algorithm can be described in terms of a unique modification to the Waters scheme and the mWat process as follows, where, in either case, if the outputs of all verifications are true, the Verify algorithm outputs “1”; otherwise, the Verify algorithm outputs “0”, where:

• • 1. if σ is an owner-type signature, (σ₁,σ₂), then:

Waters.Ver(σ,pk,H,₁(m))

• • 2. if σ is a non-owner-type signature, σ=(s⁽¹⁾,s⁽²⁾,A₁,B₁,C₁,D₁⁽¹⁾,D₁⁽²⁾,D₁⁽³⁾,E₁⁽¹⁾,E₁⁽²⁾ . . . ,A_i,B_i,C_i,D_i⁽¹⁾,D_i⁽²⁾,D_i⁽³⁾,E_i⁽¹⁾,E_i⁽²⁾), then:

Waters.Ver((s⁽¹⁾,s⁽²⁾),A₁,H₁(m)), where:

• • • for 1≦j≦i:

mWat.Ver((D_j⁽¹⁾,D_j⁽²⁾,D_j⁽³⁾),(A_j,B_j,C_j),H₂(s⁽¹⁾∥s⁽²⁾)),

e(C_j,B_j)=e(A_j,g),e(B_j,D_j⁽²⁾)=e(D_j⁽³⁾,g),

• • • for 1≦j<i:

Waters.Ver((E_j⁽¹⁾,E_j⁽²⁾),A_j+1,H₃(A_j∥B_j),

Waters.Ver((E_i⁽¹⁾,E_i⁽²⁾),pk,H₃(A_i∥B_i)).

3.5.1 Security Considerations

The following paragraphs discuss security considerations of the S_mu* proxy re-signature process without the use of random oracles.

Lemma 2: In the standard model, the S_mu* proxy re-signature process is correct and secure if both the Waters scheme and the mWat scheme are secure under adaptive chosen-message attacks.

Proof Summary: As discussed above, in order to construct the S_mu* proxy re-signature process from a starting point of the S_mu proxy re-signature process, the BLS scheme and the mBLS process of the S_mu proxy re-signature process were replaced with the Waters scheme and the mWat process, respectively. Therefore, the proof of Lemma 1 can be used to prove the security of the S_mu* proxy re-signature process by changing BLS and mBLS to Waters and mWat, respectively.

Then, combining Theorem 3, Theorem 4 and Lemma 2, Theorem 6 is constructed, as follows:

Theorem 6: In the standard model, the S_mu* proxy re-signature process is correct and secure under the Computational Diffie-Hellman (CDH) assumption and the Extended Computational Diffie-Hellman (ECDH) assumption in G (External and Internal Security).

4.0 Operational Summary of the Proxy Re-Signature System

In view of the preceding discussion, it should be clear that there are three basic forms of the proxy re-signature system, with numerous additional embodiments associated with each of those forms. In particular, as described in Section 3.1, one of the three basic forms of the proxy re-signature system provides various non-interactive message re-signature techniques under a random oracle model. As described in Section 3.4, the second basic form of the proxy re-signature system provides various alternative non-interactive message re-signature techniques under a random oracle model. Finally, as described in Section 3.5, the third basic form of the proxy re-signature system provides various non-interactive message re-signature techniques under the standard model (i.e., no random oracles.

The processes described above with respect to FIG. 1, and in further view of the detailed description provided above in Sections 1 through 3 are illustrated by the general operational flow diagrams of FIG. 2, FIG. 3, and FIG. 4, which illustrate various embodiments of each of the three basic forms of the proxy re-signature systems. Note that FIG. 2, FIG. 3, and FIG. 4 are not intended to be exhaustive representations of all of the various embodiments of the proxy re-signature system described herein, and that the embodiments represented in FIG. 2, FIG. 3, and FIG. 4 are provided only for purposes of explanation.

Further, it should be noted that any boxes and interconnections between boxes that may be represented by broken or dashed lines in FIG. 2, FIG. 3, and FIG. 4 represent optional or alternate embodiments of the proxy re-signature system described herein, and that any or all of these optional or alternate embodiments, as described below, may be used in combination with other alternate embodiments that are described throughout this document.

4.1 Non-Interactive Random Oracle Embodiment

In general, as illustrated by FIG. 2, the non-interactive random oracle model embodiment of the proxy re-signature system 200 begins with an key pair generation module 225, and includes a non-interactive re-signature key generation module 230 in which a delegator Bob 215 generates the re-signature key for the purpose to transform Alice's signature on a message to Bob's signature on that same message. Note that FIG. 2 shows the modules in the proxy re-signature system 200 rather than the actual relationship of those modules. Note also that as described in Section 3.1, the non-interactive random oracle model embodiment of the proxy re-signature system 200 is also referred to as the S_mu proxy re-signature process.

In particular, as described above in Section 3.1, in the S_mu proxy re-signature process, the key pair generation module 225 receives an input of a security parameter, 1^k. The KeyGen algorithm of the S_mu proxy re-signature process then uses the security parameter, 1^k to select a random number a ε Z_q*, and generate 225 the key pair pk=g^a and sk=a.

Next, re-signature key generator 230 produces a re-signature key to be used by the re-signing module 255 to transform delegate Alice's 210 signature to delegator Bob's 215 signature. In general, as described in detail in Section 3.1, given an input of Alice's public key pk_A=g^a and Bob's private key sk_B=b, the ReKey algorithm of the S_mu proxy re-signature key generating process 230 generates the re-signature key rk_A→B=(r,pk_A^r,H₃(pk_A^r∥pk_A)^b), where r is a random number in Z_q* determined by Bob. Note that the re-signature key is generated by delegator Bob alone, and the resulting key is sent to the proxy through a secure channel so that the proxy can use it to transform Alice's signature on a message to Bob's signature on that same message. Delegatee Alice or the proxy is not involved in generating the re-signature key. Alice's public key can be obtained through various chennels. Therefore the re-signature key generation is non-interactive.

Next, a signer such as the delegate Alice 210 in this example receives a message, m, that has not been signed previously, uses her secret key and then signs 235 that message using one of two possible types of signatures. In particular, the signing 235 of the message is accomplished using either an owner-type signature, σ=H₁(m)^a, or a non-owner-type signature σ=(s,A₁,B₁,C₁,D₁, . . . ,A_i,B_i,C_i,D_i), where A_j=g^aj, B_j=g^bj, and C_j=H₂(s)^aj/bj for 1≦j≦i, and D_j=H₃(g_j^a∥g_j^b)^aj+1, for 1≦j<i, and D_i=H₃(g_i^a∥g_i^b)^a, and a_j and b_j (1≦i) are random numbers in Z_q* and s=H₁(m)^a1.

Once the message has been signed by 235, a verifier receives Alice's 210 public key, pk_A, and attempts to verify 240 if the signature, σ, on the signed message m, is valid (i.e., that the message was actually signed by Alice). As discussed in detail in Section 3.1, this verification process 240 evaluates different conditions to determine validity of the signature depending upon whether the signature type on the message is an owner-type signature, or a non-owner-type signature.

For a message signed by Alice 210 to be transformed into Bob's 215 signature on that same message, a verifier is first used to check if the received signed message is actually signed by Alice. If the signature is determined 245 to be invalid (i.e., any of the validity conditions described in Section 3.1 are not satisfied), then the proxy terminates 250 the signature transformation process due to a suspected forgery attempt.

On the other hand, assuming that the signature is determined 245 to be valid (i.e., all of the validity conditions described in Section 3.1 for the particular signature type are satisfied), then the proxy re-signs 255 the message using the previously generated 230 re-signature key, rk_A→B=(r,pk_A^r,H₃(pk_A^r∥pk_A)^b). As discussed in detail in Section 3.1, this re-signature process 255 uses different transformation processes depending upon whether the signature type on the message is an owner-type signature, or a non-owner-type signature. Finally, the proxy outputs 260 message m with Bob's 215 signature as a re-signed message 265.

4.2 Alternative Non-Interactive Random Oracle Embodiment

In general, as illustrated by FIG. 3, the non-interactive random oracle model embodiment of the proxy re-signature system 300 begins an key pair generator 325, and includes a non-interactive re-signature key generator 330 to generate a re-signature key to transform Alice's 310 signature on a message to Bob's 315 signature on that same message. Note that FIG. 2 shows the modules in the proxy re-signature system 300 rather than the actual relationship of those modules. Note that as described in Section 3.4, the non-interactive random oracle model embodiment of the proxy re-signature system 300 is also referred to as the alternative non-interactive proxy re-signature process, denoted as S_mu^′.

In particular, as described above in Section 3.4, in the alternative non-interactive proxy re-signature process S_mu^′, the key pair generator 325 receives an input of a security parameter, 1^k. The KeyGen algorithm of the alternative non-interactive proxy re-signature system S_mu^′ then uses the security parameter, 1^k to select a random number a ε Z_q*, and generate 325 the key pair pk=g^a and sk=a. Note that this is the same process as described in Section 4.1 with respect to element 225 in FIG. 2.

Next, the delegator Bob 315 generates 330 a re-signature key which is then delegated to the proxy to transform the delegatee's signature on a message to delegator's signatures on that same message. Note also that once generated, the re-signature key can be reused to transform many signatures. In general, as described in detail in Section 3.4, given an input of Bob's private key, sk_B=b, and Alice's public key, pk_A, the ReKey algorithm of the alternative non-interactive proxy re-signature system S_mu^′ generates 330 the re-signature key rk_A→B=(r,g^r,H₃(g^r∥pk_A)^b), where r is a random number in Z_q* determined by Bob only. Note that the re-signature key generation is done in this embodiment by Bob alone and the resulting re-signature key is sent to the proxy through a secure channel. Therefore the re-signature key generation itself is non-interactive since Alice and the proxy are not involved in the process of the re-signature key generation.

Next, a signer such as the delegate Alice 310 in this example receives a message, m, that has not been signed previously, uses her secret key and then signs 335 that message using one of two possible types of signatures. This process is the same as 225 in FIG. 2.

Next, a verifier received a message, m, previously signed by Alice 310 with signature σ. The verifier then evaluates the signature type to determine 338 whether the signature is an owner-type signature, or a non-owner-type signature. As with the non-interactive proxy re-signature process S_mu, in the case of an owner-type signature, the signature will take the form of σ=H₁(m)^a. Similarly, as with the non-interactive proxy re-signature process S_mu, a non-owner-type signature will take the form of σ=(s,A₁,B₁,C₁,D₁, . . . ,A_i,B_i,C_i,D_i).

Having determined 338 the signature type, the verifier then attempts to determine the validity 340 the signature, σ, on the signed message m, using Alice's 310 public key, pk_A. As discussed in detail in Section 3.4, this verification process 340 evaluates different conditions to determine validity of the signature depending upon whether the signature type on the message is an owner-type signature, or a non-owner-type signature.

The same signature verification process is applied by the re-signature proxy in transforming Alice's signature on a message to Bob's signature on that same message. Upon receiving a message signed by Alice, the proxy applies the verification process to check validity of the received signed message. If the signature is determined 345 to be invalid (i.e., any of the validity conditions described in Section 3.4 are not satisfied for the particular signature type), then the proxy terminates 350 the signature transformation process due to a suspected forgery attempt.

On the other hand, assuming that the signature is determined 345 to be valid (i.e., all of the validity conditions described in Section 3.4 for the particular signature type are satisfied), then the proxy re-signs 355 the message using the previously generated 330 re-signature key, rk_A→B=(r,g^r,H₃(g^r∥pk_A)^b). As discussed in detail in Section 3.4, this re-signature process 355 uses different transformation processes depending upon whether the signature type on the message is an owner-type signature, or a non-owner-type signature. Finally, the proxy outputs 360 message m with Bob's 315 signature as a re-signed message 365.

4.3 Non-Interactive Standard Model Embodiment

In general, as illustrated by FIG. 4, the non-interactive standard model embodiment (no random oracles) of the proxy re-signature system 400 begins with an key pair generation module 425, and includes an non-interactive re-signature key generation module 430 in which Bob 415 uses his private key and Alice's 410 public key to generate a re-signature key and delegates the resulting key to the proxy for the purpose to transform Alice's signature on a message to Bob's signature on that same message. Note that FIG. 2 shows the modules in the proxy re-signature system 400 rather than the actual relationship of those modules. Note that as described in Section 3.5, the non-interactive random oracle model embodiment of the proxy re-signature system 400 is also referred to as the S_mu* proxy re-signature process.

In particular, as described above in Section 3.5, with respect to the non-interactive S_mu* proxy re-signature system, the key pair generator 425 receives an input of a security parameter, 1^k. The KeyGen algorithm of the S_mu* proxy re-signature system then uses the security parameter, 1^k to select a random number a ε Z_q*, for use in generating 425 the key pair pk=g^a and sk=a.

Next, the re-signature key generator 430 produces a re-signature key to be used by the re-signing module 455 to transform delegate Alice's 410 signature to delegator Bob's 415 signature. In general, as described in detail in Section 3.5, given an input of Alice's public key pk_A and Bob's private key sk_B=b, the ReKey algorithm of the S_mu* proxy re-signature process generates 430 the re-signature key rk_A→B=(r,pk_A^r,g^r,g₂^bH_w(pk_A^r∥pk_A)^r′,g^r′), where r is a random number in Z_q* determined by Bob. Note that the re-signature key is generated by Bob alone and the resulting key is delegated to the proxy.

Next, a signer such as the delegate Alice 410 in this example receives a message, m, and uses her secret key to sign 435 that message using one of two possible types of signatures. In particular, the signing 435 of the message is accomplished using either an owner-type signature, σ=(g₂^aH_w(H₁(m))^r,g^r), where r is a random number from Z_q*, or a non-owner-type signature in the form of: σ=(s⁽¹⁾,s⁽²⁾,A₁,B₁,C₁,D₁⁽¹⁾,D₁⁽²⁾,D₁⁽³⁾,E₁⁽¹⁾,E₁⁽²⁾ . . . ,A_i,B_i,C_i,D_i⁽¹⁾,D_i⁽²⁾,D_i⁽³⁾,E_i⁽¹⁾,E_i⁽²⁾), where A_j=g^aj, B_j=g^bj, C_j=g^aj/bj, D_j⁽¹⁾=g₂^aj/bjH_w(s)^rj, D_j⁽²⁾=g^rj, D_j⁽³⁾=g^ajrj for 1≦j≦i, E_j⁽¹⁾=g₂^aj+1H_w(g_j^a∥g_j^b)^r′j, and E_j⁽²⁾=g^r′j for 1≦j<i, and E_i⁽¹⁾=g₂^aH_w(g_i^a∥g_i^b)^ri, E_i⁽¹⁾=g^ri and a_j, b_j, r_j, and r_j (1≦j≦i) are random numbers in Z_q*, s₁⁽¹⁾=g₂^aH_w(m)^r and s₂⁽¹⁾=g^r.

Once the message has been signed by 435, a verifier receives Alice's 410 public key, pk_A, and attempts to verify 440 the signature, σ, on the signed message m, is valid (i.e., that the message was actually signed by Alice). As discussed in detail in Section 3.5, this verification process 440 evaluates different conditions to determine validity of the signature depending upon whether the signature type on the message is an owner-type signature, or a non-owner-type signature.

For a message signed by Alice 410 to be transformed into Bob's 415 signature on that same message, a verifier is first used to check if the received signed message is actually signed by Alice. If the signature is determined 445 to be invalid (i.e., any of the validity conditions described in Section 3.5 are not satisfied), then the proxy terminates 450 the signature transformation process due to a suspected forgery attempt.

On the other hand, assuming that the signature is determined 445 to be valid (i.e., all of the validity conditions described in Section 3.5 for the particular signature type are satisfied), then the proxy re-signs 455 the message using the previously generated 430 re-signature key, rk_A→B=(r,pk_A^r,g^r,g₂^bH_w(pk_A^r∥pk_A)^r′,g^r′). As discussed in detail in Section 3.5, this re-signature process 455 uses different transformation processes depending upon whether the signature type on the message is an owner-type signature, or a non-owner-type signature. Finally, the proxy outputs 460 message m with Bob's 415 signature as a re-signed message 465.

5.0 Exemplary Operating Environments

The proxy re-signature system is operational within numerous types of general purpose or special purpose computing system environments or configurations. FIG. 5 illustrates a simplified example of a general-purpose computer system on which various embodiments and elements of the proxy re-signature system, as described herein, may be implemented. It should be noted that any boxes that are represented by broken or dashed lines in FIG. 5 represent alternate embodiments of the simplified computing device, and that any or all of these alternate embodiments, as described below, may be used in combination with other alternate embodiments that are described throughout this document.

For example, FIG. 5 shows a general system diagram showing a simplified computing device. Such computing devices can be typically be found in devices having at least some minimum computational capability, including, but not limited to, personal computers, server computers, hand-held computing devices, laptop or mobile computers, communications devices such as cell phones and PDA's, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, video media players, etc.

At a minimum, to allow a device to implement the proxy re-signature system, the device must have some minimum computational capability along with a communications interface for interacting with other delegatees or delegators. In particular, as illustrated by FIG. 5, the computational capability is generally illustrated by one or more processing unit(s) 510, and may also include one or more GPUs 515. Note that that the processing unit(s) 510 of the general computing device of may be specialized microprocessors, such as a DSP, a VLIW, or other micro-controller, or can be conventional CPUs having one or more processing cores, including specialized GPU-based cores in a multi-core CPU.

In addition, the simplified computing device of FIG. 5 may also include other components, such as, for example, a communications interface 530. The simplified computing device of FIG. 5 may also include one or more conventional computer input devices 540. The simplified computing device of FIG. 5 may also include other optional components, such as, for example one or more conventional computer output devices 550. Finally, the simplified computing device of FIG. 5 may also include storage 560 that is either removable 570 and/or non-removable 580. Note that typical communications interfaces 530, input devices 540, output devices 550, and storage devices 560 for general-purpose computers are well known to those skilled in the art, and will not be described in detail herein.

The foregoing description of the proxy re-signature system has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the claimed subject matter to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. Further, it should be noted that any or all of the aforementioned alternate embodiments may be used in any combination desired to form additional hybrid embodiments of the proxy re-signature system. It is intended that the scope of the invention be limited not by this detailed description, but rather by the claims appended hereto.

Claims

1. A method for using a proxy to transform a signature of a delegatee to a signature of a delegator on a message, comprising steps for: generating a public and private key pair for the delegatee;signing a message with the delegates's signature, and verifying authenticity of the signed message using the key pair;generating a re-signature key for the delegator;delegating the re-signature key to a proxy; andcausing the proxy to transform a signature of the delegatee on the message to the signature of the delegator on the message by processing the signature of the delegatee using the re-signature key.

2. The method of claim 1 wherein generating the public and private key pair further comprises steps for using a discrete logarithm-based key generation algorithm to generate the pair of public and private keys.

3. The method of claim 1 wherein signing the message further comprises steps for signing the message by using a chain of signatures from a BLS signing process and an mBLS signing process.

4. The method of claim 1 wherein signing the message further comprises steps for signing the message by using a chain of signatures from a Waters signing process and an mWaters signing process.

5. The method of claim 1 wherein generating the re-signature key further comprises steps for using the delegator's private key in combination with the delegatee's public key to generate the re-signature key.

6. The method of claim 5 wherein the re-signature key is generated with one of a BLS-based signature process and a Waters-based signature process.

7. The method of claim 1 further comprising steps for reducing a size of the transformed signature by using a signature aggregation process.

8. The method of claim 1 wherein the key pair is temporary, such that the resulting re-signature key is also temporary and will expire after a predetermined period of time.

9. The method of claim 1 further comprising steps for determining validity of the signature of the delegator on the message.

10. The method of claim 9 the determining validity of the signature of the delegator on the message further comprises steps for verifying an entire chain of signatures, and wherein the chain of signature is one of: a chain of signatures generated by a BLS signature process and a mBLS signature process; anda chain of signatures generated by a Waters signature process and an mWaters signature process.

11. The method of claim 9 further comprising steps for terminating transformation of the signature of the delegator if the signature of the delegator on the message is determined to be invalid.

12. The method of claim 1 wherein the signature of the delegator on the message is of a signature type including one of an owner-type signature and a non-owner-type signature.

13. A system for transforming a signature of a delegatee to a signature of a delegator on a message, comprising: a device for generating a public and private key pair for the delegatee;a device for allowing a delegatee to sign a message;a device for verifying authenticity of a signature of the delegatee on the signed message using the key pair;a device for generating a re-signature key for the delegator using a combination of a private key of the delegator and the public key of the delegatee;a device for delegating the re-signature key to a proxy; anda device for transforming the signature of the delegatee on the message to the signature of the delegator on the message by using a proxy to process the signature of the delegatee using the re-signature key.

14. The system of claim 13 wherein generating the re-signature key further comprises allowing the delegator to use the delegator's private key in combination with the delegatee's public key to generate the re-signature key.

15. The system of claim 13 further comprising a device for terminating the transformation in the event that the signature of the delegatee on the signed message is not authentic.

16. The system of claim 13 further comprising a device for terminating the transformation in the event that the transformed signature of the delegator on the signed message is not authentic.

17. A computer-readable medium having computer executable instructions stored therein for using a proxy to transform a signature of a delegatee to a signature of a delegator on a message, said instructions comprising: using a signer module for generating a public and private key pair for the delegatee;providing a message with the delegates's signature;using a proxy for generating a re-signature key for the delegator from a combination of a private key of the delegator and the public key of the delegatee;delegating the re-signature key to a proxy; andcausing the proxy to transform a signature of the delegatee on the message to the signature of the delegator on the message by processing the signature of the delegatee using the re-signature key.

18. The computer-readable medium of claim 17 further using a signature verification module for verifying authenticity of the signature of the delegatee on signed message using the key pair.

19. The computer-readable medium of claim 18 further comprising terminating transformation of the signature if the signature of the delegatee is not authentic.

20. The computer-readable medium of claim 17 wherein the re-signature key is generated with one of a BLS-based signature process and a Waters-based signature process.