An enhanced pairing-free certificateless directed signature scheme.

Directed signature is a special cryptographic technique in which only the verifier designated by the signer can verify the validity of the signature. Directed signature can effectively protect the privacy of the signer's identity, so it is very suitable for medical records, taxation, and other fields. To improve the security and performance of the directed signature scheme, Gayathri et al. proposed the first certificateless directed signature (CLDS) scheme without bilinear pairing and claimed that their CLDS scheme could withstand Type I and Type II attacks. In this article, we provide two attack methods to assess the security of their CLDS scheme. Unfortunately, our results indicate that their CLDS scheme is insecure against Type I and Type II attacks. That is, their CLDS scheme does not meet the unforgeability and cannot achieve the expected security goals. To resist these attacks, we present an improved CLDS scheme and give the security proof. Compared with similar schemes, our scheme has better performance and higher security.

1 Introduction

Digital signature is one of the most important technologies for ensuring data security in insecure communication networks [1-3]. It can solve the problems of forgery, denial, impersonation and tampering. Digital signature provides trusted identity authentication [4] and data exchange services [5], so it is widely employed in smart city [6], smart transportation [7, 8], smart medicine [9, 10], smart grid [11] and other fields [12]. In traditional digital signature schemes, anyone can verify the signature’s validity by using the signer’s public key. However, in some practical circumstances (such as hospitals, shopping malls), the user’s public key is the private information that symbolizes the user’s identity. For example, patients do not want their health information shared with anybody other than their doctors, and consumers do not want their shopping information shared with anyone else. This requires that the user’s signature does not support public verification [13-15].

To accomplish these security functionalities, directed signature is introduced as a new signature technology [16]. Directed signature allows the signer to control the verifier of his or her signature. On the one hand, only the designated verifier can decide whether the signature is legitimate, while others can only check the signature’s validity with the signer’s or designated verifier’s help. On the other hand, when a disputed message occurs, the legitimacy of the signature can be proved to the third party by the signer and the designated verifier. On the basis of ordinary signature, directed signature adds the feature of safeguarding the signer’s identity privacy, preventing any third party from directly verifying the signature using the signer’s public key. As a result, directed signature is well suited to real scenarios in which the signer’s identity anonymity is required [17-19].

Since Lim and Lee [16] introduced the concept of directed signature, some directed signature schemes [20-22] based on the framework of public key infrastructure have been presented. However, these schemes require huge computational and communication overhead to manage certificates. Identity-based directed signature [23-25] does not require a certificate to authenticate the user’s public key, but a trusted key generation center (KGC) is required to produce a private key for the user. As a result, the key escrow problem exists in the identity-based directed signature scheme. In other words, KGC has the ability to sign any message on behalf of the user. To address these issues, certificateless directed signature (CLDS) is presented [26]. In CLDS, the user’s private key is created independently by a semi-trusted KGC and the user, so that KGC cannot obtain the user’s final private key. CLDS combines the benefits of both certificateless signature [27] and directed signature, making it more suitable for insecure communication network environments [28].

The first CLDS scheme was presented by Wan [26], but their scheme has poor computational performance because of the time-consuming bilinear pairing operation. To achieve high efficiency, Gayathri et al. [29] constructed a pairing-free CLDS scheme in 2021 and proved that their CLDS scheme is unforgeable against Type I and Type II attacks in the random model. However, in this article, we give two attack methods to prove that their CLDS scheme is insecure against Type I and Type II attackers. Specifically, both dishonest users and malicious KGC have the capacity to forge the legal signature of any message. This demonstrates that their CLDS scheme is riddled with security issues.

1.1 Our contribution

The following is a brief summary of our work.

We show that the CLDS scheme proposed by Gayathri et al. [29] cannot withstand Type I attackers by using an attack approach.

We show that Gayathri et al.’s CLDS scheme [29] is vulnerable to Type II attackers by employing another attack approach.

To improve security, we provide an enhanced CLDS scheme.

We give the security proof of the modified scheme. Furthermore, according to the results of the analysis, our scheme outperforms similar schemes in terms of performance and security.

1.2 Organization

The remainder of this article is structured in the following manner. Section 2 introduces some necessary preliminaries. Section 3 describes Gayathri et al.’s CLDS scheme [29] and analyzes its security in Section 4. Section 5 presents our improved CLDS scheme, as well as its security proof and performance analysis. Finally, the article’s conclusions are presented in Section 6.

2 Preliminaries

2.1 Elliptic curve group

Assume that F is a finite field. The equation y2 = x3 + ax + b defines an elliptic curve E on F that meets the condition 4a3 + 27b2 ≠ 0, where a, b ∈ F. Let O be an infinite point of E. G = {(x, y)∈E: x, y ∈ F}∪{O} is an additive elliptic curve cyclic group [30].

The security of Gayathri et al.’s CLDS scheme [29] is based on the following elliptic curve discrete logarithm problem (ECDLP).

Given xP ∈ G, the ECDLP is to calculate , where P is a generator of G.

2.2 Definition and security model of the CLDS scheme

As defined in [29], a CLDS scheme is composed of the following six algorithms.

Setup: On input a security parameter η, this algorithm is executed by KGC and outputs the master secret key and public parameters params.

