Improved End-to-End Data Security Approach for Cloud Computing

Abstract

Cloud computing is one of the major cutting-edge technologies that is growing at a gigantic rate to redefine computation through service-oriented computing. It has addressed the issue of owning and managing computational infrastructure by providing service through a pay-and-use model. However, a major possible hindrance is security breaches, especially when the sender uploads or the receiver downloads the data from a remotely accessed server. It is a very generic approach to ensuring data security through different encryption techniques, but it might not be able to maintain the security standard. This paper proposes an end-to-end data security approach from the sender side to the receiver side by adding extra padding sequences, as well as randomized salting, followed by hashing and an encryption technique. The effectiveness of the proposed method was established using both a simulated system and mathematical formulations with different performance metrics. Furthermore, its performance was compared with those of contemporary algorithms, showing that the proposed algorithm creates a larger ciphertext that is almost impossible to crack due to randomization modules. However, it has significantly longer encryption and decryption times, although our primary concern is ensuring security, not reducing time.

1. Introduction

Recent technical advancements make it possible to think of computing power as a utility service that can be executed by switching it on and off. This allows users to pay for whatever amount of computational power they have used, and the services are only available whenever they are required, owing to the nature of cloud computing technology [1,2,3]. End users can access computational processing power, memory, storage, etc., from a cloud service provider through the Internet based on the pay-and-use model, avoiding the extra headache of buying, managing, and maintaining IT infrastructure [4,5]. Moreover, it is possible to scale up and down the entire IT infrastructure instantly as per the requirements of the client work development cycle, whereas, in the traditional scenario, it is essential to acquire all resources before the development phase starts [6,7]. In a nutshell, the cloud can be considered a service-oriented computing paradigm that delivers computing services on demand through the Internet.

The entire spectrum of services provided by cloud computing is roughly divided into three dimensions: infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS) [8,9]. Hence, the subscriber can obtain any kind of service, ranging from hardware and platforms to software. The entire service can be run on the Internet from any remote location in the world. Sometimes, confidential personal data need to be transferred through the public Internet, which is an insecure medium. There may be a high chance of compromised data security, as any illegitimate user can access the data illegally. Moreover, secure information is stored on the server of a third-party cloud service provider, which may raise a point of concern about breaches of trust. However, in the cloud model, clients need to rely on the service provider to keep the data secure.

As the power of cloud computing is utilized to a great extent, the amount of data stored on the cloud is increasing exponentially, opening up room for work on data security. A slight compromise in the security aspect may cause illegitimate access to highly confidential data, which may cause huge losses for the client organization. Although cloud service providers ensure that the data stored in the cloud are safe, the security measures are not as reliable as they claim. Several incidents directly point to questions about such claims. For example, in 2009, Amazon’s cloud storage service was interrupted twice [10], stopping the operation of some storage systems that were fully dependent on the service.

In the same year, a compromise of security vulnerabilities occurred in Google Docs. As a consequence, confidential user information was exposed. Similar security vulnerabilities were also reported for VMware [10,11]. The above-mentioned scenarios create a strong foundation for us to work on data security in the cloud environment. In this work, we propose an approach to ensuring end-to-end cloud data security by combining data encryption and hashing. It should be mentioned that encryption is a method by which data are converted or encrypted into an unreadable form, which can later be decrypted when needed using a password key. However, an individual generic encryption algorithm does not need to be so strong that it can eliminate the chance of a security violation [12,13]. To address this issue, we applied the hash function to a selected portion of encrypted data. To strengthen encryption, we added random salt and extra padding. A more-detailed description of the proposed methodology is provided in Section 3. Several performance metrics, namely ciphertext size, encryption and decryption time, and encryption and decryption throughput, were used to establish the efficiency of the proposed approach. The performance of our proposed algorithm was compared with that of other standard algorithms, with the results reflecting the fact that the proposed algorithm converted plain text to a larger ciphertext by adding extra randomization, making it nearly invulnerable to compromise by an attacker. However, both the encryption and decryption throughput values were low with the proposed approach. As a result, it took longer to encrypt and decrypt messages. As time was not our prime concern, we did not address this issue in the present work, although it should be addressed in the future.

The contributions of this paper are as follows:

• We propose an end-to-end data security approach from the sender side to the receiver side.
• On the sender side, data security is provided by the proposed algorithm, which combines random salting and hashing with data encryption.
• On the receiver side, the encrypted message is decrypted and eventually accepted or rejected after verification.
• Despite its lower throughput, the algorithm produces a larger random ciphertext that is almost impossible to decipher.

