New Secure and Practical E-Mail Protocol with Perfect Forward Secrecy

: The invention of electronic mail (e-mail) has made communication through the Internet easier than before. However, because the fundamental functions of the Internet are built on open-source technologies, it is critical to keep all transmitted e-mail secure and secret. Most current e-mail protocols only allow recipients to check their e-mail after the recipients are authenticated by the e-mail server. Unfortunately, the subsequent e-mail transmission from the server to the recipient remains unprotected in the clear form without encryption. Sometimes, this is not allowed, especially in consideration of issues such as conﬁdentiality and integrity. In this paper, we propose a secure and practical e-mail protocol with perfect forward secrecy, as well as a high security level, in which the session keys used to encrypt the last e-mail will not be disclosed even if the long-term secret key is compromised for any possible reason. Thus, the proposed scheme beneﬁts from the following advantages: (1) providing mutual authentication to remove the threat of not only impersonation attacks, but also spam; (2) guaranteeing conﬁdentiality and integrity while providing the service of perfect forward secrecy; (3) simplifying key management by avoiding the expense of public key infrastructure involvement; and (4) achieving lower computational cost while meeting security criteria compared to the related works. The security analysis and the discussion demonstrate that the proposed scheme works well.

. The common e-mail protocol, with confidentiality and authentication.
In order to achieve authentication, the digital signature service provided by PGP is as follows: The sender A computes the signature {ℎ( )} (the used notations are described in the first table below). In order to achieve confidentiality, the above message ||{ℎ( )} is encrypted. The sender computes the ciphertext [ ||{ℎ( )} ] , which is appended with { } . Finally, [ ||{ℎ( )} ] ||{ } is sent to the recipient B. The recipient B obtains the message encryption key k by decrypting { } using his/her private key PRB to decrypt [ ||{ℎ( )} ] . With the signature {ℎ( )} , the recipient can verify the integrity and the origin of message M.
If the long-term secret key of the recipient is compromised, all previously used shortterm secret keys will be disclosed in such a way that all past corresponding e-mails will be readable. Some research has therefore been conducted to provide a strong e-mail protocol to guarantee perfect forward secrecy (PFS).
In 2005, Sun et al. [16] proposed two strong-security e-mail protocols with PFS. Unfortunately, Dent [17] pointed out that the second protocol in Sun et al.'s schemes failed to provide the PFS service as claimed. Subsequently, Phan's cryptanalysis in [18] showed that replay attacks and unknown key-share attacks did take place in both Sun's first and second protocols. Furthermore, Kim et al. [19] proposed a further two robust protocols with PFS, in which the additional short-term key is generated by Diffie-Hellman key exchange. The authors claimed that the exposure of the long-term key would not disclose the secrecy of the previous session keys. Unfortunately, in 2007, Yoon and Yoo [20] pointed out that the second protocol of Kim et al.'s schemes was susceptible to sender impersonation and server impersonation attacks. Recently, Zhang and Hua proposed a new ID-based authenticated e-mail protocol with PFS [21]. Unfortunately, their scheme employed pairing computations in both the sending and receiving phases. As has been demonstrated, it is not a good idea to perform bilinear pairings via mobile device [22]. In 2015, Toorani [23] presented the cryptanalysis of a new, widely used e-mail protocol with PFS proposed by Chen and Wu [24], showing that Chen and Wu's scheme is vulnerable If the long-term secret key of the recipient is compromised, all previously used shortterm secret keys will be disclosed in such a way that all past corresponding e-mails will be readable. Some research has therefore been conducted to provide a strong e-mail protocol to guarantee perfect forward secrecy (PFS).
In 2005, Sun et al. [16] proposed two strong-security e-mail protocols with PFS. Unfortunately, Dent [17] pointed out that the second protocol in Sun et al.'s schemes failed to provide the PFS service as claimed. Subsequently, Phan's cryptanalysis in [18] showed that replay attacks and unknown key-share attacks did take place in both Sun's first and second protocols. Furthermore, Kim et al. [19] proposed a further two robust protocols with PFS, in which the additional short-term key is generated by Diffie-Hellman key exchange. The authors claimed that the exposure of the long-term key would not disclose the secrecy of the previous session keys. Unfortunately, in 2007, Yoon and Yoo [20] pointed out that the second protocol of Kim et al.'s schemes was susceptible to sender impersonation and server impersonation attacks. Recently, Zhang and Hua proposed a new ID-based authenticated e-mail protocol with PFS [21]. Unfortunately, their scheme employed pairing computations in both the sending and receiving phases. As has been demonstrated, it is not a good idea to perform bilinear pairings via mobile device [22]. In 2015, Toorani [23] presented the cryptanalysis of a new, widely used e-mail protocol with PFS proposed by Chen and Wu [24], showing that Chen and Wu's scheme is vulnerable to some password-related attacks, and fails to provide PFS. Furthermore, Kang and Xu [25] mentioned that the protocol of Chen and Wu [24] suffered from several security weaknesses, and proposed an improved e-mail scheme using PFS.