Partial Secret Key Gen: On input an identity ID, this algorithm is executed by KGC and outputs a partial private key D.

User Key Gen: The user runs this algorithm to generate its public key PK and secret key SK.

Signature Generation: Given a message m and a public key PK of a designated verifier, a signer uses its secret key SK and public key PK to generate a signature σ of m.

Direct Verification: On input a signature σ of m and the signer’s public key-identity pair (PK, ID), the designated verifier uses its secret key SK to check the validity of the signature. This algorithm outputs accept if σ is legal; otherwise, it outputs reject.

Public Verification: Given a signature σ of m, a value Aid calculated by the signer or the designated verifier, the signer’s public key-identity pair (PK, ID) and the designated verifier’s public key-identity pair (PK, ID), this algorithm outputs accept if σ is legal; otherwise, it outputs reject.

As discussed in [26, 29], a secure CLDS scheme must resist the following two types of attackers.

Type I Attacker : It is an external adversary who can launch the public key replacement attack on any user. However, cannot obtain KGC’s master secret key.

Type II Attacker : It is a malicious KGC that can create the partial private key of any user and modify the values of system parameters, but cannot replace the user’s public key and obtain the user’s secret key.

To describe the unforgeability of a CLDS scheme, the following oracles are defined by security games between the challenger and the adversary.

Reveal Partial Secret Key Oracle : On receiving an identity ID from the adversary, the challenger obtains D by running the Partial Secret Key Gen algorithm and returns it to the adversary.

Create User Oracle : When receiving an identity ID from the adversary, the challenger obtains a public key PK by running the User Key Gen algorithm and returns it to the adversary.

Reveal Secret Key Oracle : On receiving an identity ID from the adversary, the challenger obtains a secret key SK by running the User Key Gen algorithm and returns it to the adversary.

Replace Public Key Oracle : On receiving a tuple from from the adversary, the challenger replaces (x, PK) of ID with , respectively.

Sign Oracle : When receiving two identities (ID, ID) and a message m from the adversary, the challenger obtains a signature σ of m by running the Signature Generation algorithm and returns it to the adversary.

D. Verify Oracle : When receiving two identities (ID, ID), a message m and a signature σ from the adversary, the challenger runs the Direct Verification algorithm and returns the corresponding output to the adversary.

P. Verify Oracle : When receiving two identities (ID, ID), a message m and a signature σ from the adversary, the challenger runs the Public Verification algorithm and returns the corresponding output to the adversary.

Game 1: The adversary in this game is a Type I attacker .

Initialization Phase: The challenger runs the Setup algorithm and sends params to .

Queries Phase: is allowed to adaptively query seven oracles , , , , , and .

Forgery Phase: Eventually, outputs a tuple . wins in this game if σ* is a valid signature on m* under and , and the following conditions hold.

The oracle has never been involved for .

The oracle has never been involved for .

Game 2: The adversary in this game is a Type II attacker .

Initialization Phase: runs the Setup algorithm, and sends the master secret key and params to the challenger.

Queries Phase: is allowed to adaptively query the oracles , , , and .

Forgery Phase: Eventually, outputs a tuple . wins in this game if σ* is a valid signature on m* under and , and the following conditions hold.

The oracle has never been involved for .

The oracle has never been involved for .

Definition 1. A CLDS scheme is said to be existentially unforgeable, if there is no polynomial time attacker ( and ) can win in the above two games with a non-negligible probability.

3 Review of Gayathri et al.’s CLDS scheme

In this section, Gayathri et al.’s CLDS scheme [29] is briefly described as follows.

Setup: KGC selects an elliptic curve group G of prime order q and a generator P. Then, KGC randomly selects , calculates P = sP, and sets the master secret key as msk = s. Next, KGC selects three hash functions . Finally, KGC publicly broadcasts the parameters params = {G, q, P, H1, H2, H3, P}.

Partial Secret Key Gen: Given the identity ID of a user, KGC does as follows.

Select at random and calculate R = r P.

Calculate h1 = H1(ID, R, P).

Calculate d = r + h1 s mod q.

Send the partial private key D = (R, d) to the user secretly.

After receiving D from KGC, the user checks the validity of its partial private key through the following equation.

User Key Gen: A user with identity ID does as follows.

Select randomly and calculate X = x P.

Set its secret key as SK = (x, d).

Set its public key as PK = (X, R).

Signature Generation: Given the public key PK and identity ID of a designated verifier, a signer with identity ID performs the following operations to sign a message m.

Select randomly, and calculate U = t1 P and V = t2 P.

Calculate W = U + t2 X.

Calculate h2 = H2(m, ID, ID, U, R) and h3 = H3(m, ID, ID, U, R, h2) by using its identity ID and public key PK = (X, R).

Calculate k = h2 d + h3 t2 + h2 x mod q by using its secret key SK = (x, d).

Set σ = (k, W, V) as the signature of m.

Direct Verification: After receiving a signature σ = (k, W, V) on a message m from a signer with identity ID, a designated verifier with identity ID performs the following operations to verify the validity of the signature.

Calculate Y = W − x V = U by using its secret key SK = (x, d).

Calculate h2 = H2(m, ID, ID, Y, R).