The rest of this paper is organized as follows. Section 2 of this paper discusses some prominent related works in this field, along with their limitations. The details of the proposed methodology are explained and an in-depth block diagram is presented in Section 3. Section 4 includes an analysis of the results based on the considered performance metrics, as well as a comparison with previous works. Finally, the paper is concluded in Section 5, along with suggestions for directions for further work.

2. Related Works

Several studies have been conducted on data security and privacy issues in cloud computing, particularly in the last decade. In this section, we take a look at a few pioneering works that have received extensive attention from researchers in this field.

The authors of [14] prepared a survey on aspects of cloud computing security, but focused the discussion only on possible security threats, without exploring any possible remedies. Modi et al. analyzed the different factors impacting security-related issues in cloud computing along with possible solutions to those findings [15]. However, they lacked the future directions of the work. Abbas et al. reviewed an extensive and comprehensive study of privacy issues in cloud computing [16]. However, this work focused on the privacy challenges of a particular type of cloud, which was deployed for e-health only and not for any other general purpose. In [17], Xiao et al. analyzed the probable security and privacy threats and proposed some possible solutions to the existing vulnerabilities. However, the work put most of the attention on defining the security parameters and was confined to a brief discussion on the solutions for the vulnerabilities. A storage security protocol, namely SecCloud [18], was proposed by Wei et al. It provided security for data storage and performed computation auditing. However, the effectiveness of this protocol is limited due to a scalability issue. A prominent user authentication protocol for mobile cloud computing [19] was proposed by Roy et al. In this proposal, a lightweight security mechanism through a cryptographic hash function, bitwise XOR, and fuzzy extractor functions was proposed. However, they mainly focused on high-end security with minimal communication and computation costs, which is much more suitable for the mobile cloud computing domain. Another notable work by Hamid et al. dealt with bilinear pairing cryptography to provide security for storing and accessing healthcare-related data in cloud and fog computing environments [20]. Here, security is ensured by generating a session key, which is shared among the participants, which may cause some extra overhead. Some of the approaches are much more concentrated on reducing the extra overhead of cryptography-based security techniques. In [21], the authors, Xu et al. followed the same principle to propose a less computationally expensive public key encryption technique for cloud-based WSNs. However, this work may be compromised by security standards. Sharma et al. developed a signature-generating technique [22] to authenticate sender and receiver transactions securely in IoT communication models. Here, the signature was generated through a well-known hashing algorithm, namely SHA-3 [23]. However, their work was confined to authentication only without considering other security parameters, which may compromise the data security. In [24], Farwan et al. used the salted hash algorithm to provide multi-level security privileges for an e-payment system. However, the work was very application-specific, with a limited set of results discussed. Ghosh et al. proposed a software-defined network based on the information-centric cloud environment [25] to ensure the security standard as per the service level agreement between the client and service provider. The work was not only restricted to security issues, but also ensured offering other network resources to the user. There have been several works already performed on security and privacy protection for the cloud, edge, and fog computing environments accessing big data. Makkar et al. proposed a security-preserving federated learning algorithm for the edge–cloud environment [26]. In [27], Gupta et al. proposed a homomorphic-encryption-based method for an energy-efficient cloud environment. Sun et al. surveyed secure cloud computing techniques along with the future directions for the research in [28]. Another good study on big data and the cloud is available in the literature [29]. Batra et al. proposed the hybrid logical security framework (HLSF), which ensured data privacy in the green IoT environment [30]. The main objective of their work was to provide security while maintaining minimal energy usage. For that purpose, the proposed framework was capable of providing a lightweight security solution with a minimum key size. A hybrid scheme combining data encryption, access control, and intrusion detection was proposed by Razaque et al. for big data security in the cloud environment [31]. However, due to its hybrid nature, the procedure may be computationally expensive. Moreover, it can be implemented with other sets of algorithms. Almiani et al. developed an intelligent network intrusion-detection model [32] using the backpropagation neural network for DDoS attacks on a cloud computing platform. To detect malicious DDoS activity, the method sifts through the traffic flows through the containerized microservices architecture. However, the work focused on a particular type of attack in the native cloud system. All the listed literature surveys convinced us that the works were concentrated mostly on giving more security assurance through cryptographic key generation. But still, there are some gaps in providing end-to-end data security, which is almost impossible to crack. Here, we addressed the security issues by using data encryption combined with hashing and random salt to keep the sender’s data safe until they reach the receiver’s side.

