# Utilizing Trusted Lightweight Ciphers To Support Electronic-Commerce Transaction Cryptography
## 5 Security and Performance of Proposed E-Commerce Applications
### Attacks Analysis on Our Protocol
The attacker cannot decrypt the electronic payment details (see Figure 8c) because we rely on a sufficiently long, random 256 bit key to fend off this type of attack. Our protocol does not send secrets over the insecure channel. In addition, when the guesser captures the packet, it cannot parse it to derive the keys \(Pr_{k}\) and \(Pu_{k}\). Therefore, our protocol deservedly resists this attack. * **Credit card fraud** A fraudster tries to access a customer's account and compromises a credit card account in order to obtain secret parameters (such as the credit card number, the card security code, or knowing the expiration of the attack value) for the user/company. An attacker uses document falsification and fraudulent information using credit card fraud attacks. Even if the fraudster receives some credit card details or uses some fake details, he/she does not have secret parameters such as _PW_ and \(Pr_{k}\) without which he/she cannot complete the e-commerce transactions. Thus, our protocol is able to prevent this type of attack. * **Sabotage** A saboteur intends to destroy, subvert or obstruct by penetrating certain websites, stopping the system of a company/institution, stopping the sale/purchase requests or online payment operations, or sending sensitive information from the client or server to another party. Infecting an e-commerce app with a malicious program is an example of online buying and selling environment sabotage. A more extreme instance is causing e-commerce in a nation to go down. To counter this attack, our protocols use \(Pu_{k}\)s that change each time the buyer and seller's devices connect to the e-commerce network. * **Data modification** An attacker attempts to penetrate the exchanged e-commerce information then modifies or deletes the information of the e-commerce requests (purchasing, selling and invoices), and changes some of its contents or prevents access to the information receiver. In order to prevent this attack, we maintain the confidentiality of the information by implementing an encryption algorithm (AES-256). In our protocol, any change in e-commerce requests will be detected by the receiver app because our protocol uses specific forms for e-commerce requests. If the attacker makes a change to the encrypted requests, upon decryption, the change will be exposed and not match the forms used. * **Ransomware** An attacker compromises a website or application by injecting or analyzing to try to obtain secrets such as a credit card number, encryption keys and \(PW\), and they use this information to demand a ransom from the targeted victims. Then, attackers can demand the ransom online payment or even set up a ransom program. If the victim does not pay or execute the ransom, the attacker either destroys the data, publishes the data, or encrypts the data in a way that the victim cannot access. In our protocol, if an attacker can access \(Pr_{k}\), \(Pu_{k}\) and \(Salt_{i}\) (which is impossible) on the current connection, the attacker will not benefit from these parameters because they will not be used on the next connection. That is, the attacker cannot demand ransom for the secret parameters even if he/she receives them. We use a protocol that combines encryption algorithms such as ElGamal-1024 and AES-256, which are difficult to penetrate due to their high security. * **Sniffing** An unauthorized sniffer monitors, intercepts and captures all sensitive request data for the targeted network that passes through the sending and receiving processes of a certain request. The goal of this attack is to expose login credentials and financial information or to hijack a target's device by sending a packet or group of packets to the victim's device to gain access to sensitive information. In our protocol, any packet that does not use legitimate parameters such as \(Pu_{k}\) for the receiver device will be rejected outright. Thus, our protocol does not handle requests that use hijacking packets.