Calculate h3 = H3(m, ID, ID, Y, R, h2).

Verify the following signature verification equation.

If it holds, σ is valid and accepted by the verifier; else, the verifier rejects σ.

Public Verification: Given a signature σ = (k, W, V) on a message m under two identities ID and ID, any third party does as follows.

Obtain the value Aid = U = Y calculated by the signer with ID or the verifier with ID.

Calculate h2 = H2(m, ID, ID, Aid, R).

Calculate h3 = H3(m, ID, ID, Aid, R, h2).

Verify the following signature verification equation.

If it holds, σ is valid; else, σ is invalid.

4 Security analysis of Gayathri et al.’s CLDS scheme

In [29], Gayathri et al. claimed that their CLDS scheme could withstand Type I and Type II attackers. In this section, we give two concrete attack methods to prove that their CLDS scheme is insecure against Type I and Type II attacks. As a result, their CLDS scheme has serious security weaknesses.

4.1 Type I attack

A Type I attacker selects a target user whose identity and public key are ID and PK = (X, R), respectively. can forge the valid signature of any selected message by replacing the public key of the target user. Let the identity and public key of the designated verifier be ID and PK = (X, R), respectively. initiates the following attack operations.

Calculate h1 = H1(ID, R, P).

Randomly select and calculate

Replace the previous public key PK of the target user with the new public key .

Randomly select , and calculate , and .

Select a message m*, and calculate and .

Calculate .

Output as a forged signature of m*.

The following equation shows that the signature forged by is considered valid and accepted by the verifier with identity ID, because

Then, we have

Therefore, the forged signature meets the signature verification equation in the Direct Verification algorithm. During the above-mentioned attack, does not gain any knowledge about the target user’s partial private key. That is, ’s attack against the CLDS scheme of Gayathri et al. [29] is successful. As a result, Gayathri et al.’s CLDS scheme [29] is insecure against Type I attacks.

4.2 Type II attack

Assume that ID and PK = (X, R) are the identity and public key of the target user attacked by a Type II attacker , respectively. Let the identity and public key of the designated verifier be ID and PK = (X, R), respectively. knows the master secret key s, so can calculate the target user’s partial private key and modify system parameters. performs the following attack operations to forge the valid signature of any message.

Randomly select and calculate

Replace the previous value R with the new value .

Calculate .

Select randomly, and calculate , and .

Select a message m′, and calculate and .

Calculate .

Output as a forged signature of m′.

The signature forged by is considered legal and accepted by the verifier whose identity is ID, because

It is easy to derive the following equation from the above equation.

This demonstrate that the forged signature satisfies the signature verification equation in the Direct Verification algorithm. In the above attack, the secret key x of the target user is unknown to . Therefore, ’s forgery attack against the CLDS scheme of Gayathri et al. [29] is successful. In other words, Gayathri et al.’s CLDS scheme [29] is also insecure against Type II attacks.

5 Our improved CLDS scheme

The reason why Gayathri et al.’s CLDS scheme [29] cannot resist the public key replacement attack is that does not require the target user’s partial private key for forging the signature. Furthermore, the reason why Gayathri et al.’s CLDS scheme [29] cannot withstand Type II attacks is that avoids the target user’s secret key by changing the value R.

5.1 Our construction

To resist the two types of forgery attacks, we modify the CLDS scheme of Gayathri et al. [29] as follows.

The Setup algorithm is the same as the corresponding algorithm in the original scheme, and the only difference is to add a hash function .

The algorithms Partial Secret Key Gen and User Key Gen are the same as the corresponding algorithms in the original scheme.

In the Signature Generation algorithm, a value h4 = H4(m, ID, ID, U, V, PK, PK, h2) is added, and the values of h2 and h3 are modified to two new values h2 = H2(m, ID, ID, U, V, P) and h3 = H3(m, ID, ID, U, V, h2) respectively. The corresponding value k is modified to and the signature of a message m is σ = (k, W, V).

The algorithms Direct Verification and Public Verification are the same as the corresponding algorithms in the original scheme. The only difference is that the verifier needs to calculate h2, h3 and h4, and verifies σ by using the following equation:

Correctness:

5.2 Security proof

In our CLDS scheme, adequate redundant values are added to the input parameters of the three hash functions h2, h3 and h4. By altering some public values, Type I and Type II attackers will be unable to forge valid signatures. The following theorems 1 and 2 provide the security proof for the improved CLDS scheme.

Theorem 1. If the ECDLP is intractable, then our improved CLDS scheme is unforgeable against Type I attacks.

Proof. Let be a Type I attacker. If can forge a legal signature of the improved scheme, then we construct an algorithm that can solve the ECDLP. Note that serves as the challenger in Game 1 (as stated in Section 2.2). Suppose that obtains an ECDLP instance (P, αP). To calculate the unknown by using the forgery of , plays the following interactive game with .

Initialization Phase: generates system parameters params = {G, q, P, H1, H2, H3, P} by executing the Setup algorithm, where P = αP. The assignment of P indicates that the master secret key is α, but does not know α. Then, selects a target user’s identity ID*, and sends params to .

Queries Phase: responds to ’s various queries by establishing the following oracles.