3. The Proposed Methodology

In this section, the proposed approach for providing an end-to-end data security mechanism for the cloud computing paradigm is discussed. Here, random salt and padding are added to the sender’s data to make it difficult to identify the actual data portion of the entire message. Then, the whole message is encrypted, and a part of the message should go through the hashing function. After that, the encrypted message along with the hashed portion should be uploaded to the cloud server from the sender’s side. Although the cloud service provider signed a service level agreement to ensure the privacy of the data in the public cloud, they can be compromised, as data encryption or password hashing techniques do not truly ensure it. As an example, today’s encrypted text can be easily broken using different approaches, like brute-force attacks, dictionary attacks, lookup tables, reverse lookup tables, or rainbow tables [33]. However, our approach is difficult to crack, as the sender’s data are jumbled with different techniques like random salting, padding, encryption, and hashing, which are almost impossible to revert. It should be mentioned that, here, we used asymmetric encryption, where the encryption key is public, so it can be made available to many people working in the same organization, who can encrypt the data before uploading them to the cloud. The decryption key in the asymmetric encryption method is kept private, so it is made available only to the selected user with whom the organization wants to share the data. So, it also enhances the data security standard as it is only shared with selected users. Further, a detailed description of the proposed approach is given in the next section.

3.1. System Architecture

Here, the sender’s data are stored and transmitted using the cloud server, where the data are converted by an encryption technique, which is combined with a hash function. The elliptic curve cryptography (ECC) and simple hashing algorithm (SHA-3) [23] are used for encryption and hashing, respectively. Furthermore, the security of the user data is made stronger by adding some random amounts of salt and padding bits to the original data before performing the encryption.

On the receiver side, while trying to decrypt the downloaded message from the cloud server, the secret key of the receiver is used to obtain two different parts, namely the decrypted message and hashed-valued text. Then, the first part is once again hashed with the same algorithm and compared with the second hashed-valued text. The message is accepted if both parts are equal; otherwise, it will be rejected. The details of the different modules used on both the sender and receiver sides are illustrated through the system architecture, as shown in Figure 1.

3.2. Sender Side Module

This section explains each module applied to the user data from the sender side, and the ultimate converted version will be uploaded to the cloud server. As depicted in Figure 1, the sender data (D[$D_{len}$]) have a length of $D_{len}$ and are appended with a predefined-sized $P_{len}$ text padding (P[$D_{len}$]), which is used to identify the end of the data portion. The combination of sender data followed by text padding is considered the message (M[ ]), which is mathematically depicted in Equation (1). As the length of P[$D_{len}$] is greater than zero, the length of M must be larger than the length of D[$D_{len}$].

$$M\left[\right]\leftarrow D\left[D_{len}\right]+P\left[P_{len}\right]$$

(1)

Then, the random salt generator module produces a bit sequence of random length ($R_{len}$), which is referred to as salt ($S\left[R_{len}\right]$), at any time instance ($T_i$). The salt generated at any time instance ($T_i$) is independent of the salt created at any other time instance ($T_j$). Hence, the salt generated in any time instance is different from another salt that is produced in any other time instance. It should be mentioned that the length of the salt is generally quite short in comparison with the length of the data ($D_{len}$$>>$$R_{len}$). Salt is also appended to the message after the padding sequence. Hence, the whole message $(M[])$ constitutes three portions, namely data, padding, and salt, as shown in Equation (2). It should be mentioned that, due to the randomness of the salt portion, different messages can be generated even from the same data and padding portion.

$$\begin{array}{c}M\left[\right]\leftarrow D\left[D_{len}\right]+P\left[P_{len}\right]+S\left[R_{len}\right]\hfill \\ whereM\left[\right]\ne N\left[\right]eveniff,\\ M\left[\right]\leftarrow D\left[D_{len}\right]+P\left[P_{len}\right]+S_M\left[R_{len}\right]\wedge M\left[\right]\leftarrow D\left[D_{len}\right]\\ \hfill +P\left[P_{len}\right]+S_N\left[R_{len}\right]\end{array}$$

(2)

Then, $M\left[\right]$ is duplicated into two different message instances, namely $M_{i_1}\left[\right]$ and $M_{i_2}$[]. Here, both $M_{i_1}$[ ] and $M_{i_2}$[ ] are equal with their parental message $M\left[\right]$, as illustrated in Equation (3).