Motivation
According to the abovementioned observations, the design guidelines of a secure e-mail protocol are highlighted below: 1.
Storage-and-forwarding: The practical design of a secure e-mail protocol should take into account its storage-and-forwarding nature.

2.
Confidentiality: The content of e-mail should be transmitted over public networks in the form of ciphertext using a one-time-use key.

3.
Integrity: The integrity of e-mail content is guaranteed by generating the authentication message via a message authentication code (MAC) function [9], or by computing the signature with the sender's private key.

4.
Authentication: The identities of the sender and the recipient should be mutually confirmed in order to remove the threat of false impersonation attacks. Sometimes, the e-mail server should authenticate the sender in such a way that the spam will be deterred effectively, and the recipient must be authenticated prior to receiving the e-mail.

5.
Perfect forward secrecy: It is critical to provide a PFS service to the security-sensitive applications of e-mail.

Contribution
In this paper, the authors propose a secure and practical e-mail protocol with PFS, while taking into account the abovementioned design guidelines. The e-mail server shoulders the responsibilities of both authenticating and helping to negotiate the session key shared between the sender and the recipient.
Compared with the abovementioned protocols, the main advantages of the proposed scheme are highlighted as follows: 1.
The mutual authentication among sender, recipient, and server removes the threats of not only impersonation attacks, but also spam.

2.
The confidentiality and integrity of the content of transmitted e-mail are guaranteed, while providing the service of PFS.

3.
The expense of involving the PKI, like all related schemes, is avoided in order to keep the key management simple. 4.
The proposed protocol not only achieves lower computational costs, but also satisfies more security criteria compared to existing protocols.

5.
The remainder of this paper is organized as follows: Preliminary points are presented in the following section. Thereafter, Section 3 demonstrates the proposed scheme. Security analysis and discussions are presented in Sections 4 and 5. Finally, conclusions are presented in Section 6.

Preliminary
A Schnorr signature scheme [26] is a cryptosystem based on discrete logarithms [27]. In the Schnorr signature scheme, there is a large prime p and a primitive element g shared among a group of users. Each user randomly generates an integer x < p, called their private key, and calculates their related public key y as y ≡ g x mod p . The public key of the user is y and the private key is x. This technique employs a subgroup of order q in Z * p and a hash function h:{0,1} →Z q .
The Schnorr signature scheme is reviewed as follows.
To sign a message M, the signer should do the following: 1.
Compute r ≡ g δ mod p, where δ is a randomly chosen integer and 1 ≤ δ < q.

The Proposed Scheme
The proposed e-mail protocol with PFS is composed of three phases-the registration phase, the sending phase, and the receiving phase-as shown in Figure 2. For simplicity, two communication parties A and B and the trusted e-mail server S participate in the protocol. First, some notations shown in Table 1 are used to make the proposed protocol easier to understand.  Suppose that sender A must be a legal user of the e-mail server. Sending is allowed via the server only after a successful login process. Otherwise, the request will be rejected.

Registration Phase
A user (for instance, B) must register to the e-mail server S in order to become a legal user before obtaining the related e-mail services. Figure 3 shows these processes.  Suppose that sender A must be a legal user of the e-mail server. Sending is allowed via the server only after a successful login process. Otherwise, the request will be rejected.

Registration Phase
A user (for instance, B) must register to the e-mail server S in order to become a legal user before obtaining the related e-mail services. Figure 3 shows these processes.  Step 1) B S : IDB, g User B selects a random number xB to compute g mod and then sends (IDB, B x g ) to S.
Step 2) S B : VB, (eB, sB) Upon receiving the message, S intends to share a secret VB with B by performing the following operations: • Select a random number B, where 1 ≤

≤ . •
Compute the master key VB = h(IDB, B) for authentication of the identity of B later.