: creates a list L1 of tuple (ID, R, P, h1) whose initial value is empty. When initiates a query H1(ID, R, P), returns h1 to if L1 contains the tuple (ID, R, P, h1). Otherwise, randomly selects , adds (ID, R, P, h1) to L1, and returns h1 to .

: creates a list L2 of tuple (m, ID, ID, U, V, P, h2) whose initial value is empty. When initiates a query H2(m, ID, ID, U, V, P), returns h2 to if L2 contains the tuple (m, ID, ID, U, V, P, h2). Otherwise, randomly selects , adds (m, ID, ID, U, V, P, h2) to L2, and returns h2 to .

: creates a list L3 of tuple (m, ID, ID, U, V, h2, h3) whose initial value is empty. When initiates a query H3(m, ID, ID, U, V, h2), returns h3 to if L3 contains the tuple (m, ID, ID, U, V, h2, h3). Otherwise, randomly selects , adds (m, ID, ID, U, V, h2, h3) to L3, and returns h3 to .

: creates a list L4 of tuple (m, ID, ID, U, V, PK, PK, h2, h4) whose initial value is empty. When initiates a query H4(m, ID, ID, U, V, PK, PK, h2), returns h4 to if L4 contains the tuple (m, ID, ID, U, V, PK, PK, h2, h4). Otherwise, randomly selects , adds (m, ID, ID, U, V, PK, PK, h2, h4) to L4, and returns h4 to .

Reveal Partial Secret Key Oracle : creates a list L of tuple (ID, d, R, r) whose initial value is empty. returns D = (R, d) to if L contains the tuple (ID, d, R, r). Otherwise, executes as follows.

If ID = ID*, randomly selects , sets d* = ⊥, calculates R* = r* P, adds (ID*, d*, R*, r*) to L, and returns D* = (d*, R*) to .

If ID ≠ ID*, randomly selects , calculates R = d P − h1 P, adds (ID, R, P, h1) to L1, records (ID, d, R, r) in L, and returns D = (R, d) to .

Create User Oracle : creates a list L of tuple (ID, x, X, SK, PK) whose initial value is empty. When receiving an identity ID from , returns PK to if L contains the tuple (ID, x, X, SK, PK). Otherwise, randomly selects , retrieves d and R from the tuple (ID, d, R, r) in L, calculates X = x P, sets SK = (x, d) and PK = (X, R), adds (ID, x, X, SK, PK) to L, and returns PK to .

Reveal Secret Key Oracle : On receiving an identity ID from , finds the tuple (ID, x, X, SK, PK) from L to recover SK, and then returns SK to .

Replace Public Key Oracle : On receiving a tuple from , looks for the tuple (ID, x, X, SK, PK) from L, and then replaces x and PK with and , respectively.

Sign Oracle : When receiving two identities (ID, ID) and a message m from , does as follows.

If ID ≠ ID*, runs the algorithm Signature Generation to produce a signature σ = (k, W, V) of m, and returns it to .

If ID = ID*, randomly selects , searches the tuple (ID*, x*, X*, SK*, PK*) in L to recover PK* = (X*, R*), looks for the tuple (ID, x, X, SK, PK) in L to retrieve x and PK = (X, R), and finds the tuple in L1 to retrieve . Then, calculates W = t P, and U = W − x V, sets σ = (k, W, V), and sends the signature σ to . Finally, records (m, ID, ID, U, V, P, h2), (m, ID, ID, U, V, h2, h3) and (m, ID, ID, U, V, PK, PK, h2, h4) in lists L2, L3 and L4, respectively.

D. Verify Oracle : When receiving two identities (ID, ID), a message m and a signature σ from , runs the algorithm Direct Verification and returns the corresponding output to .

P. Verify Oracle : When receiving two identities (ID, ID), a message m and a signature σ from , runs the algorithm Public Verification and returns the corresponding output to .

Forgery Phase: Finally, outputs a legal signature for a message under the target user’s identity ID* and public key PK*. According to Forking Lemma [31], uses the same random tape to replay and assigns a different value to the hash function H2, then generates another signature of that satisfies , and . Since and are two legal signatures, we get the following equations.

From Eqs (1) and (2), we have

Thus, we use Eqs (3) and (4) to calculate

From Eq (5), we can get the solution α of the given ECDLP instance. However, ECDLP is a difficult problem that cannot be solved in polynomial time, so it can be inferred that the above forgery attack initiated by is not feasible. Therefore, our improved CLDS scheme is unforgeable against the Type I attacker.

Theorem 2. If the ECDLP is intractable, then our improved CLDS scheme is unforgeable against Type II attacks.

Proof. Let be a Type II attacker. If can forge a legal signature of the improved scheme, then we construct an algorithm that can solve the ECDLP. Note that acts as the challenger in Game 2 (as defined in Section 2.2). Suppose that obtains an ECDLP instance (P, αP). To calculate the unknown by using the forgery of , plays the following interactive game with .

Initialization Phase: randomly selects , calculates P = sP, and sets s as the master secret key. Then, executes the Setup algorithm to produce system parameters params. Finally, sends params and s to . Let ID* is the identity of the target user selected by .

Queries Phase: responds to ’s various queries by establishing the following oracles.

The oracles , , and are the same as in Theorem 1.