$$\begin{array}{c}M\left[\right]\to (M_{i_1}\left[\right]\wedge M_{i_2}\left[\right])\hfill \\ \hfill Where,M\left[\right]=M_{i_1}\left[\right]=M_{i_2}\left[\right]\end{array}$$

(3)

$M_{i_1}\left[\right]$ is passed through the SHA-3 hash function. It is also required to mention that, here, we used the 512 bit SHA-3 algorithm, which will convert $M_{i_1}$ into an almost unique 512 bit hash value sequence ($H_{M_{i_1}}$), as shown in Equation (4).

$$\begin{array}{c}{M}_{i_1}\to SHA3(M_{i_1})\to H_{M_{i_1}}\hfill \\ where|H_{M_{i_1}}| = |H_{M_{i_2}}|\dots |H_{M_{i_n}}| = |H_{M_n}| = 512\\ \hfill if\exists H_{M_{i_x}}=H_{M_{j_y}}\iff M_{i_x}=M_{j_y}\end{array}$$

(4)

However, the hashing technique may be compromised by the attacker due to a brute-force attack, rainbow table attack, etc., [33]. So, further giving the uttermost security, we encrypted the hash value using elliptic curve cryptography (ECC) [34]. Here, $H_{M_{i_1}}$ is encoded in a point, namely $(P_{H_{M_{i_1}}})$ in the elliptic curve, and this point will be further encrypted ($(E(H_{M_{i_1}}))$), as shown in Equation (5), where $G_{H_{M_{i_1}}}$ is the base point, k is a random positive integer, and $Pu{b}_{rec}$ is the public key of the receiver.

$$E(H_{M_{i_1}})=k{G}_{H_{M_{i_1}}},P_{H_{M_{i_1}}}+kPu{b}_{rec}$$

(5)

Then, the encrypted hash code $E(H_{M_{i_1}})$ will be append to the second part of the message ($M_{i_2}$), and we encrypt the resultant sequence once again by following the mentioned procedure in Equation (5). So, $M_{i_2}$ will become E($M_{i_2}$), and $E(H_{M_{i_1}})$ will be $E(E(H_{M_{i_1}}))$ as shown in Equation (6). The combined message is uploaded to the cloud server via the public Internet, which should be accessible from the receiver end. Here, the message $M_{i_2}$ and $E(H_{M_{i_1}})$ are encoded into the points in the elliptic curve denoted as $P_{M_{i_2}}$ and $P_{E(H_{M_{i_1}})}$, respectively, and those points are encrypted. Moreover, $G_{M_{i_2}}$ and $G_{E(H_{M_{i_1}})}$ are the base points of the elliptic curve.

$$\begin{array}{c}E(M_{i_2}+E(H_{M_{i_1}}))\to E(M_{i_2})+E(E(H_{M_{i_1}}))\hfill \\ Where,E(M_{i_2})=k{G}_{M_{i_2}},P_{M_{i_2}}+kPu{b}_{rec};\\ E(E(H_{M_{i_1}}))=k{G}_{E(H_{M_{i_1}})},P_{E(H_{M_{i_1}})}+kPu{b}_{rec}\end{array}$$

(6)

The above-discussed procedure, which needs to be executed by the sender before uploading to the cloud, is also illustrated in Figure 1.

3.3. Receiver Side Module

Once the message is uploaded to the cloud from the sender’s side, the receiver will be able to access it with the proper authentication key. More specifically, it will be decrypted by employing the receiver’s secret key. The first part of $E(M_{i_2})$ is multiplied with the private key by the receiver, as depicted in the first line of Equation (7). Then, the resultant of the multiplication is subtracted from the second part of $E(M_{i_2})$, as illustrated in Equation (7). Here, we substitute $(G_{M_{i_2}}\times Pr{i}_{rec})$ as the public key of the receiver $(Pu{b}_{rec})$ and, finally, return back the encoded point $(P_{M_{i_2}})$, which will be decoded into the original message $M_{i_2}$.

$$\begin{array}{c}k{G}_{M_{i_2}}\times Pr{i}_{rec}\\ P_{M_{i_2}}+kPu{b}_{rec}-(k{G}_{M_{i_2}}\times Pr{i}_{rec})=P_{M_{i_2}}\\ + kPu{b}_{rec}-kPu{b}_{rec}=P_{M_{i_2}}\\ \hfill Decoded(P_{M_{i_2}})\to M_{i_2}\end{array}$$