•
Generate the Schnorr signature (eB, sB), as follows: Finally, S delivers a smart card with VB, (eB, sB) to B via a secure pathway. In order to check the validation of (eB, sB), user B obtains S's public key PUS to retrieve rB' as: and then verifies the equality h(IDB, rB')=eB. If it holds, B inputs xB into the smartcard. Likewise, user A also possesses a smart card with VA, (eA, sA) and xA in the same way above. Note that S keeps the records (IDB, g ) and (IDA, g ) for B and A, respectively.

Sending Phase
When user A intends to send e-mail M securely to user B, who is assumed to be offline, the detailed description is shown as follows (see also: Figure 4): Step 1) B→ S: ID B , g x B User B selects a random number x B to compute g x B mod p and then sends (ID B , g xB ) to S.
Step 2) S→ B: V B , (e B , s B ) Upon receiving the message, S intends to share a secret V B with B by performing the following operations: Generate the Schnorr signature (e B , s B ), as follows: Finally, S delivers a smart card with V B , (e B , s B ) to B via a secure pathway. In order to check the validation of (e B , s B ), user B obtains S's public key PU S to retrieve r B ' as: and then verifies the equality h(ID B , r B ')=e B . If it holds, B inputs x B into the smartcard. Likewise, user A also possesses a smart card with V A , (e A , s A ) and x A in the same way above. Note that S keeps the records (ID B , g x B ) and (ID A , g x A ) for B and A, respectively.

Sending Phase
When user A intends to send e-mail M securely to user B, who is assumed to be offline, the detailed description is shown as follows (see also: Figure 4): Step 1) A S : IDA, IDB, TSA, (eA, sA), g , ( , , , , g ) User A sends S a request message asking for e-mail service. The smartcard selects a random number yA to compute g mod and ( , , Step 1) A→ S: User A sends S a request message asking for e-mail service. The smartcard selects a random number y A to compute g y A mod p and MAC(V A , When receiving the request sent by A, S first checks the freshness of TS A . If it holds, S authenticates A as follows.
Use the corresponding ID A to compute the master key If it holds, A is authenticated successfully by S.
Step 3) A→ S: in order to confirm the integrity and origin of the received message. If it holds, the smart card confirms two things: The received message is fresh but not replayed because TS A is fresh.

2.
The identity of S is authenticated.
Then, the smart card computes the message encryption key k = (TS A , h(g x B ) y A mod p).

Receiving Phase
Note that we assume that more than one e-mail exists for B in the server. When user B intends to receive the e-mail-say M 1 , M 2 , . . . , M n -from S, B must be authenticated by S, and the corresponding session keys k 1 ,k 2 , . . . ,k n should be constructed first. The detailed description is shown as follows (also see Figure 5).

Receiving Phase
Note that we assume that more than one e-mail exists for B in the server. When user B intends to receive the e-mail-say M1, M2, …, Mn-from S, B must be authenticated by S, and the corresponding session keys k1,k2,…,kn should be constructed first. The detailed description is shown as follows (also see Figure 5). Step 1) B S : IDB, (eB, sB), TRB, g ′ , ( , , , g ′ ) B sends S a request message (IDB, eB, sB, TRB, g ′ , ( , , , g ′ )), where xB' is a nonce and TRB is the current timestamp.  Step 1) B→ S: ID B , (e B , s B ), TR B , g x B , MAC(V A , TR B , ID B , g x B ) B sends S a request message (ID B , e B , s B , TR B , g x B , MAC(V A , TR B , ID B , g x B )), where x B ' is a nonce and TR B is the current timestamp.
Step 2) S→ B: When receiving the request sent by B, S first checks the freshness of TR B . If it holds, S authenticates B as follows: The corresponding ID B is used to compute the master key is verified successfully, S is authenticated by B. Note that B should replace x B with x B ' for the next round.

Security Analysis
The security issues of the proposed protocol encompass four main services: confidentiality, integrity, authentication, and PFS. Confidentiality is the protection of transmitted e-mail from passive attacks, such as eavesdropping. In other words, confidentiality means keeping transmitted e-mail secret from illegal access by any but the authorized recipients. The most commonly used method is to encrypt e-mail using a secret key along with a public encryption algorithm. An integrity service then ensures that the e-mail is received without unauthorized modification. The authentication service is concerned with ensuring that the communication participants are authentic. Confirming the precise origin of the transmitted e-mail allows the recipient to know who sent the message. This confirmation implies that either of the two communication participants and the e-mail server can authenticate one another. PFS provides a high-level security service that is much more important for some security-sensitive applications.
Prior to the demonstration of security, some assumptions of security are made. We highlight the following facts providing proof of security. The discrete logarithm problem (DLP) and the Diffie-Hellman problem (DHP) [28] are two hard problems to solve in polynomial time, and the cryptographic hash function has collision-free and irreversible properties.