Create User Oracle : creates a list L of tuple (ID, d, R, x, X, SK, PK) whose initial value is empty. When receiving an identity ID from , returns PK to if L contains the tuple (ID, d, R, x, X, SK, PK). Otherwise, runs the algorithm Partial Secret Key Gen to create a partial private key D = (R, d), and then performs the following operations.

If ID = ID*, sets x* = ⊥ and X* = αP. Then, sets SK* = (x*, d* = d) and PK* = (X*, R* = R). Next, adds (ID*, d*, R*, x*, X*, SK*, PK*) to L, and returns PK* to .

If ID ≠ ID*, randomly selects , calculates X = x P, sets SK = (x, d) and PK = (X, R), adds (ID, d, R, x, X, SK, PK) to L, and returns PK to .

Reveal Secret Key Oracle : On receiving an identity ID from , finds the tuple (ID, d, R, x, X, SK, PK) from L to recover SK, and then returns SK to .

Sign Oracle : creates a list L of tuple (m, ID, ID*, V, W, t2) whose initial value is empty. When receiving two identities (ID, ID) and a message m from , does as follows.

If ID ≠ ID* and ID ≠ ID*, runs the algorithm Signature Generation to produce a signature σ = (k, W, V) of m.

If ID ≠ ID* and ID = ID*, randomly selects and calculates U = t1 P, V = t2 P and W = U − t2 X*. Then, runs the algorithm Signature Generation to generate a signature σ = (k, W, V) of m. Finally, records (m, ID, ID*, V, W, t2) in L.

If ID = ID* and ID ≠ ID*, randomly selects , searches the tuple (ID*, d*, R*, x*, X*, SK*, PK*) in L to recover PK* = (X*, R*), looks for the tuple (ID, d, R, x, X, SK, PK) in L to retrieve x and PK = (X, R), and finds the tuple in L1 to retrieve . Then, calculates W = t P, and U = W − x V, and sets σ = (k, W, V).

If ID = ID* and ID = ID*, randomly selects , searches the tuple (ID*, d*, R*, x*, X*, SK*, PK*) in L to recover PK* = (X*, R*), and finds the tuple in L1 to retrieve . Then, calculates W = t P, and U = W − t2 X*, and sets σ = (k, W, V). Finally, records (m, ID*, ID*, V, W, t2) in L.

sends the final signature σ to . Moreover, records (m, ID, ID, U, V, P, h2), (m, ID, ID, U, V, h2, h3) and (m, ID, ID, U, V, PK, PK, h2, h4) in lists L2, L3 and L4, respectively.

D. Verify Oracle : When receiving two identities (ID, ID), a message m and a signature σ from , determines whether ID = ID*. If it holds, finds the tuple (m, ID, ID*, V, W, t2) from L to extract t2 and calculates Y = U = W − t2 X*. Then, runs the algorithm Direct Verification and returns the corresponding output to .

P. Verify Oracle : When receiving two identities (ID, ID), a message m and a signature σ from , determines whether ID = ID*. If it holds, finds the tuple (m, ID, ID*, V, W, t2) from L to extract t2 and calculates Aid = Y = U = W − t2 X*. Then, runs the algorithm Public Verification and returns the corresponding output to .

Forgery Phase: Finally, outputs a legal signature for a message under the target user’s identity ID* and public key PK*. According to Forking Lemma [31], uses the same random tape to replay and assigns a different value to the hash function H4, then generates another signature of that satisfies , . Since and are two legal signatures, we get the following equations.

From Eqs (6) and (7), we have

Thus, we utilize Eqs (8) and (9) to calculate

From Eq (10), we can obtain the solution α of the given ECDLP instance. Since ECDLP is a hard mathematical problem, the aforementioned forgery attack initiated by is not feasible. Therefore, our improved CLDS scheme is unforgeable against the Type II attacker.

5.3 Performance analysis

We evaluate the computational and communication costs of the enhanced CLDS scheme and similar schemes. The execution time of various cryptographic operations is given in [32], and a summary of all operations is shown in S1 Table. In the following performance comparisons, we don’t consider modular multiplication and modular addition in because their computational overhead is so negligible.

In Azees et al.’s scheme [4] and Ahamed et al.’s scheme [7], the computational cost of calculating a signature is T + T = 0.167001 ms, whereas the computational cost of verifying a signature is 2T + T + T + T = 9.050491 ms. Hence, the total computational overhead is 9.217492 ms. These two schemes [4, 7] have high signature generation efficiency. Unfortunately, none of them are CLDS schemes.

In Wan et al.’s CLDS scheme [26], the computational overhead of the algorithm Signature Generation is 5T + T + 2T + 2T + T = 5.557464 ms, the computational overhead of the algorithm Direct Verification is 3T + 2T + 2T = 13.612061 ms, whereas the computational overhead of the algorithm Public Verification is 2T + T + 2T = 9.028336 ms. Hence, the total computational overhead is 28.197861 ms.

In Gayathri et al.’s CLDS scheme [29], the computational overhead of the algorithm Signature Generation is 3T + 2T + T = 0.500623 ms, the computational overhead of the algorithm Direct Verification is 5T + 3T + 4T = 0.837053 ms, whereas the computational overhead of the algorithm Public Verification is 5T + 3T + 3T = 0.835649 ms. Hence, the total computational overhead is 2.173325 ms.