(7)

The last portion of the received message $E(E(H_{M_{i_1}}))$ is also decrypted at the receiver’s side by following the procedure described in the last paragraph. The approach will, finally, return the encrypted hashed message, as illustrated in Equation (8).

$$\begin{array}{c}k{G}_{E(H_{M_{i_1}})}\times Pr{i}_{rec}\\ P_{E(H_{M_{i_1}})}+kPu{b}_{rec}-(k{G}_{E(H_{M_{i_1}})}\times Pr{i}_{rec})=P_{E(H_{M_{i_1}})}\\ + kPu{b}_{rec}-kPu{b}_{rec}=P_{E(H_{M_{i_1}})}\\ \hfill Decoded(P_{E(H_{M_{i_1}})})\to E(H_{M_{i_1}})\end{array}$$

(8)

In the next step, $M_{i_2}$ is passed through the SHA-3 hash function by following the same procedure and parameters as discussed in Equation (4). So, here, we considered that $M_{i_2}$ should be converted to $H_{M_{i_2}}$, as shown in Equation (9).

$$M_{i_2}\Rightarrow SHA3(M_{i_2})\to H_{M_{i_2}}$$

(9)

The other resultant component of the receiving message, $E(H_{M_{i_1}})$, is further decrypted by following the previously discussed decryption procedure in Equation (7). Consequently, $E(H_{M_{i_1}})$ is decrypted to the hashed value $H_{M_{i_1}}$ by applying the private key of the receiver, as illustrated in Equation (10).

$$\begin{array}{c}kG(H_{M_{i_1}}) \times Pr{i}_{rec}\\ P(H_{M_{i_1}}) + kPu{b}_{rec}-(kG(H_{M_{i_1}})\times Pr{i}_{rec}) = P(H_{M_{i_1}})\\ + kPu{b}_{rec}-kPu{b}_{rec}= P(H_{M_{i_1}})\\ \hfill Decoded(P(H_{M_{i_1}}))\to H_{M_{i_1}}\end{array}$$

(10)

The receiver only accepts the message if the hashed value $H_{M_{i_1}}$ of Equation (10) is the same as the value obtained by applying the hashing technique to $M_{i_2}$. So, the receiver accepts the message while $H_{M_{i_1}}$ is equal to $H_{M_{i_2}}$. As in the sender end, both $M_{i_1}$ and $M_{i_2}$ are equal. Otherwise, if both of them are unequal, then it is conclusive that the message must have been compromised or altered between sending and receiving. Hence, the proposed approach ensures both the authenticity and confidentiality aspects by employing hashing and message encryption along with adding random salt and padding bits. Further, the efficiency of the proposed approach was critically evaluated based on several performance metrics, as discussed in the following Section 4.

4. Results and Comparison

To implement the proposed method, we simulated the environment using the following hardware setup with the C programming language with the GMPLibrary (GMP-5.1.1) [35], Miracl Library [36], and PBC Library (pbc-0.5.13) [37]. The simulation environment was as follows:

• The server ran on a PowerEdge R420 PC Server, whose settings are listed below: CPU: Intel^®, Xeon^®, Processor E5-2400 and E5-2400 v2 product families with a physical memory: 8GB DDR3 1600MH, which uses Ubuntu 13.04 Linux 3.8.0-19-generic SMP i686.
• The client systems were PC laptops with the settings of CPU I PDC E6700 with a 3.2 GHz DDR3 2 G 1600 MHz RAM, which runs Windows 7.

In order to establish the efficiency of the proposed approach, it was analyzed through both system-simulated performance and the mathematical formulation of the considered performance metrics, namely ciphertext size, encryption time, decryption time, encryption throughput, and decryption throughput. It should be mentioned that larger-sized ciphertext should be more secure against any brute-force attack [38]. The time taken for encryption and decryption can be reflected in the system overhead of the proposed approach. Further, if a high amount of time is required for encryption and decryption, then the throughput is also reduced, as both are inversely related.

4.1. Cipher Text Size

In this section, we calculated the ciphertext size before uploading the message to the cloud. Let us consider the sender’s data sequence $(D\left[D_{len}\right])$ having length $D_{len}$ as the considered plain text (PT). So, the length of the message $M\left[M_{len}\right]$ after adding padding of length $|P_{len}|$ and random salt having length $|R_{len}|$ is calculated as shown in Equation (11).