Assumption 1 (discrete logarithm assumption).
The discrete logarithm problem (DLP) is defined so as to give a prime p, a generator g of the finite cyclic group Z p * , and an element b ∈ Z * p , finding the integer a, 1 ≤ a ≤ p − 2, such that g a ≡ b mod p. The DLP assumption is that there is no feasible way of solving the DLP for all probabilistic polynomial time algorithms.

Assumption 2 (computational Diffie-Hellman assumption).
The computational Diffie-Hellman (CDH) problem is defined so as to compute g ab given g a and g b , where g is a generator of the finite cyclic group Z * p , and 1 ≤ a, b ≤ Z * p . The CDH assumption is that there is no feasible way of solving the CDH problem for all probabilistic polynomial time algorithms. Assumption 3 (one-way hash assumption). A one-way hash function is defined as a hash function that can take inputs of any size, and the resultant hash value should be fixed-sized. For any message m, it is easy to compute m's hash value h(m). However, it is computationally infeasible to find a message m from its hash value h(m). The assumptions are as follows:

1.
For any message m 1 , it is computationally infeasible to find another message m 2 such that h(m 1 ) = h(m 2 ).

2.
It is computationally infeasible to find a pair of different messages m 1 and m 2 such that h(m 1 ) = h(m 2 ).
It is reasonable to assume that the server is trustworthy for users, because a user only becomes legal after registering with the e-mail server by providing private information.
Proposition 1 (security of the master key). The master key shared between a legal user and the e-mail server is kept secret.

Proof.
Considering the confidentiality of the user's master key, the master key is a hashed value of the user's identity and the random number-i.e., V B = h(ID B , δ B )-selected for user B. In order to deduce the master key, the attacker would have to know δ B in order to compute the master key V B . In order to succeed, the attacker must try to derive δ B from the ordinary Schnorr signature (e B , s B ). Nevertheless, solving the well-known DLP is believed to be infeasible in polynomial time (Assumption 1).

Proposition 2 (confidentiality). The protocol provides confidentiality of the transmitted e-mail by keeping the encryption key secret.
Proof. It is crucial for users to keep the encryption key k = h(TS A , g x B y A ) secret from outsiders in order to ensure the confidentiality of the content of e-mail. The encryption key is a hashed value of the timestamp TS A and g x B y A .
This implies that an attacker must have g x B y A in order to deduce k. From the steps in the e-mail sending phase, an attacker could eavesdrop g x B and g y A in order to compute g x B y A . Nevertheless, solving the well-known CDH problem is believed to be infeasible in polynomial time (Assumption 2). This implies that the confidentiality of e-mail is ensured, and that the session/encryption key is only shared between the sender and the recipient.

Proposition 3 (integrity). The protocol ensures the integrity of the transmitted e-mail.
Proof. In the proposed protocol, the integrity of the transmitted e-mail is guaranteed through the MAC function by either the master key or the session key. The following demonstrates that the attacker cannot modify the transmitted e-mail without knowing either the master key or the session key. Since k i is shared between A and B, the attacker will not know about k i (Proposition 2), and is therefore unable to forge the related MAC value.
These two observations above provide proof of the integrity of e-mail.

Proposition 4 (mutual authentication).
The protocol provides mutual authentication between the sender A, the server S, and the recipient B.
Proof. This proposition is analyzed from three perspectives: authentications among A, B, and S. The server S shoulders the responsibility of assisting A and B in authenticating one another. A (resp. B) is satisfied with both the origin and the integrity of the received messages from Step 2 in the sending phase (resp. Step 2 in the receiving phase) from S. If the verification of the message from S holds, A (resp. B) is convinced that the origin of the received message g x B (resp.g y A ) is B (resp. A), as only A/B knows the secret exponent y A /x B . The common session key can be generated by A/B as k = h TS A , (g x B ) y A /k = h TS A , (g y A ) x B . Because the session key is only known by A and B, nobody can forge a valid MAC k i , TS i , ID i , ID B , [M] k i .
In accordance with the above analyses, mutual authentication between S, A, and B is achieved.

