# Utilizing Trusted Lightweight Ciphers To Support Electronic-Commerce Transaction Cryptography
## 4 Proposed Protocol Methodology for E-Commerce
### Proposed Protocol Procedures  
In designing the protocol, we rely on the method of encrypting and decrypting request transactions. This is performed using symmetric and asymmetric encryption algorithms. We use the AES algorithm to encrypt the text and request information. We follow the following steps (Figure 9 shows our proposed protocol procedures):  
1. We generate random keys that are the private and public keys by default using an ElGamal asymmetric encryption algorithm. Then, we divide the random key whose size is from 1024 to 256 bit to fit the AES algorithm keys.
2. We use this public key to encrypt the e-commerce requests among \(B\), \(S\) and \(TAS\). Our protocol performs strong encryption using high encryption randomness, which is difficult to crack when sent from \(B\) to \(S\).  
Figure 8: Selling and buying requests and invoice.  
3. The request information will be decrypted using the AES and ElGamal keys. The buyer/seller receives a decrypted text that is difficult to penetrate from an attacker.
4. Public and private keys are updated when required or when the number of key mix-ups has expired.
5. Hiding information and security parameters on network devices, especially keys, is important in cases of hacking of these devices.  
The first procedure in our protocol is the key generation procedure. Algorithm 1 refers to the operations performed for the key generation procedure. Key generation instructions for the ElGamal algorithm are described earlier in Section 3.2. In this section, we will describe directives added to support public and private key security. Initially, the parameters \(P_{n}\) and \(G_{n}\) were used to generate the keys in ElGamal. We use ElGamal to generate \(P_{tk}\) public keys with a size of 1024 bit. In addition, we make use of ElGamal-CRT to generate the private key (\(Pr_{k}\)). To support randomness in public keys, we split the public key (\(Pu_{k}\)) into subkeys (\(Sk_{s}\)). These \(Sk_{s}\) are \(Sk_{1}\), \(Sk_{2}\), \(Sk_{3}\) and \(Sk_{4}\) with a length of 256 bit, which fits the AES algorithm. Our protocol performs the operations \(k_{1}=Sk_{1}\oplus Sk_{2}\) and \(k_{2}=Sk_{3}\oplus Sk_{4}\). Then, our protocol obtains the final key (\(Fk\)) of length 256 bit through \(Fk_{i}=k_{1}\oplus k_{2}\oplus Sk_{i}\) (where \(Sk_{i}\) can be the value of \(Sk_{1}\), \(Sk_{2}\), \(Sk_{3}\) and \(Sk_{4}\)). To protect the keys \(Pr_{k}\) and \(Fk_{i}\) on network devices, they are hidden using the operations result (\(Inte\)) \(=PW\oplus Pr_{k}\) (where \(Inte\) represents the interim value) and final key ephemeral (\(Fk_{e}\)) \(=Fk_{i}\oplus Inte\oplus PW\). At this point, \(Inte\) and \(Fk_{e}\) are safely stored on devices using e-commerce applications. On the next connection, our protocol moves to the fourth step in Algorithm 1 without generating keys. Our protocol relies on scrambling \(Sk_{s}\) to use new public keys; for example, our protocol computes \(k_{1}=Sk_{1}\oplus Sk_{3}\) and \(k_{2}=Sk_{2}\oplus Sk_{4}\) and then performs the same operations in Algorithm 1 until 16 connections are completed. If the network device has made 16 connections in e-commerce applications, then in the next connection, it should start from step 1 in Algorithm 1. Bypassing key generation for 16 connections reduces computational costs, especially in \(TAS\).  
Figure 9: Proposed methodology procedures.  
```
1:Input: \(P_{n}\), \(G_{n}\) values and \(PW\)
2:Output: \(Pr_{k}\) and \(Pu_{k}\) keys with 256 bit length
3:Use ElGamal to generate \(Pu_{k}\) with 1024 bit length
4:Use ElGamal-CRT to generate \(Pr_{k}\)
5:Divide \(Pu_{k}\) to four part with 256 bit length
6:Four subkeys: \(Sk_{1}\), \(Sk_{2}\), \(Sk_{3}\) and \(Sk_{4}\)
7:Apply \(\oplus\) with subkeys
8:Obtain \(Fk_{i}\) with 256 bit length
9:Protect \(Pr_{k}\) and \(Fk_{i}\) on device
10:Compute \(Inte=PW\oplus Pr_{k}\)
11:Store \(Fk_{e}=Fk_{i}\oplus Inte\oplus PW\)
12:Next connection, go to step 4 with changing \(Sk_{s}\) order
13:After 16 connections, go to step 1
```  
**Algorithm 1** Keys generation procedure