$$\begin{array}{c}P{T}_{len}=\left|D_{len}\right|\\ M\left[M_{len}\right]= |D_{len}| + |P_{len}| + |R_{len}|\hfill \end{array}$$

(11)

Then, the original message $M\left[\right]$ is duplicated into two different message instances, namely $M_{i1}\left[\right]$ and $M_{i2}\left[\right]$, both of which have the same length ($M\left[M_{len}\right]$). So, the ultimate length of the message $M\left[\right]$ is calculated in Equation (12).

$$M\left[M_{len}\right]= |M_{i1}\left[M_{len}\right]| + |M_{i1}\left[M_{len}\right]| =2 \times |\left[M_{len}\right]|$$

(12)

Then, $M_{i1}\left[\right]$ is passed through the 512 bit $SHA-3$ hash function, which makes it a 512 bit-long sequence, namely $H_{M_{i_1}}$. After that, $H_{M_{i_1}}$ is encrypted by the ECC algorithm. So, the generated ciphertext $E(H_{M_{i_1}})$ length is approximated by Equation (13).

$$|E(H_{M_{i_1}})| = |H_{M_{i_1}}| + 3\times |Pu{b}_{rec}| + 1$$

(13)

Then, the encrypted hash code $|E(H_{M_{i_1}})|$ will be appended with the second part of the message ($M_{i_2}$) and, finally, once again encrypted by following the same procedure. So, the total length of the encrypted message will be as calculated in Equation (14).

$$\begin{array}{c}|E(|M_{i_2}| + |E(H_{M_{i_1}})|)|= |H_{M_{i_1}}| + 3\times |Pu{b}_{rec}| + 1 + \\ |H_{M_{i_2}}| + 3\times |Pu{b}_{rec}| + 1\\ \approx |H_{M_{i_1}}| + |H_{M_{i_2}}| + 6\times |Pu{b}_{rec}|\\ \hfill \approx 2\times M\left[\right]+6\times |Pu{b}_{rec}|\end{array}$$

(14)

Here, we implemented the proposed encryption technique on three different data lengths along with a predefined fixed-size padding and a random-sized salt bit sequence, as listed in

Table 1. Data length comparison in different intermediate steps in the proposed algorithms ${}^{*}$.

Data Length	Padding Size	Salt Size	Hashed Message Size	Encrypted Message Size
20	10	6	512	2055
50	10	11	512	2059
570	10	22	512	2062

${}^{*}$ All the measurements are in bits.

. It should be mentioned that all the encrypted messages generated by our proposed approach were almost equal in length. So, the length of the message is independent of the data length. The reason behind this is that all the sender’s data are converted to a fixed-length hashed message to which the encryption algorithm is applied.

The encrypted message size also compares with the message generated by using other contemporary algorithms, namely the Advanced Encryption Standard (AES) and the Data Encryption Standard (DES), by keeping all other settings unchanged. The corresponding results are shown in

Table 2. Comparison of plain text and encrypted message length for different algorithms ${}^{*}$.

Data Length	Encrypted Message Size
	Proposed Algorithm	AES Algorithm	DES Algorithm
20	2055	48	48
50	2059	92	190
570	2062	840	1068

${}^{*}$ All the measurements are in bytes.

. Moreover, the listed results in Table 2 are represented visually through Figure 2 for better understanding by the readers.

It was concluded from the results presented in Table 2 and Figure 2 that the encrypted text size of our proposed algorithm was significantly larger than both those of the AES and DES algorithms. As a consequence, it must be capable of converting any plain text to encrypted text, which is stronger against any brute-force attack as compared to the ciphertext generated by the considered AES and DES algorithms. Moreover, it generated almost the same length of ciphertext irrespective of the original message size, which provides the same level of security for all message sizes. However, if the data size is remarkably larger than 512 bits, then the proposed algorithm’s performance should be degraded, as it is confined by the length of the hashing operation. However, it is quite impractical for the data size to be higher than that, as password texts, which are required, for most security, are generally short in length.

4.2. Encryption Time

The encryption time ($E_{Time}$) of an algorithm refers to the amount of time required for converting the plain text to ciphertext. $E_{Time}$ is directly proportional to the size of the plain text. More specifically, larger plain text takes more time to produce the ciphertext by any algorithm as compared to smaller plain text. However, the proposed algorithm has a non-significant variation of $E_{Time}$ for different sizes of the plain text that is ultimately hashed into the same size text. So, any plain text internally is converted to a 512 bit-long hashed text and then goes through the encryption process.