In our CLDS scheme, the computational overhead of the algorithm Signature Generation is 3T + 3T + T = 0.502407 ms, the computational overhead of the algorithm Direct Verification is 6T + 4T + 4T = 1.004054 ms, whereas the computational overhead of the algorithm Public Verification is 6T + 4T + 3T = 1.002650 ms. Hence, the total computational overhead is 2.509111 ms.

The comparison results of the computational overhead between our CLDS scheme and the other CLDS schemes are shown in S1 Fig. As shown in S1 Fig, the computational cost of our scheme is less than that of Wan et al.’s scheme [26], and is almost equal to that of Gayathri et al.’s scheme [29]. However, we demonstrate in Section 4 that Gayathri et al.’s scheme [29] is insecure, and that our enhanced CLDS scheme can withstand Type I and II forgery attacks.

Similar to the evaluation of communication overhead in [32], a bilinear pairing e: G1 × G1 → G2 is selected, where the length of an element in G1 is 1024 bits. In the elliptic curve cryptosystem, the length of the prime number q is 160 bits, while the length of an element in the group G is 320 bits. The signature length of Azees et al.’s scheme [4] is |G1| = 1024 bits = 128 bytes, the signature length of Ahamed et al.’s scheme [7] is |G1| = 128 bytes, the signature length of Wan et al.’s scheme [26] is 4|G1| = 4 × 1024 = 4096 bits = 512 bytes, the signature length of Gayathri et al.’s scheme [29] is 2|G| + |q| = 2 × 320 + 160 = 800 bits = 100 bytes, whereas the signature length of our scheme is also 2|G| + |q| = 100 bytes. Obviously, our CLDS scheme has shorter signature length than other schemes [4, 7, 26]. The comparison results of the communication overhead of the three CLDS schemes are given in S2 Fig. Therefore, our CLDS scheme has better performance and higher security.

6 Conclusions

Directed signature can ensure data security as well as the signer’s identity privacy, so it is very suitable for practical applications such as medical records and tax information. Gayathri et al. [29] devised and proved the first pairing-free CLDS scheme. However, in this article, we analyze the security of their CLDS scheme and find that their scheme is insecure against Type I and Type II attackers. Therefore, their CLDS scheme suffers from significant security flaws. To address the security issues, we give an enhanced CLDS scheme. The results of comparison with related schemes show that our scheme has higher security while keeping the original scheme’s performance, so it is more suitable for practical scenarios.

(XLSX)

Click here for additional data file.

The execution time of cryptographic operations.

(PDF)

Click here for additional data file.

Comparison of the computational cost of CLDS schemes.

(PDF)

Click here for additional data file.

Comparison of communication overhead of CLDS schemes.

(PDF)

Click here for additional data file.

4 Jan 2022

A rebuttal letter that responds to each point raised by the academic editor and reviewer(s). You should upload this letter as a separate file labeled 'Response to Reviewers'.

A marked-up copy of your manuscript that highlights changes made to the original version. You should upload this as a separate file labeled 'Revised Manuscript with Track Changes'.

An unmarked version of your revised paper without tracked changes. You should upload this as a separate file labeled 'Manuscript'.

If you would like to make changes to your financial disclosure, please include your updated statement in your cover letter. Guidelines for resubmitting your figure files are available below the reviewer comments at the end of this letter.

If applicable, we recommend that you deposit your laboratory protocols in protocols.io to enhance the reproducibility of your results. Protocols.io assigns your protocol its own identifier (DOI) so that it can be cited independently in the future. For instructions see: https://journals.plos.org/plosone/s/submission-guidelines#loc-laboratory-protocols. Additionally, PLOS ONE offers an option for publishing peer-reviewed Lab Protocol articles, which describe protocols hosted on protocols.io. Read more information on sharing protocols at https://plos.org/protocols?utm_medium=editorial-email&utm_source=authorletters&utm_campaign=protocols.

We look forward to receiving your revised manuscript.

Kind regards,

Pandi Vijayakumar, Ph.D

Academic Editor

PLOS ONE

Journal Requirements:

When submitting your revision, we need you to address these additional requirements.

1. Please ensure that your manuscript meets PLOS ONE's style requirements, including those for file naming. The PLOS ONE style templates can be found at

https://journals.plos.org/plosone/s/file?id=wjVg/PLOSOne_formatting_sample_main_body.pdf and

https://journals.plos.org/plosone/s/file?id=ba62/PLOSOne_formatting_sample_title_authors_affiliations.pdf

2. In your Data Availability statement, you have not specified where the minimal data set underlying the results described in your manuscript can be found. PLOS defines a study's minimal data set as the underlying data used to reach the conclusions drawn in the manuscript and any additional data required to replicate the reported study findings in their entirety. All PLOS journals require that the minimal data set be made fully available. For more information about our data policy, please see http://journals.plos.org/plosone/s/data-availability.

Upon re-submitting your revised manuscript, please upload your study’s minimal underlying data set as either Supporting Information files or to a stable, public repository and include the relevant URLs, DOIs, or accession numbers within your revised cover letter. For a list of acceptable repositories, please see http://journals.plos.org/plosone/s/data-availability#loc-recommended-repositories. Any potentially identifying patient information must be fully anonymized.

