MORSA: An Innovative Modified and Optimized RSA Framework Using Parallel Computing Environment

2.1 Drawbacks associated with different types of modified RSA cryptosystems

i. Low Public Key Efficiency [25]: RSA with Chinese Remainder Theorem (CRT), can enhance the effectiveness of decryption with help of the CRT to accelerate the modular exponentiation method. However, these schemes frequently require additional parameters and computations, which increase the size of the public key. This can lead to more storage requirements and increased transmission costs.

ii. Reduced Security Margin [26]: Certain variations to RSA, for instance RSA with small public exponents (e.g., small Fermat primes), aim to increase efficiency by using smaller exponents. Although this can accelerate decryption and encryption, it can also reduce the security margin of the algorithm. Small exponents make the encryption more exposed to attacks such as the Wiener attack, where an attacker can factorise the modulus when the exponent is too small.

iii. Vulnerability Attacks in Side-Channel [27]: Some implementations or modifications of RSA may be susceptible to side-channel attacks. Side-channel attacks exploit information leaked during the cryptographic operation, such as power consumption, timing information, or electromagnetic radiation. If proper countermeasures are not taken, sensitive data may be extracted via side-channel attacks., including the private key.

iv. Increased Key Size and Computation Complexity [28]: Some modifications of RSA aim to enhance security by using larger key sizes or more complex mathematical operations. While this can provide additional security, it also leads to increased computational requirements. Larger key sizes can impact encryption and decryption performance, requiring more computational resources and potentially slowing down the cryptographic operations.

2.2 Current research trends and research question

Kitchenham et al. [29] stated that there are three parts to the question structure: population, interventions, and outcomes. All the under-researched RSA models, or more accurately, algorithms that are improved or altered variants of the real standard RSA algorithm, make up the Population, which is the center of our study. Actions such as changed or enhanced, among others, that demonstrate the kind of therapies with RSA are the interventions in our situation according to training. The ultimate verdict on whether the improved RSA algorithms have shown any notable benefit is found in the outcomes.

RQ1. What the authors goal in improving the RSA model?

RQ2. What are the conventional RSA algorithms many revisions to date?

RQ3. How do suggested RSA schemes address present-day data or network security issues?

RQ4. Which RSA scheme domain has received greater attention?

2.3 Countermeasures and preventative measures

a.    Since key size: Since it has been shown that 512 RSA keys are too short and unsafe for usage, many of the standards that are now in place mandate the use of 1024/2048/4096 bits for RSA keys.

b.    Strong primes: It is suggested that moduli with a bit size of 1024/2048/4096 employ more than three factors [12].

c.    Multi-prime RSA: To speed up the RSA private operation, there are proposals of using more than two primes to generate the modulus.

d.    Public exponent: At the very least, the private exponent need to be 300 bits in length for the usual key that is 1024 bits in length.

In summary, the selection of prime numbers in RSA directly impacts the algorithm and resilience against various attacks. By choosing prime numbers that are large, generated securely, and have suitable properties, RSA implementations can mitigate vulnerabilities and resist attacks more effectively. Additionally, considerations such as efficient modular exponentiation can indirectly impact the effectiveness of side-channel and timing attack mitigations.

The main goal of our work is the proposed MORSA algorithm, an important generation improved process that ensures that the generated keys are fairly large and resistant to modern cryptographic attacks. Additionally, the new generation of key generation technologies reduces the overhead connected to key sizes. This means that resource-limiting devices can use severe encryption. Second, this paper examines the use of optimized algorithms to generate prime numbers to efficiently select a large number of primes. This optimization reduces the performance observed in traditional RSAs due to the high complexity of computing involved in prime number production. Furthermore, the MORSA cryptosystem introduces a dynamic modulus selection approach, where the modulus is varied based on the input data size, thus improving the encryption speed while preserving the same level of security. This feature allows for adaptive encryption suitable for a diverse range of applications with varying data sizes. Next, Analyze and optimize the implementation for efficiency and speed with respected to Standard RSA algorithms, consider parallel processing techniques to enhance performance, especially for large data sets. The workflow diagram of proposed MORSA algorithm is shown in Figure 1.

11.png

Figure 1. Workflow diagram of proposed MORSA algorithm

Here describe how to Implement the large random and optimized prime number generation algorithm during key generation using PSO optimizing technique, dynamic Modulus Selection, MORSA decryption and encryption process using Parallel of computing resources technique. Figure 2 represents four distant features proposed MORSA system.

22.png

Figure 2. Four distant features of proposed MORSA system

4.1 Implement the large random and optimized prime number generation algorithm

4.1.1 Large random prime generation procedure

The goal is to efficiently calculate large random numbers with a specific bit size. The standard method for manually implementing a random prime generator that can generate linear values with satisfactory levels of accuracy is specified as follows:

i. Random number of the desired bit size.

ii. Make sure that the selected numbers cannot be split due to the first 100 prime numbers (these are presented). Based on the acceptable error rate, we use a certain number of iterations by Rabin Miller Primality test [30] to get the number that is probably prime.

iii. Implement the optimized prime number generation algorithm to efficiently select large prime numbers required during key generation using PSO optimising technique.

iv. Ensure that the prime number generation process is robust and capable of generating sufficiently large prime numbers for proposed method.

4.1.2 Optimization of Large prime number generation algorithm

Prime number generation is traditionally a discrete problem because prime numbers are inherently discrete values—whole numbers that are greater than 1 and divisible only by 1 and themselves. However, in the context of optimization algorithms, it can be treated as a continuous optimization problem if consider it within an optimization framework. This involves adapting continuous optimization techniques to search for prime numbers, despite their discrete nature.

Applying PSO to prime number generation is an unconventional use of the algorithm, but it can be explored as a new way to search for prime numbers in a defined range or optimize some prime-related function. Let’s break down how prime number generation can be viewed as a continuous optimization problem and what adaptations would be required.

1. Understanding the Discreteness of Primes

Prime numbers are discrete because they belong to the set of integers {2,3,5,7, 11…}. So, traditionally, finding prime numbers involves checking numbers in this discrete set (integers). This is what makes prime number generation a discrete problem. PSO are often used for continuous optimization tasks where variables can take any value from a range (usually real numbers). Despite this, these algorithms can sometimes be adapted to work with discrete values by introducing methods like rounding, discretization, or relaxation.

2. Continuous Optimization for Discrete Problems

• Represent potential solutions (candidate numbers) as continuous variables.
• Adapt the algorithm to either discretize the continuous solutions or directly check for the primality of the solutions at each iteration.

3. Step-by-Step Adaptation for Continuous Optimization for Prime Number Generation

1. Discrete PSO Variant: Use a variant of PSO designed for discrete spaces, where particles represent integers rather than real-valued vectors.
2.  Fitness Function (Primality Test): The fitness function evaluates whether the number represented by a particle is prime. If the number is prime, the fitness is high; if not, the fitness is low.

def is_prime no.(n):

  if n <= 1:

    return False

  for i in range (2,int (n * 0.5) + 1):

    if n % i = 0:

      return False

  return True

3. Fitness with Probabilistic Primality: For large numbers, you might use a probabilistic primality test (e.g., Miller-Rabin) and use the confidence as fitness:

def fitness(x):

  # Return a probability estimate (pseudo-code)

  return miller_rabin_confidence(x)

• Calculation Swarm Size (Number of Particles) for prime number search: If they consider Small Primes (i.e., <10,000) that means 20 particles so Number of Iterations will be 30. Similarly, Medium Primes (~10⁶): 30-40 particles, 50-70 iterations and Large Primes (≥10¹⁰): 40-60 particles, 70-100+ iterations.

With help of above condition, we get the percentage of success rate shown in Figure 3.

Velocity and Position Update: In PSO, the particles move toward better solutions. However, after updating the particle's position (which may be continuous), you will need to round or map the particle's position to a valid integer (the next candidate number) to ensure it is still a valid candidate for primality testing.

4. Discretization: Once the particle moves in the continuous space, it would be rounded or converted to an integer. The PSO algorithm itself will explore continuous space, but the solution will always be tested as a discrete integer.
5. Optimization Process: PSO will continue searching for prime numbers by moving particles through the continuous space and checking if their corresponding values are prime numbers. Particles with prime numbers will have better fitness values and be attracted toward areas with more prime numbers.

33.png

Figure 3. Estimated prime search success rate with respect to swam size

4.2 Dynamic modulus selection

Understanding Modulus Size in MORSA: The modulus size (n) in MORSA is typically 1024, 2048, 3072, or 4096 bits. The maximum size of the data that can be encrypted directly is limited to (modulus size in bytes - padding overhead). Table 2 indicates the general guideline for modulus selection. Figure 3 shows the estimated prime search success rate with respect to swam size.

Table 2. General guideline for modulus size selection

Note: Exact input size depends on the padding scheme used (e.g., OAEP).

b. Adaptive Modulus Sizing Logic (Pseudocode)

def select_modulus_size(input_data_bytes):

  # Estimate required size with padding

  overhead = 42 # for OAEP padding (approx.)

  total_bytes = len(input_data_bytes) + overhead

  if total_bytes <= 117:

    return 1024 # bytes ~117

  elif total_bytes <= 245:

    return 2048 # bytes ~245

  elif total_bytes <= 373:

    return 3072

  elif total_bytes <= 501:

    return 4096

  else:

    raise ValueError ("Input data too large use parallel processing for direct MORSA encryption.")