On the sender side, the total time required for the entire encryption process ($T{E}_{Time}$) can be calculated by summing up the total time required for the pre-encryption $Pr{e}_{E_{T}ime}$ module’s execution time, encryption time $E_{Time}$, and overhead time $O_{Time}$, which is mostly system and integration overhead. The calculation of $T{E}_{Time}$ is formally expressed in Equation (15). It should be mentioned that $Pr{e}_{E_{Time}}$ is a combination of several sub-modules, like padding time $P_{Time}$, salting time $S_{Time}$, message-duplicating time $M_{D_{Time}}$, and hashing time $H_{Time}$, as shown in Equation (16).

$$T{E}_{Time}=Pr{e}_{E_{Time}}+E_{Time}+O_{Time}$$

(15)

$$Pr{e}_{E_{Time}}=P_{Time}+S_{Time}+M_{D_{Time}}+H_{Time}$$

(16)

We compared the encryption time for the proposed algorithm with the AES and DES algorithms, which are shown in

Table 3. Comparison of the total time required for the encryption process on different algorithms.

Data Length	Total Encryption Time ${}^{\mathbf{*}}$
	Proposed Algorithm	AES Algorithm	DES Algorithm
20	196	116	84
50	202	129	102
570	209	176	123

${}^{*}$ All the measurements are in milliseconds.

. Moreover, the same comparison is visually depicted in Figure 3 for a clearer understanding for the reader. It was reflected from those data that the proposed algorithm took more time to encrypt the considered message than both the AES and DES algorithms, as the extra time was required for bit salting, padding, and other pre-processing operations. The proposed algorithms also took almost the same amount of time to encrypt different sizes of text as it went for the same-sized hashed data to be encrypted in the internal phase.

4.3. Encryption Throughput

The encryption throughput $T{H}_E$ is referred to as how much data are encrypted in a unit of time. So, it can be calculated by dividing the size of the encrypted data by the total amount of time required, as shown in Equation (17).

$$T{H}_E=D_{Size}/T{E}_{Time}$$

(17)

The average encryption throughput $T{H}_{E_{Avg}}$ can be calculated by taking the average of several throughputs that are obtained from different encryption text size considerations, as shown in Equation (18).

$$T{H}_{E_{Avg}}=\frac{{\sum }_{i=1}^{n}T{H}_{E_1}+T{H}_{E_2}+\dots +T{H}_{E_n}}{n}$$

(18)

The calculated $T{H}_E$ and $T{H}_{E_{Avg}}$ for the proposed algorithm and other considered algorithms are included in

Table 4. Comparison of encryption throughput for different algorithms.

Data Length in Bites	Encryption Throughput ${}^{\mathbf{*}}$
	Proposed Algorithm	AES Algorithm	DES Algorithm
20	0.1020	0.1724	0.2380
50	0.2475	0.3875	0.4901
570	2.7272	3.2386	4.6341
$T{H}_{E_{Avg}}$	1.0255	1.6394	2.2728

${}^{*}$ All the measurements are in Kb/s.

.

It was concluded from Table 4 that $T{H}_E$ significantly varied with the length of the data used for encryption, irrespective of the algorithm used. It is also noted that $T{H}_E$ increased while larger data were provided for encryption, as shown in Figure 4. Moreover, $T{H}_E$ was lower for the proposed algorithm as it passed through the salting, padding, and hashing modules, which added up to extra overhead in the encryption process and, as an ultimate consequence, reduced the throughput.

4.4. Decryption Time

The decryption time ($D_{T}ime$) of an algorithm refers to the amount of time required to revert the ciphertext to plain text. It is directly proportional to the size of the ciphertext. The total time required for the total decryption process ($T{D}_{Time}$) on the receiver side can be calculated by summing the total time required for the decryption time ($D_{T}ime$), post-decryption module ($Pos{t}_{D_{Time}}$), and system integration overhead time ($O_{Time}$), as illustrated in Equation (19). Further, $Pos{t}_{D_{Time}}$ is calculated by adding the decryption for the $E(H_{M_{i1}})$ portion of the receiving message, the hashing time ($H_{Time}$) for the $M_{i2}$ part of the receiving message, and the comparison time ($C_{Time}$) between $H_{M_{i1}}$ and $H_{M_{i2}}$. The detailed calculation is shown in Equation (20).