Proposition 5 (perfect forward secrecy).
The proposed e-mail protocol provides the service of PFS.
Proof: Perfect forward secrecy means that when the long-term keys of either side of the sender or the recipient are compromised, the previous short-term common session keys are still kept secret. The common session key shared between sender and recipient is constructed as k = h TS A , (g x B ) y A = h TS A , (g y A ) x B . Assume that the attacker has intercepted and collected all messages transferred in past e-mail sessions; only g y A and g x B were obtained, but neither y A nor x B . If the long-term secret keys V A , V B , and PR S have been compromised, based on the difficulty of solving the DLP and the CDH hard problems, obtaining y A /x B or g y A x B from g y A /g x B to compute k is infeasible. In order to obtain the session key, the attacker must have the knowledge of y A or x B . In addition, the session keys generated to encrypt different e-mails are independent, since y A and x B are randomly chosen by A and B, respectively, in each run; that is, the attacker cannot know previous session keys even if they obtain the session key used in this run.
Proposition 6 (resistance to replay attacks). The protocol ensures the freshness of the transmitted messages by removing the threat of replay attacks.

Proof.
A timestamp is involved in the MAC function in order to guarantee the freshness of the transmitted messages. Each participant can easily measure the time duration of the message traveling. Based on this knowledge, the freshness can be guaranteed by checking whether or not the time difference is acceptable.
In the sending phase, all of the messages in the three steps are protected by involving TS A issued by the sender.
Furthermore, the freshness of all of the messages in the receiving phase is guaranteed by involving TR B issued by the recipient. Table 2 summarizes the analyses of security and the comparison between the related works and the proposed scheme. Compared to the related works, the proposed scheme provides more security functionality, and is more secure against attacks. The proposed Yes Yes Yes Yes Yes *: The e-mail server is not authenticated by the sender; **: the sender might be cheated by attackers owing to lacking mutual authentication; ***: the e-mail server does not verify the identity of the recipient.

Discussion
In spite of demonstrating the security analysis, there are several valuable merits to be discussed, as follows:

Computional Efficiency
Prior to demonstrating the computational efficiency, some observations are highlighted: • The e-mail server performs two linear operations to solve secret random numbers δ A /δ B in order to compute the shared master keys V A =h(ID A , δ A )/V B =h(ID B , δ B ), and four (resp. three) operations for generating hash/MACs in the sending phase (resp. the receiving phase).

•
The senders perform two modular exponential operations for preparing g y A and computing a common session key k = h(TS A , g x B y A ), and five operations for hash/ MACs. Furthermore, one secret-key operation is performed in order to compute [M] k .

•
The recipients perform two modular exponential operations for preparing g x B and computing a common session key k = h(TS A , g y A x B ), and four operations for hash/ MACs. Furthermore, one secret-key operation is performed in order to decrypt [M] k .
As shown in [29], the speed of secret-key operations is about 100-1000 times faster than that of public-key operations, while the speed of hash-based operations is much faster than that of secret-key operations. Thus, public-key operations and modular exponentiation operations are computationally expensive. Table 3 clearly indicates that the computational costs on the sender/recipient side and the e-mail server side are comparatively lighter than those of the related works. In client/server networks, the server can easily be inappropriately designed, and thus become a computational bottleneck involving heavy computational cost. The following characteristics are highlighted below:

1.
Server side: In the proposed protocol, the computational cost on the server side is significantly lighter than that of the related works. Compared to conventional PKI-based systems, in which the server has to handle huge computational overhead for each session, the e-mail server in our scheme merely treats efficient hashing operations in the phases of sending and receiving (see column 5 in Table 3). Although the generation of a Schnorr signature is required on the server during the registration phase, this is an infrequent task, and some supplementary measures-such as precomputation or offline computation-can also be considered in order to improve overall performance. 2.
User side: The total computational cost required from the sender (resp. the recipient) in the proposed scheme is two (resp. two) exponentiation operations. This implies that the computational cost in the proposed scheme is lower than that of the related works. Table 3. Comparison of performance in e-mail sending and receiving phases between the related works and the proposed scheme.

Operation Modular Exponentiation
A/S/B The recipient should send a new g x and the signature of g x to the e-mail server for the next round.

