# Secure Video Communication Using Multi-Equation Multi-Key Hybrid Cryptography
## 4 Experimentation  
The proposed cryptography method is implemented using the mobile platform. The encryption and decryption procedures, as well as video streaming, are implemented using an Android-based application. When implementing the RSA and AES algorithms in the Android platform, choosing the appropriate security parameters is crucial. In the context of RSA, a key size of 2048 bits is selected, which is considered to be a robust choice for ensuring the security of the encryption algorithm. Additionally, a secure padding scheme known as Optimal Asymmetric Encryption Padding (OAEP) is employed (we have implemented the method discussed in [27]). This padding scheme enhances the security of RSA by introducing additional randomness and mitigating potential vulnerabilities. When considering the Advanced Encryption Standard (AES), selecting an appropriate key size is crucial based on the desired level of security. In this case, a key size of 128 bits is chosen. Additionally, the AES-GCM mode of operation is selected, which provides both confidentiality and integrity protection. To ensure the effectiveness of AES-GCM, an initialisation vector (IV) is utilised. The IV is generated using the proposed method for generating keys. Firstly, the Android development environment needs to be established in order to proceed with the required tasks. Once the environment is set up, the Android Keystore is utilised for secure key storage. To ensure data security, encryption and decryption functionalities are implemented. The KeyPairGenerator class is employed for RSA operations, while the Cypher class is utilised for AES operations. The sender devices keep the video material and video metadata for streaming. The sender software launches when a receiver asks to stream a video file. The sender, an authorised video distributor, confirms the recipient's identity before sending the video material to them. The receiver data are maintained in the device. During the sign-up procedure, information is gathered about the recipient. The sender's database is retrieved and filled with all data, including the user name, password, public key, and user attributes, like the MAC address. Decryption and video replay are the receiver's primary responsibilities. The proposed module gets encrypted video chunks and decrypts them. The receiver's database is used to acquire the required keys. Therefore, in this technique, no key exchange takes place. The sender's public and recipient's private keys are used in the decoding. The program uses an RSA implementation to get the first video segments. The implemented application then shows the video data on the device's display unit. As a result, there is no need to save the obtained video data. A database must be set up for the applications to keep the video metadata and information about the receiver. On the sending side, the database keeps track of the following: information about the recipient, such as their username, the MAC address of the device, the public key, and other information that is unique to their account. In the same way, the sender's public key and the video session's metadata are saved in the receiver's database. The suggested method uses a collection of equations to generate the dynamic key automatically. The suggested module uses the trap-door mechanism, a well-known feature of the equation-based method. The module considers the receiver's public key in addition to the previously generated key that was discussed in the previous Section 3, as well as a set of user attributes. The sender-side module creates the segments after reading the video file. In this case, the FFMpeg module created the video chunks. The movie has been divided into a unit size. Regardless of the chunk size, which can be any size, the module generates the chunks to the nearest complete frame.