d. The relation between MORSA key size (modulus size in bits) and the maximum plaintext size you can encrypt using OAEP padding is based on the following formula:

Max plaintext size (in bytes) = (modulus_size_in_bytes) - 2 * hash_len - 2

Where:

• modulus_size_in_bytes = key_size_in_bits / 8
• hash_len = length of the hash output used in OAEP (e.g., SHA-256 = 32 bytes, SHA-1 = 20 bytes)

Table 3. MORSA key size vs max OAEP plaintext size

First, determine the size of the input data. This can be measured in terms of the number of bits, bytes, or other relevant units. Next, establish criteria or rules for selecting the modulus size based on the input data size. This can be done using predefined thresholds or a mathematical formula. Then, based on the input size and the defined criteria, select an appropriate modulus size. Finally, use the selected modulus size in your cryptographic or mathematical operations. Table 3 represents relation between the MORSA key size vs. max OAEP plaintext size.

4.3 MORSA decryption and encryption process using parallel computing resources technique

It is already introduced speeding up modular exponentiation using optimized technique and dynamic modulus system to increase efficiency of MORSA cryptosystem. But still now MORSA cryptosystem faces some challenges when dealing with large input data, including Performance Issues with Large Data with Slow Encryption and Decryption: and High Computational Cost, Padding Overhead, Memory Constraints, Modulus Size Constraints, Scalability. Parallelization for MORSA Operations is the one impotent solution. Encrypting/decrypting multiple blocks of data in parallel.

4.3.1 Parallelization for MORSA cryptosystem operations

Parallelization can help improve the performance of the MORSA Cryptosystem, especially when working with large datasets. Because MORSA's core is based on RSA (and includes modular equation), parallelization in various regions can be used to reduce time complexity and optimize systems for large-scale operations.

1. Important areas of parallelization: Encryption and decryption of several sections: When processing large files or messages, the data must be split into smaller sections corresponding to module N. These sections can be encrypted or decrypted in parallel because each section operates independently. Here, the data is split into small sections, each section is encrypted in parallel using a thread pool. These sections can be encrypted or decrypted in parallel because each section operates independently. Here, the data is split into small sections, each section being encrypted in parallel using a thread pool.
2. Using Python's concurrent.futures library, we can parallelize the encryption of each section:

import concurrent.futures

def encrypt_section(section, public_key):

  “Encrypt a single section."

  return encrypt(section, public_key)

def parallel_encrypt(data, public_key, section_size, num_workers=6):

  "Encrypt data in parallel by splitting it into section."

  # Split data into sections

  Section = [data[i:i+section_size] for i in range (0, len(data), section _size)]

# Use Thread Pool Executor to parallelize the encryption of section

  with concurrent. futures. Thread Pool xecutor(max_workers=num_workers) as executor:

    encrypted_sections = list (executor.map(lambda section: encrypt_section(section, public_key), sections))

    return encrypted sections

2. Similarly, for decryption, sections of encrypted data can be processed independently:

def decrypt_section (section, private_key):

  "Decrypt a single section."

  return decrypt(section, private_key)

def parallel_decrypt(encrypted_data, private_key, section _size, num_workers=6):

  "Decrypt encrypted data in parallel by splitting it into sections."

  # Split encrypted data into sections

  sections = [encrypted_data[i:i+chunk_size] for i in range(0, len(encrypted_data), section_size)]

    # Use ThreadPoolExecutor to parallelize the decryption of sections

  with concurrent.futures. Thread Pool Executor(max_workers=num_workers) as executor:

    decrypted_sections = list(executor.map(lambda section: decrypt_section(section, private_key), sections))

    return decrypted_sections

2. Modular Exponentiation (MORSA Operations): The modular exponentiation operation M^f mod  n (for encryption) and C^d mod  n (for decryption) is computationally expensive. Although MORSA is inherently sequential for a single message, it can be parallelized when dealing with multiple messages or blocks. This is especially useful when processing multiple chunks of encrypted data in parallel. In the example above, modular exponentiation for each chunk is parallelized using a thread pool, which speeds up the overall process.

def modular_exponentiation(modulus, base, exponent,):

"Modular exponentiation."

Returnpow(modulus,base,exponent,)

def parallel_modular_exponentiation(sections, exponent, modulus, num_workers=6):

"Perform modular exponentiation on each section in parallel." with concurrent futures.

Thread Pool Executor(max_workers=num_workers) as executor:

results = list(executor.map(lambda section : modular_exponentiation (section, exponent, modulus), sections))

return results