Simple Key Management
Obviously, if the e-mail server maintains a security-sensitive database containing all users' passwords or secret keys, it becomes the target of numerous attacks from networks. In general, schemes based on a secret-key-or password-based cryptosystems likely face this challenge (i.e., the secret key/password management problem) in such a way that it limits the scalability of the system. In the proposed protocol, there is no sensitive information stored centrally in the e-mail server. On the contrary, the master key used to authenticate the senders/recipients is dynamically computed by the e-mail server from the message (e, s), which is a form of Schnorr signature.
Compared with traditional PKI-based key exchange protocols, such as the DH protocol [28], the authenticated key exchange is provided without involving public key authentication based on PKI instead of the trusted third party, i.e., the e-mail server. This system does not demand the establishment of PKI. Hence, the burden of maintaining PKI is avoided. In summary, the key management is simple.

Implementation
Taking e-mail contexts into account, every e-mail generally has two contexts-the SMTP context, and the MIME context [10]-as shown in Figure 6. The former determines the communication pattern-i.e., sender and recipients-and the SMTP-related actionse.g., reply and reply-all. The latter determines the rendering of the e-mail content, including the parsers for HTML, CSS, etc. Herein, the whole MIME is potentially protected, while the whole SMTP is kept public.

Implementation
Taking e-mail contexts into account, every e-mail generally has two contexts-the SMTP context, and the MIME context [10]-as shown in Figure 6. The former determines the communication pattern-i.e., sender and recipients-and the SMTP-related actionse.g., reply and reply-all. The latter determines the rendering of the e-mail content, including the parsers for HTML, CSS, etc. Herein, the whole MIME is potentially protected, while the whole SMTP is kept public.  Figure 6. E-mail context: (a) SMTP context; and (b) MIME context.

Further Disussions
The proposed protocol achieves the following advantages: 1. Mutual authentication: Based on Proposition 4, the mutual authentication between sender, recipient, and server removes the threat of impersonation attacks and spam. This implies that the proposed protocol is an authenticated key exchange scheme. 2. Confidentiality and Integrity: Based on Propositions 2 and 3, the confidentiality and integrity of the content of transmitted e-mail is guaranteed, while providing the service of PFS based on Proposition 5.

Simple Key Management:
Based on the analysis in Section 5.2, the expense of involving PKI, such as S/MIME-based and PGP-based PKI [10], is avoided in order to keep key management simple. 4. Lower computational costs: As shown in Table 3, the proposed protocol achieves lower computational costs, as mentioned above, and meets higher security criteria compared to the existing protocols, as shown in Table 2.

Further Disussions
The proposed protocol achieves the following advantages:

1.
Mutual authentication: Based on Proposition 4, the mutual authentication between sender, recipient, and server removes the threat of impersonation attacks and spam. This implies that the proposed protocol is an authenticated key exchange scheme.

2.
Confidentiality and Integrity: Based on Propositions 2 and 3, the confidentiality and integrity of the content of transmitted e-mail is guaranteed, while providing the service of PFS based on Proposition 5.

3.
Simple Key Management: Based on the analysis in Section 5.2, the expense of involving PKI, such as S/MIME-based and PGP-based PKI [10], is avoided in order to keep key management simple. 4.
Lower computational costs: As shown in Table 3, the proposed protocol achieves lower computational costs, as mentioned above, and meets higher security criteria compared to the existing protocols, as shown in Table 2.
It is worthwhile to note that the proposed e-mail protocol benefits from providing PFS and avoiding expensive PKI maintenance costs compared with traditional e-mail protocols such as S/MIME and PGP.

Limitation
Since e-mail is one of the most popular communication tools, there are a variety of threats in the e-mail scenario, such as phishing attacks, spam mail, denial-of-service (DoS) attacks, and viruses. The proposed scheme, however, does not cover most of these practical concerns as long as the senders have been authenticated. For instance, spammers may obtain authentication following the scheme, and apply some technologies for the avoidance of spam detection systems; hence, spamming can still succeed. Fortunately, research and newer methods in terms of spam prevention are continuously under development, e.g., in [8], a spam-filtering system with an artificial backpropagation neural network (BPNN) is proposed in order to minimize the influence of spam. Moreover, the spread of viruses via the sending of malicious messages or attached files constitutes a similar problem, and the corresponding approach in [30] is proposed in order to optimally control virus propagation on the e-mail network.

Conclusions
While the security of e-mail is receiving considerable attention not only from academia, but also from industry, the proposed protocol guarantees the crucial security criteria. This includes confidentiality, integrity, mutual authentication, and PFS, without the introduction of expensive computational costs. It is worthwhile to note that since PKI is not required, key management thus becomes simple. Therefore, the proposed protocol is more secure and more practical than those currently in use. The major advantages include: (1) computational efficiency; (2) simple key management; and (3) satisfying more security criteria compared to similar existing schemes.