Important: If there are ethical or legal restrictions to sharing your data publicly, please explain these restrictions in detail. Please see our guidelines for more information on what we consider unacceptable restrictions to publicly sharing data: http://journals.plos.org/plosone/s/data-availability#loc-unacceptable-data-access-restrictions. Note that it is not acceptable for the authors to be the sole named individuals responsible for ensuring data access.

We will update your Data Availability statement to reflect the information you provide in your cover letter.

3. PLOS requires an ORCID iD for the corresponding author in Editorial Manager on papers submitted after December 6th, 2016. Please ensure that you have an ORCID iD and that it is validated in Editorial Manager. To do this, go to ‘Update my Information’ (in the upper left-hand corner of the main menu), and click on the Fetch/Validate link next to the ORCID field. This will take you to the ORCID site and allow you to create a new iD or authenticate a pre-existing iD in Editorial Manager. Please see the following video for instructions on linking an ORCID iD to your Editorial Manager account: https://www.youtube.com/watch?v=_xcclfuvtxQ

Additional Editor Comments:

Based on the comments of the reviewers, I recommend major revision for this paper.

[Note: HTML markup is below. Please do not edit.]

Reviewers' comments:

Reviewer's Responses to Questions

Comments to the Author

1. Is the manuscript technically sound, and do the data support the conclusions?

The manuscript must describe a technically sound piece of scientific research with data that supports the conclusions. Experiments must have been conducted rigorously, with appropriate controls, replication, and sample sizes. The conclusions must be drawn appropriately based on the data presented.

Reviewer #1: Yes

Reviewer #2: Yes

**********

2. Has the statistical analysis been performed appropriately and rigorously?

Reviewer #1: Yes

Reviewer #2: Yes

**********

3. Have the authors made all data underlying the findings in their manuscript fully available?

The PLOS Data policy requires authors to make all data underlying the findings described in their manuscript fully available without restriction, with rare exception (please refer to the Data Availability Statement in the manuscript PDF file). The data should be provided as part of the manuscript or its supporting information, or deposited to a public repository. For example, in addition to summary statistics, the data points behind means, medians and variance measures should be available. If there are restrictions on publicly sharing data—e.g. participant privacy or use of data from a third party—those must be specified.

Reviewer #1: Yes

Reviewer #2: Yes

**********

4. Is the manuscript presented in an intelligible fashion and written in standard English?

PLOS ONE does not copyedit accepted manuscripts, so the language in submitted articles must be clear, correct, and unambiguous. Any typographical or grammatical errors should be corrected at revision, so please note any specific errors here.

Reviewer #1: Yes

Reviewer #2: Yes

**********

5. Review Comments to the Author

Please use the space provided to explain your answers to the questions above. You may also include additional comments for the author, including concerns about dual publication, research ethics, or publication ethics. (Please upload your review as an attachment if it exceeds 20,000 characters)

Reviewer #1: The author is required to analyse the following security related papers in the introduction section. Moreover, the computational cost of the proposed work should be compared with the following papers

1EAAP: Efficient anonymous authentication with conditional privacy-preserving scheme for vehicular ad hoc networks

Dual authentication and key management techniques for secure data transmission in vehicular ad hoc networks

An efficient anonymous mutual authentication technique for providing secure communication in mobile cloud computing for smart city applications

An efficient anonymous authentication and confidentiality preservation schemes for secure communications in wireless body area networks

EMBA: An efficient anonymous mutual and batch authentication schemes for vanets

BBAAS: Blockchain-Based Anonymous Authentication Scheme for Providing Secure Communication in VANETs

Reviewer #2: The author has made a genuine attempt to analyze the security of the previously proposed work on certificate less directed signature by Gayathri et al., using the Type I and Type II attacks. With necessary supporting proof for the previous work being susceptible to the attacks, the author has also proposed an enhanced version of the previous work which ensures the needed security. The author has introduced necessary redundant values to the input parameters of the hash functions to avoid the attacks. The author has given enough security analysis and also, the performance analysis suggests that, the work is novel and is suitable for publication in our journal.

But, I kindly request the author to give the following relevant works as citations in the proposed work to add value to its significance.

(i) Efficient NTRU Lattice-Based Certificateless Signature Scheme for Medical Cyber-Physical Systems

(ii) A practical group blind signature scheme for privacy protection in smart grid

(iii) Efficient and Secure Anonymous Authentication With Location Privacy for IoT-Based WBANs

**********

6. PLOS authors have the option to publish the peer review history of their article (what does this mean?). If published, this will include your full peer review and any attached files.

If you choose “no”, your identity will remain anonymous but your review may still be made public.

Do you want your identity to be public for this peer review? For information about this choice, including consent withdrawal, please see our Privacy Policy.

Reviewer #1: No

Reviewer #2: No

[NOTE: If reviewer comments were submitted as an attachment file, they will be attached to this email and accessible via the submission site. Please log into your account, locate the manuscript record, and check for the action link "View Attachments". If this link does not appear, there are no attachment files.]