$$T{D}_{Time}=D_{Time}+Pos{t}_{D_{Time}}+O_{Time}$$

(19)

$$Pos{t}_{D_{Time}}=D_{Time}+H_{Time}+C_{Time}$$

(20)

We compared $T{D}_{Time}$ for the proposed algorithm with the other contemporary approaches, namely the AES and DES algorithms. The evaluation result is listed in

Table 5. Comparison of total decryption time for different algorithms.

Total Decryption Time *
Text Size ${}^{\mathbf{*}\mathbf{*}}$	Proposed	Text Size	AES	Text Size	DES
	Algo		Algo		Algo
2055	379	48	32	48	23
2059	382	92	45	190	42
2062	386	840	119	1068	96

* All the measurements are in milliseconds. ** All the measurements are in bytes.

. It was inferred from the results that the proposed algorithm took more time in the decryption process than the AES and DES algorithms, as an extra hashing operation was performed on the $M_{i2}$ portion of the receiving message and one extra decryption operation needed to be performed on the $E(H_{M_{i1}})$ part of the receiving message. Moreover, for the proposed algorithm, the decryption message length was significantly higher than the other algorithms in all the considered cases, as the sender side message that was received was already larger for the proposed approach. It should be mentioned that, for the almost equal length of the messages, the decryption time was almost the same for the proposed algorithm, as visualized in Figure 5.

4.5. Decryption Throughput

The decryption throughput ($T{H}_D$) refers to how much of the encrypted text can be reverted to normal plain text within a unit of time. It can be calculated by dividing the size of the encrypted text ($E_{Size}$) that is decrypted within the total amount of time ($T{D}_{Time}$), as shown in Equation (21).

$$T{H}_D=E_{Size}/T{D}_{Time}$$

(21)

The average decryption throughput $T{H}_{D_{Avg}}$ is calculated by taking an average of several throughputs that are obtained from different encrypted texts that are given for decryption, as shown in Equation (22).

$$T{H}_{D_{Avg}}=\frac{{\sum }_{i=1}^{n}T{H}_{D_1}+T{H}_{D_2}+\dots +T{H}_{D_n}}{n}$$

(22)

The measured values of $T{H}_D$ and $T{H}_{D_{Avg}}$ for the proposed and other considered algorithms are shown in

Table 6. Comparison of total decryption throughput for different algorithms.

Decryption Throughput
Text	Proposed *	Text	AES	Text	DES
Size **	Algo	Size	Algo	Size	Algo
2055	5.4221	48	1.5	48	2.0869
2059	5.390	92	2.04	190	4.5238
2062	5.3419	840	7.0588	1068	11.0833
$T{H}_{D_{Avg}}$	5.384	3.5329			5.898

* All the measurements are in milliseconds. ** All the measurements are in Kb/s.

.

It was concluded from Table 6 that $T{H}_D$ significantly varied with the length of the data used in both the AES and DES algorithms. The change in $T{H}_D$ was directly proportional to the size of the data. However, the changes were almost invariant for the proposed algorithm as the data size was the same in all the scenarios, as depicted in Figure 6. Moreover, while the larger-sized data were taken into consideration, the value of $T{H}_D$ was lower for the proposed algorithm in comparison with the other algorithms, as an extra overhead in the decryption process.

5. Conclusions

Providing end-to-end data security from the sender side to the receiver side in the context of cloud computing is a very crucial concern. In this paper, we addressed the security issue by proposing an algorithm that combines different techniques, namely salting, padding, asymmetric data encryption, and hashing. Here, randomization was added by using the salting and padding techniques, followed by the hashing and encryption techniques. It produced the final encrypted data, which were almost impossible to crack. Further, it created a larger ciphertext compared to the AES and DES algorithms, which were also difficult to crack, particularly by brute-force attack. However, the encryption and decryption times for the proposed algorithm were significantly longer than the AES and DES algorithms due to the extra processing time required for salting padding and other pre- and post-processing steps. As a result, it reduced the throughput for both the encryption and decryption phases. Moreover, it should be mentioned that the encryption and decryption times of the proposed algorithm were the least sensitive to text size compared to the other algorithms considered. This work can be extended by considering other parametric settings. Moreover, it can be further enhanced towards the reduction of the encryption and decryption times, which was not considered the primary scope in the current context.