3. Key Generation: Generating large prime numbers for the keys and the modulus n can be parallelized. While probabilistic primality tests (like the Miller-Rabin test) can be expensive, they can be run on different cores for each candidate prime. Additionally, the process of finding multiple primes (e.g., p,q,r,s) for a multi-prime system like MORSA can be parallelized.

import concurrent.futures

from sympy import is prime

def generate_prime_candidate(bits=1024):

  "Generate a random candidate for prime number."

  return random.getrandbits(bits)

def check_and_generate_prime(bits=1024):

  "Generate a prime number."

  candidate = generate_prime_candidate(bits)

  while not isprime(candidate):

    candidate = generate_prime_candidate(bits)

  return candidate

def parallel_generate_primes(num_primes=4, bits=1024, num_workers=6):

  "Generate multiple primes in parallel."

  with concurrent.futures.ThreadPoolExecutor(max_workers=num_workers) as executor:

    primes = list(executor.map(lambda_:section _and_generate_prime(bits), range(num_primes)))

  return primes

4. Key Splitting and Combining: When using multiple primes (as in the MORSA system), operations like splitting the private key into smaller parts (modular inverses for each prime) and combining results can benefit from parallelism. In this case, modular inverses for each prime can be computed in parallel, reducing the time spent on this operation.

def mod_inverse_parallel(a, moduli, num_workers=6):

  "Compute modular inverse in parallel for each prime factor."

  def mod_inv_for_prime(p):

    return mod_inverse(a, p)

  with concurrent. futures. Thread Pool Executor(max_workers=num_workers) as executor:

    inverses = list(executor.map(mod_inv_for_prime, moduli))

    return inverses

5. Parallelizing Padding and Unpadding: Padding and unpadding of the message to ensure it fits into the modulus size can be done in parallel for multiple chunks. This is particularly useful when dealing with larger files or messages.

def parallel_pkcs1_pad(sections, n_size, num_workers=6):

  "Apply PKCS#1 padding in parallel to each chunk."

  with concurrent. futures. Thread Pool Executor(max_workers=num_workers) as executor:

    padded_sections = list(executor.map(lambda section: pkcs1_pad(section,n_size),sections))

  return padded_sections

def parallel_pkcs1_unpad(sections, n_size, num_workers=6):

  "Unpad PKCS#1 padding in parallel."

  with concurrent. futures. Thread Pool Executor(max_workers=num_workers) as executor:

    unpadded_sections = list(executor.map(lambda section: pkcs1_unpad(secton, n_size), sections))

  return unpadded_sections

In our proposed model, multiple threads are parallelly executed equ-length sections. By parallelizing key parts of the MORSA cryptosystem, including the encryption/decryption of sections, modular exponentiation, key generation, and padding, we can improve the system's efficiency and scalability, especially when working with large data sets.

MORSA uses four big primes instead of two, making the modulus n = p * q * r * s difficult to calculate.

Below explains how and why does this withstand to security claims likes brute-force attacks.

1. Large key space makes brute force impractical: MORSA is the product of 4 big primes (512-1024 bits each). If each prime is 512 bits, n is 2048 bits and if each prime is 1024 bits, n is 4096 bits. Brute-force factorization is exponentially more costly than with 2 primes due to the exponential number of prime combinations. With modulus size, brute force factoring time complexity becomes super-polynomials. Combinations grow exponentially with additional primes.
2. Increased Primes in Factorization: Although additional primes may make factorization simpler, this is not true. Classical algorithms, such as trial division and Pollard's rho, remain unsuccessful. Increasing the number of bits in n slows even the quickest factoring process, number field sieve (NFS). MORSA's n = p * q * r * s is much greater, therefore NFS chokes.
3. Factoring Hardness Security: RSA can be broken by factoring n = p * q in traditional RSA but MORSA factor n = p * q * r * s. This demands more resources and time to break multiple factors. Here key length (bits) is more important than prime number in repelling brute force. The use of numerous big primes provides increased security.
4. No Use for Brute Force Key Guessing: Some call brute force "guessing the private key d": d is usually hundreds of digits long and independent calculated. Factoring n is necessary to calculate φ(n) and confirm assumed d. Unknown totient makes estimating d impossible.
5. Padded Randomized Encryption: With OAEP or another padding method in MORSA is given the same plaintext with distinct ciphertexts each time, preventing dictionary and chosen-plaintext attacks, which are brute-force tactics.

The answer of the proposed research questions, which are introduced at Section 2 are addressed. In RQ 1: MORSA aims to improve RSA’s key generation via PSO, dynamic modulus, parallel computation via Tables 3, 4 and 8; RQ 2: Table 1 represents different modification of conventional RSA cryptosystem; RQ 3: Section 6 shows how the present-day data or network security issues can be minimized with proposed MORSA. RQ 4: RSA’s key generation via PSO, dynamic modulus is giving the attention. This was attended in our proposed model.