While revising your submission, please upload your figure files to the Preflight Analysis and Conversion Engine (PACE) digital diagnostic tool, https://pacev2.apexcovantage.com/. PACE helps ensure that figures meet PLOS requirements. To use PACE, you must first register as a user. Registration is free. Then, login and navigate to the UPLOAD tab, where you will find detailed instructions on how to use the tool. If you encounter any issues or have any questions when using PACE, please email PLOS at figures@plos.org. Please note that Supporting Information files do not need this step.

20 Jan 2022

We have uploaded a rebuttal letter in response to every point raised by the academic editor and reviewers, labeled 'Response to Reviewers'.

Submitted filename: Response to Reviewers.pdf

Click here for additional data file.

31 Jan 2022

An enhanced pairing-free certificateless directed signature scheme

PONE-D-21-34945R1

Dear Dr. Yang,

We’re pleased to inform you that your manuscript has been judged scientifically suitable for publication and will be formally accepted for publication once it meets all outstanding technical requirements.

Within one week, you’ll receive an e-mail detailing the required amendments. When these have been addressed, you’ll receive a formal acceptance letter and your manuscript will be scheduled for publication.

An invoice for payment will follow shortly after the formal acceptance. To ensure an efficient process, please log into Editorial Manager at http://www.editorialmanager.com/pone/, click the 'Update My Information' link at the top of the page, and double check that your user information is up-to-date. If you have any billing related questions, please contact our Author Billing department directly at authorbilling@plos.org.

If your institution or institutions have a press office, please notify them about your upcoming paper to help maximize its impact. If they’ll be preparing press materials, please inform our press team as soon as possible -- no later than 48 hours after receiving the formal acceptance. Your manuscript will remain under strict press embargo until 2 pm Eastern Time on the date of publication. For more information, please contact onepress@plos.org.

Kind regards,

Pandi Vijayakumar, Ph.D

Academic Editor

PLOS ONE

Additional Editor Comments (optional):

Reviewers' comments:

Reviewer's Responses to Questions

Comments to the Author

1. If the authors have adequately addressed your comments raised in a previous round of review and you feel that this manuscript is now acceptable for publication, you may indicate that here to bypass the “Comments to the Author” section, enter your conflict of interest statement in the “Confidential to Editor” section, and submit your "Accept" recommendation.

Reviewer #1: All comments have been addressed

Reviewer #2: All comments have been addressed

**********

2. Is the manuscript technically sound, and do the data support the conclusions?

The manuscript must describe a technically sound piece of scientific research with data that supports the conclusions. Experiments must have been conducted rigorously, with appropriate controls, replication, and sample sizes. The conclusions must be drawn appropriately based on the data presented.

Reviewer #1: Yes

Reviewer #2: Yes

**********

3. Has the statistical analysis been performed appropriately and rigorously?

Reviewer #1: Yes

Reviewer #2: Yes

**********

4. Have the authors made all data underlying the findings in their manuscript fully available?

The PLOS Data policy requires authors to make all data underlying the findings described in their manuscript fully available without restriction, with rare exception (please refer to the Data Availability Statement in the manuscript PDF file). The data should be provided as part of the manuscript or its supporting information, or deposited to a public repository. For example, in addition to summary statistics, the data points behind means, medians and variance measures should be available. If there are restrictions on publicly sharing data—e.g. participant privacy or use of data from a third party—those must be specified.

Reviewer #1: Yes

Reviewer #2: Yes

**********

5. Is the manuscript presented in an intelligible fashion and written in standard English?

PLOS ONE does not copyedit accepted manuscripts, so the language in submitted articles must be clear, correct, and unambiguous. Any typographical or grammatical errors should be corrected at revision, so please note any specific errors here.

Reviewer #1: Yes

Reviewer #2: Yes

**********

6. Review Comments to the Author

Please use the space provided to explain your answers to the questions above. You may also include additional comments for the author, including concerns about dual publication, research ethics, or publication ethics. (Please upload your review as an attachment if it exceeds 20,000 characters)

Reviewer #1: (No Response)

Reviewer #2: (No Response)

**********

7. PLOS authors have the option to publish the peer review history of their article (what does this mean?). If published, this will include your full peer review and any attached files.

If you choose “no”, your identity will remain anonymous but your review may still be made public.

Do you want your identity to be public for this peer review? For information about this choice, including consent withdrawal, please see our Privacy Policy.

Reviewer #1: No

Reviewer #2: No

8 Feb 2022

PONE-D-21-34945R1

An enhanced pairing-free certificateless directed signature scheme

Dear Dr. Yang:

I'm pleased to inform you that your manuscript has been deemed suitable for publication in PLOS ONE. Congratulations! Your manuscript is now with our production department.

If your institution or institutions have a press office, please let them know about your upcoming paper now to help maximize its impact. If they'll be preparing press materials, please inform our press team within the next 48 hours. Your manuscript will remain under strict press embargo until 2 pm Eastern Time on the date of publication. For more information please contact onepress@plos.org.

If we can help with anything else, please email us at plosone@plos.org.

Thank you for submitting your work to PLOS ONE and supporting open access.

Kind regards,

PLOS ONE Editorial Office Staff

on behalf of

Dr. Pandi Vijayakumar

Academic Editor

PLOS ONE