# Utilizing Trusted Lightweight Ciphers To Support Electronic-Commerce Transaction Cryptography
## 4 Proposed Protocol Methodology for E-Commerce
### Encryption Procedure  
To perform the encryption process in our protocol, \(Pr_{k}\), \(Pu_{k}\), \(PW\) and \(R_{i}\) (buying, selling or invoice request) are used. However, before the encryption process can be performed, the keys \(Pr_{k}\) and \(Fk_{i}\) that are hidden on the network devices must be extracted. As described in Algorithm 2, Steps 1 and 2 represent the extractions of \(Pr_{k}\) and \(Fk_{i}\) for use in AES-256 ciphers. Next, our protocol uses a CRT technique with the key \(Pr_{k}\) to obtain a random \(Salt_{i}\) with minimal computational overhead. Then, our protocol uses \(Fk_{i}\) and \(Salt_{i}\) to perform the encryption operations, whereas the encryption operation \(Enc_{R_{i}}\) is executed through the operation \(R_{i}||Salt_{i}\). Our protocol uses the operation \(Pu_{k}\oplus Salt_{i}\) to obtain a hidden ephemeral salt (\(Salt_{e}\)). Finally, the \(Enc_{R_{i}}||Salt_{e}\) cipher is sent to the target device. In the same way, \(Pr_{k}\) and \(Fk_{i}\) are hidden by \(Fk_{e}\) to prevent attackers from hacking the device and from gaining security parameters.  
```
1:Input: \(Pr_{k}\), \(Pu_{k}\) keys with 256 bit, \(PW\) and \(R_{i}\)
2:Output: \(Enc_{R_{i}}\) and \(Salt_{e}\)
3:Extract \(Pr_{k}=PW\oplus Inte\)
4:Extract \(Fk_{i}=Fk_{e}\oplus Inte\oplus PW\)
5:Use CRT to generate \(Salt_{i}\)
6:Use \(Fk_{i}\) 256 bit with AES encryption
7:Encrypt \(Enc_{R_{i}}(R_{i}||Salt_{i})\)
8:Hide \(Salt_{e}=Pu_{k}\oplus Salt_{i}\)
9:Send \(Enc_{R_{i}}||Salt_{e}\)
10:Store \(Fk_{e}=Fk_{i}\oplus Inte\oplus PW\)
11:Store connection order on the sender side
```  
**Algorithm 2** Encryption procedure  
### Encryption Procedure  
The encryption procedure is followed by a process called decryption. After the target device receives the encrypted request, it decrypts it with the public and private keys as well as security parameters such as \(Salt\). For example, sellers need to decrypt buyers' requests to identify the type of request, the quantity ordered, the destination of the request, and the information that represents the invoice payment. In the same way as Algorithm 2, Algorithm 3 extracts the keys \(Pr_{k}\) and \(Fk_{i}\) stored on network devices during steps 1 and 2. Next, the receiver receives requests such as \(R_{i}=Enc_{R_{i}}||Salt_{e}\), then subtracts \(Salt_{e}\) from the encryption request, and then extracts \(Salt_{i}\) from \(Salt_{e}\) to perform the decryption process. Then, our protocol uses \(Fk_{i}\) and \(Salt_{i}\) to perform the decoding of \(R_{i}\) by \(Enc_{R_{i}}||Salt_{i}\). After the receiving device receives the explicit text of the requests, it is stored in the datasets for archiving. In the same manner as Algorithms 2 and 3, it stores keys anonymously.  
Keys Updating Procedure  
For a protocol to be robustly designed for security, it should include a key update procedure (see Algorithm 4). Initially, our protocol applies steps 1 to 6 in Algorithm 1 which performs key generation operations \(Pr_{k}\) and \(Pu_{k}\) and then obtains \(Pr_{k}\) by ElGamal-CRT and \(Fk_{i}\) by mixing \(Sk_{s}\). To hide \(Fk_{e}\), the last salt (\(LSalt_{i}\)) is used within the process \(Fk_{i}\oplus Fk_{o}\oplus LSalt_{i}\). The sender (buyer) sends \(Fk_{e}\) to the receiver (seller). Finally, public and private keys are protected on network devices in the same way as Algorithms 1-3.  
Input: \(P_{n}\), \(G_{n}\) values and \(PW\)  
Output: \(Pr_{k}\) and \(Pu_{k}\) keys with 256 bit length  
```
1:Apply Algorithm 1, steps 1-6
2:Obtain \(Pr_{k}\) and \(Fk_{i}\)
3:Compute \(Fk_{e}=Fk_{i}\oplus Fk_{o}\oplus LSalt_{e}\)
4:Send \(Fk_{e}\) to the receiver
5:Protect \(Pr_{k}\) and \(Fk_{i}\) on device
6:Compute \(Inte=PW\oplus Pr_{k}\)
7:Store \(Fk_{e}=Fk_{i}\oplus Inte\oplus PW\)
```  
**Algorithm 4** Keys updating procedure