Hybrid Encryption Model for Secure Token Distribution Scheme

1  Introduction

Tokens are a type of digital asset that utilizes encryption techniques to secure transactions and verify the authenticity of the data. Cryptographic tokens are used to demonstrate ownership of digital assets on blockchains, authenticate users into systems, or provide access to services [1]. The security and efficiency of token encryption systems have become key considerations as the reliance on digital technology and the increase in proliferation of distributed systems. Tokens can serve various purposes, including as a means of exchange, a representation of ownership or voting rights, or as a form of digital identity. Tokens are instrumental in ensuring the integrity and confidentiality of sensitive data, especially in scenarios where access control is paramount. The main objective of a cyber defense system is that data should be confidential, available, and without loss of its integrity [2].

Digital signatures, hash functions, message authentication codes, and encryption are four key cryptographic techniques used to achieve these goals. In cryptography, a ciphertext is the content of encrypted message that is in an unreadable format to outsiders, where the technical process of transforming the ciphertext into a readable format is called decryption [3].

1.1 Research Methodology

The methodology of this study involved four main stages: first, a literature review and threat analysis were conducted to identify vulnerabilities in token transmission and justify the choice of SHA-2, ChaCha20, and RSA; second, a hybrid cryptographic protocol was designed by integrating SHA-2 for token integrity, ChaCha20 for fast symmetric encryption, and RSA for secure key exchange; third, the protocol was implemented in a controlled Monte carlo simulation environment using Python cryptographic libraries, where tokens were transmitted over an insecure channel to assess security. The cryptographic libraries provide the secure primitives used to build a functional prototype of the hybrid model. The Monte Carlo simulation introduces random variables and iterative processes, randomized attack scenarios and inputs, which are fed into the cryptographic model to test its resilience and explore the system’s weaknesses. Finally, the system was evaluated using both security metrics (resistance to brute force, replay, MITM, and token modification attacks) and efficiency metrics (encryption speed, key generation, and computational overhead), with validation through penetration testing to confirm robustness against adversarial models.

1.2 Related Work

There are different types of cryptographic algorithms used in the encryption of tokens, mainly: symmetric key cryptography, which uses the same key for encrypting and decrypting data, and Asymmetric key cryptography, which consists of two keys: the public key for encrypting data and the private key for decrypting data. One of the fundamental aspects of cryptography is key distribution, which ensures that encrypted data can be securely shared between communicating entities. In classical cryptography, safe key distribution is crucial for maintaining the confidentiality and integrity of transmitted information [4].

Hybrid cryptographic algorithms have gained prominence in various domains due to their ability to enhance security and operational speed. Ref. [4] discussed the enhanced security provided by hybrid encryption techniques in communication and financial transactions, utilizing both symmetric and asymmetric encryption methods. These various combinations have been used to provide security on tokens. Examples, Advanced Encryption Standard (AES), Elliptical Curve Cryptography (ECC), and Rivest, Shamir, and Adleman (RSA) algorithms, are used to provide hybrid encryption. Secure Hash Algorithm (SHA-256) is also used to provide authentication and integrity [5]. These models aim to overcome the limitations of individual encryption methods by utilizing a combination of algorithms to enhance security and efficiency in various applications.

1.3 Preliminaries

This section provides the formal preliminaries for the proposed hybrid encryption model by introducing the system model, security goals, adversary and computational assumptions, the signcryption framework employed, and the mathematical hardness assumptions that underpin the security analysis.

Mathematical Hardness Assumptions

The security of the proposed hybrid encryption model is grounded in well-established computational hardness assumptions from modern cryptography. First, the confidentiality of the symmetric key exchange relies on the assumed intractability of the RSA problem. Given an RSA modulus N = p · q, where p and q are large prime numbers, and a public exponent e, it is computationally infeasible for a polynomial-time adversary to recover the private exponent d from the public key pair (e, N). This assumption is equivalent to the hardness of the integer factorization problem. The security of the ChaCha20 encryption component relies on the pseudorandomness of its keystream generator. ChaCha20 is assumed to be a secure stream cipher, meaning that for any efficient adversary, the keystream produced by ChaCha20(K_enc, N) is computationally indistinguishable from a truly random bit sequence, where K_enc denotes the symmetric encryption key and N denotes a cryptographic nonce. The integrity of transmitted tokens is ensured by the cryptographic properties of the SHA-2 hash function. In particular, SHA-2 is assumed to satisfy:

(i) pre-image resistance—given a hash value h, it is computationally infeasible to find any input m such that SHA2(m) = h;

(ii) second pre-image resistance—given an input m, it is infeasible to find m′ ≠ m such that SHA2(m′) = SHA2(m); and

(iii) collision resistance—it is infeasible to find any pair (m, m′) with m ≠ m′ such that SHA2(m) = SHA2(m′).

Together, these hardness assumptions provide the formal cryptographic foundation for the confidentiality, integrity, and authenticity guarantees claimed by the proposed hybrid encryption scheme.

1.4 Motivation

The rapid adoption of digital platforms and online services has led to an increased reliance on secure authentication mechanisms, with tokens playing a central role in verifying users and securing communication. As systems grow more interconnected, the need to protect tokens during their transmission becomes even more critical. Tokens, which often contain sensitive information such as user credentials, access rights, or authentication data, are particularly vulnerable during transmission. If compromised, they can lead to severe security breaches, including unauthorized access, identity theft, and data manipulation.

Studies indicate that when applied to secure token distribution, hybrid encryption models can fortify protection against various attacks, including interception and unauthorized access. For instance, Nabil and Herráiz highlight a hybrid model that combines cryptography with steganography, adding complexity to defensive strategies, thereby enhancing overall security [6]. This study is motivated by the growing necessity for secure token distribution and the vulnerabilities associated with current encryption techniques. The challenge lies not only in encrypting the token data but also in ensuring its integrity, confidentiality, and authenticity while being transmitted across potentially insecure networks by developing a cryptographic protocol that not only secures token transmission but also provides a practical, adaptable solution to meet the growing security challenges of an increasingly digital world.

Research Gap

Although numerous studies have explored hybrid cryptographic schemes for secure communication, most existing models focus primarily on general data protection or secure messaging, with limited attention to the specific challenges of secure token transmission in distributed authentication systems. Current approaches often emphasize either performance efficiency or cryptographic strength, but rarely provide a systematic integration of confidentiality, integrity, authentication, and replay resistance within a unified token-centric framework.

Furthermore, many hybrid encryption models assume idealized network conditions and overlook practical adversarial scenarios such as token modification, replay attacks, and man-in-the-middle interference in real-world distributed environments. Existing studies also tend to evaluate security properties theoretically, with limited empirical validation through adversarial simulation and performance benchmarking.

Consequently, there remains a clear gap in the literature for a practically validated hybrid encryption framework that is explicitly designed for secure token distribution, balances security and computational efficiency, and demonstrates resilience under realistic attack models. This study addresses this gap by proposing and evaluating a hybrid cryptographic protocol tailored specifically to secure token transmission in distributed systems.

1.5 Contribution

This paper makes the following key contributions to the field of secure token-based communication systems:

1. A token-centric hybrid encryption framework:

We propose a novel hybrid cryptographic model specifically designed for secure token distribution, integrating RSA for secure key exchange, ChaCha20 for high-performance symmetric encryption, and SHA-2 for integrity verification. Unlike prior hybrid schemes that focus on generic data protection, our framework is tailored to the security requirements of authentication tokens in distributed environments.

2. Formal security objectives aligned with real-world threats:

The proposed scheme systematically addresses critical attack vectors in token transmission, including man-in-the-middle attacks, replay attacks, brute-force attempts, and token modification, thereby extending beyond traditional confidentiality-only models to provide end-to-end token security.

3. Adversarially validated design:

We introduce a Monte Carlo–based adversarial simulation framework to empirically evaluate the robustness of the proposed protocol under randomized attack scenarios. This bridges the gap between purely theoretical security claims and practical system resilience.

4. Performance-security trade-off analysis:

Through comparative evaluation with widely used hybrid schemes (RSA + AES + SHA-256, ECDH + AES + SHA-256, and DH + AES + SHA-512), we demonstrate that the proposed RSA + ChaCha20 + SHA-2 model achieves a superior balance between cryptographic strength and computational efficiency, particularly for resource-constrained environments.

5. Applicability to real-world distributed systems:

The study presents concrete application scenarios in domains such as online banking, healthcare systems, and API authentication, illustrating how the proposed model can be directly deployed to enhance the security of token-based access control mechanisms.

1.6 Organization

The paper is structured as follows: Section 2 reviews security goals, while Section 3 outlines the system model, presents the proposed hybrid encryption protocol, assumptions, and related schemes. Section 4 presents security analysis. Section 5, performance evaluation and results. Section 6, discusses application scenarios and concludes with future research directions.

2  Security Goals

In this section, we present the security goals provided by the Hybrid Encryption Model for the Secure Token Distribution Scheme. While safeguarding the communication against various adversarial threats, the scheme addresses the following security objectives:

2.1 Message Confidentiality

The use of ChaCha20 symmetric encryption, in combination with RSA for secure key exchange, guarantees that unauthorized entities cannot decrypt the tokens and gain access to the sensitive data being transmitted. Recent studies have shown that ChaCha20 performs well in terms of throughput and security, making it a reliable choice for ensuring message secrecy [7]. This ensures that no adversary can view or manipulate the token without having access to the decryption keys.

2.2 Message Authentication

The model ensures that the recipient of a message can verify that it was generated by a legitimate sender (i.e., a valid server or client). RSA key pairs are used for authenticating the identity of the sender during the key exchange process, assuring that the communication is coming from an authorized entity.

2.3 Message Integrity

In situations where cryptographic collisions occur, an attacker could potentially forge signatures or manipulate token validity. Although SHA-2 is widely regarded as secure, there are emerging attacks targeting hash collisions that could undermine its integrity guarantees [8]. SHA-2 hashing generates a cryptographic hash of the token, which is then encrypted using ChaCha20. When the recipient decrypts the token, they can verify that the hash matches the token’s expected hash, confirming that the message has not been modified. If the integrity check fails, the token is discarded, preventing any fraudulent or tampered messages from being processed.

2.4 Non-Repudiation

The sender of a message cannot deny their involvement in the communication. By using RSA public-key encryption for secure key exchange and ChaCha20 for encrypting the token, the sender’s involvement is cryptographically verified [9]. Additionally, the use of digital signatures and hashes in the encryption process ensures that the source of the message can be traced.

2.5 Unlinkability

To prevent an adversary from linking multiple messages or identifying that they were generated by the same sender, the proposed hybrid encryption model ensures Unlinkability. The use of session-specific symmetric keys for encryption (via ChaCha20) ensures that tokens from the same sender are encrypted differently each time, making it impossible for attackers to correlate multiple messages to a single source. This provides enhanced privacy and prevents tracking of communication patterns.

2.6 Resistance against Attacks

The use of RSA ensures that only authorized parties can communicate by preventing unauthorized entities from masquerading as legitimate participants. Only those in possession of the private RSA key can decrypt messages encrypted with the corresponding public key, thwarting impersonation attempts. The integrity of the transmitted data is protected by SHA-2 hashing, ensuring that any modification of the message during transmission will result in a mismatch of the hash, causing the message to be discarded. This makes it nearly impossible for attackers to modify messages without detection. To prevent replay attacks, the hybrid scheme includes timestamping and session-specific encryption keys. If an attacker tries to retransmit a previously captured token, it will fail validation due to the unique key used for each session and the token’s expiration timestamp. The integration of hashes and symmetric encryption like ChaCha20 reinforces the confidentiality and integrity of messages, supporting secure communications in sensitive environments [10]. This guarantees that tokens cannot be reused maliciously. RSA key exchange ensures that any public keys exchanged between the server and client are authentic, preventing MITM attackers from intercepting and altering messages during key exchange. Hybrid models that combine key features of both algorithms facilitate a more robust security framework capable of addressing current and future threats [11,12]. Additionally, the encrypted token transmission using ChaCha20 ensures that the content of the messages remains confidential and unaltered even if the attacker attempts to intercept them.

3  System Model

In this section, we describe the system model for secure token transmission, which forms the foundation of the proposed hybrid encryption protocol. The model includes the network setup and cryptographic assumptions under which the system operates.

3.1 Network Setup

The system consists of multiple parties involved in token generation, transmission, and reception. These parties include the sender, receiver, and a trusted authority (TA) responsible for generating and distributing keys. The sender and receiver may belong to different networks or domains, but both rely on a hybrid encryption protocol to ensure the confidentiality, integrity, and authenticity of tokens during transmission.

     i.  Sender: The sender is responsible for generating tokens and encrypting them before transmission. The sender uses a symmetric encryption algorithm (ChaCha20) to encrypt the token and a public-key encryption system (RSA) to securely exchange keys with the receiver.

    ii.  Receiver: The receiver is responsible for receiving encrypted tokens, performing the decryption process using the corresponding private key, and verifying the integrity of the token. The receiver uses the same hybrid encryption model for decryption as the sender used for encryption.

   iii. Trusted Authority (TA): The TA facilitates the secure distribution of keys for the hybrid encryption system. The TA issues public and private key pairs for RSA encryption and provides the cryptographic primitives necessary to perform the operations securely. It ensures that only authorized parties can access the encryption keys.

3.2 Hybrid Encryption Scheme—RSA, Chacha20, Sha2

The scheme ensures reasonable security despite limited computational resources, without significantly impacting system performance. The encryption process uses RSA for secure key exchange, ChaCha20 for token encryption, and SHA2 for data integrity verification. Data was generated using random token algorithms, encrypted, and analyzed. Tests were conducted to evaluate the impact of an adversary attempting to decrypt with incorrect keys. The Table 1 below summarizes the meaning to the acronyms used in the flowchart and data flow of the model in the in Fig. 1.

Figure 1: The flow chart of the proposed model.

The Proposed Model:

Model Explanation

The secure token distribution model begins with the server and client each generating their own RSA key pairs (private and public keys) independently. These public keys are then uploaded to a trusted cloud storage, allowing both parties to retrieve them. The server proceeds to generate a random symmetric key for ChaCha20 encryption and encrypts this symmetric key using the client’s public RSA key, which was obtained from the cloud. The encrypted ChaCha20 key is sent to the client, who then decrypts it using their private RSA key, thereby obtaining the shared ChaCha20 symmetric key. At this point, both the server and the client possess the same ChaCha20 symmetric key. The server then generates a random token (T) and applies the SHA2 hashing algorithm to the token, producing a hash (H). The server encrypts the hash (H) using the shared ChaCha20 key, generating an encrypted token ciphertext. This encrypted ciphertext is transmitted to the client over a secure channel. The client decrypts the ciphertext with the shared ChaCha20 key to recover the hash (H). The client then compares the received hash (H) with a newly computed hash of the token (T) or, alternatively, verifies it through a secure request to the server. If the hashes match, the integrity of the token is validated; otherwise, the token is discarded as compromised.

3.3 Computation Assumptions

We begin with the cryptographic assumptions that support the security of our system. The first assumption is based on the RSA encryption system, which is considered secure due to the computational difficulty of factoring large integers. RSA is well-established for its security properties, which rely on the computational difficulty of factoring large numbers [13]. The RSA algorithm, first introduced by Rivest, Shamir, and Adleman in 1978, utilizes this mathematical principle effectively, making it a cornerstone of modern cryptography [14]. This makes it suitable for transmitting encryption keys securely. The hybrid model infrastructure is designed to retain the security benefits of RSA and the efficiency of ChaCha20, which is known for its performance advantages, particularly in environments constrained by processing power, such as mobile and IoT devices [15]. Given a modulus N = p · q, where p and q are large prime numbers, it is computationally infeasible to recover the private key d from the public key (e, N). The RSA encryption operation is mathematically represented as:

C=MemodN

here M is the plaintext, e is the public exponent, and N is the modulus. The decryption operation is given by:

M=CdmodN

where d is the private exponent.

The ChaCha20 stream cipher is assumed to be secure; its key stream is difficult to predict or reverse. It offers high performance in both hardware and software implementations due to its optimizations for modern processors. In scenarios requiring rapid encryption and decryption, this characteristic is particularly advantageous by leveraging ChaCha20 for substantive data encryption; the systems can achieve a balance between adequate security levels and operational efficiency [15]. The use of ChaCha20 helps mitigate the performance penalty that comes with RSA, allowing for efficient data encryption once the keys have been securely exchanged. This ensures the confidentiality of encrypted tokens. The encryption of a message M with a symmetric key Kenc is represented as:

C=M⊕ChaCha20(Kenc,Nnonce)

where ⊕ denotes the XOR operation and Nnonce is a nonce. Additionally, we assume SHA-2 is collision-resistant, meaning it is computationally infeasible to find two distinct inputs that hash to the same value, thus ensuring the integrity of the token. Integrating SHA-2 within the hybrid model provides an additional layer of security, ensuring data integrity and authenticity. SHA-2, specifically designed for resistance against vulnerabilities that plagued its predecessor SHA-1, employs more complex algorithms that provide improved collision resistance [16]. By generating digital signatures using SHA-2, the system can protect against unauthorized access and ensure that any modifications to the data are detectable. Various studies on cryptography indicate that integrating digital signatures with secure hashing techniques creates a reliable method for traceability and accountability in transactions [17].

The Sender generates a random symmetric key Kenc of 256 bits for ChaCha20 encryption, which will be used to encrypt the token data. This symmetric key is then encrypted using the Receiver’s public RSA key eR, producing the ciphertext:

CRSA=keRencmod N

This ciphertext is securely transmitted to the Receiver. Upon receiving the ciphertext, the Receiver decrypts it using their private RSA key dR:

CdrRSAKenc= mod N

which recovers the symmetric key Kenc.

The Sender generates a random token T, which represents sensitive information (e.g., an authentication token or session ID). The Sender then computes the hash of the token using SHA-2:

H=SHA−2(T)

This hash H will serve as the integrity check for the token. The Sender then encrypts the hash H using the shared symmetric key Kenc with ChaCha20, producing the ciphertext Ctoken:

Ctoken=ChaCha20(H,Kenc)

This encrypted token ciphertext Ctoken is transmitted to the Receiver.

Upon receiving the ciphertext, the Receiver decrypts it using the shared symmetric key Kenc, recovering the hashed token′:

H′=ChaCha20−1(Ctoken,Kenc)

Next, the Receiver computes the hash of the received token T′ using SHA-2:

H′′=SHA−2(T′)

The Receiver compares the decrypted hash H′ with the newly computed hash H′′. If H′ = H′′, the token’s integrity is verified, and the Receiver can proceed with using the token. If the hashes do not match, the token is discarded as compromised.

3.4 Syncryption Framework

The signcryption technique not only encrypts the data but also generates a signature that proves the authenticity of the sender. This is crucial for preventing issues like spoofing and ensuring that the recipient can verify the sender’s identity [18]. As demonstrated below, are the steps in encryption algorithms. Algorithm 1 demonstrates Secure Symmetric Key Exchange, Algorithm 2 demonstrates Nonce generation and Encryption, while on Unsigncryption Framework, Algorithm 3 shows Nonce exchange and decryption, while Algorithm 4 shows Nonce integrity verification.

Encryption Algorithm

3.5 Unsigncryption Framework

This process ensures that only authorized recipients can read the token, confirm its authenticity, and verify its integrity.

Scheme

Given:

•   Sample token T∈{0,1}∗ (e.g., T = “sampleToken1234AbCd”)

•   RSA key generation and encryption/decryption operations

•   Symmetric encryption using ChaCha20 with key K chacha

•   SHA-2 hash function SHA2(⋅)

Steps:

i. RSA Key Generation

•   Server generates RSA key pair:

(sRSA−Pbkr=(es,ns),sRSA−Prk=(ds,ns))

•   Client generates RSA key pair:

(cRSA−Pbk=(ec,nc),cRSA−Prk=(dc,nc))

where n = p × q for large primes p, q and e, d are public and private exponents satisfying:

d×e≡1(modφ(n));φ(n)=(p−1)(q−1)

ii. Public Key Distribution

•   Both server and client upload cRSA-Pbk and sRSA-Pbk to the cloud for retrieval.

iii. Symmetric Key Generation

•   Server generates symmetric ChaCha20 key:

C20Prk←${0,1}256 (a uniformly random 256-bit key).

iv. Secure Symmetric Key Exchange

•   Server retrieves cRSA-Pbk from cloud and encrypts C20Prk using cRSA-Pbk:

cRSA−Pbk=RSA−OAEP.Enc(cRSA-Pbk,cRSA-Pbk)=C20PrkecC20Prkmodnc

•   Server sends ciphertext CC20Prk to client.

v. Client Decrypts Symmetric Key

•   Client uses private key cRSA-Prk to decrypt:

KC20Prk=RSA-OAEP.Dec(CC20Prk,cRSA-Prk)=C20PrkdcfC20Prkmodnc

vi. Token Generation

•   Server generates token T = “sampleToken1234AbCd”

vii. Token Hashing

•   Server computes SHA2 hash of T:

H=SHA2(T)

viii. Encrypt Hashed Token

•   Server generates nonce nonce←${0,1}96 (12 bytes for ChaCha20).

•   Server encrypts H with C20Prk:

CC20Prk=C20Prk.Enc(H,C20Prk,nonce)

ix. Server Sends Encrypted Hashed Token and Nonce

•   Sends pair (C T_C20Prk, nonce) to client.

x. Client Decrypts Hashed Token

•   Client decrypts received ciphertext:

H′=ChaCha20.Dec(CT,Kchacha,nonce)

xi. Integrity Verification

•   Client independently computes:

Hverify=SHA2(T)

•   Client verifies integrity:

Accept T iff H′ = H verify

•   Otherwise, reject T as compromised.

The asymmetric RSA algorithm is employed for the secure exchange of the symmetric key Kchacha. Specifically, the server generates the symmetric key Kchacha∈{0,1} and encrypts it using the client’s RSA public key PKclient = (ec,nc) as Ckey = Kecchacha mod nc. The ciphertext Ckey is transmitted to the client, who recovers the original symmetric key by computing Kchacha = Cdckey mod nc, where SKclient = (dc,nc) is the private key. This process guarantees confidentiality of Kchacha under the assumed hardness of the RSA problem.

Once both parties share the symmetric key Kchacha, the server computes a hash H = SHA2(T) of the token T∈{0, 1}∗ using a cryptographically secure hash function SHA2:{0, 1}∗→{0, 1}256. The hash H acts as a digest ensuring the integrity and authenticity of the token. The server then encrypts H with the symmetric key under the ChaCha20 stream cipher: CT = ChaCha20.Enc(H,Kchacha, nonce), where nonce∈{0, 1}96 is a unique, uniformly random nonce. This encryption produces ciphertext CT that is indistinguishable from random under the assumption of ChaCha20’s pseudorandomness and provides semantic security.

The client receives (CT,nonce) and decrypts the ciphertext to obtain H′ = ChaCha20.Dec(CT, Kchacha, nonce). The client then independently computes Hverify = SHA2(T) on the received plaintext token. Verification consists of checking the equality H′ = ?Hverify. If equality holds, the token’s integrity is assured; otherwise, the token is rejected as compromised. This verification process is predicated on the collision resistance of the SHA-2 function and the correctness of the encryption/decryption algorithms.

3.6 Correctness

Given a plaintext token (M), the hybrid encryption of (M) via RSA for key exchange and ChaCha20 for actual data encryption must ensure that any unauthorized entity cannot derive (M) from its ciphertext without knowledge of the private key. This is enforced through the one-way nature of RSA and the pseudo-randomness of ChaCha20 [19].

Token Generation and Integrity Hashing:

The correctness of the hashed token is assured by the properties of the hash function, specifically pre-image resistance, second pre-image resistance, and collision resistance [16,20]. It is computationally infeasible for an adversary to find a different input (token T) that hashes to the same value (H). H = SHA2(T) [21].

3.6.1 Token Encryption

The hashed token H is then encrypted using ChaCha20, Let the encrypted token ciphertext be C = ChaCha20(H, K_chacha). The client later decrypts the ciphertext C to recover the original hash value H:

H = ChaCha20−1(C, Kchacha). Since ChaCha20 is a secure symmetric encryption scheme, it guarantees that if the correct key is used, the decryption will successfully recover the original message H. After decryption, the client recomputes the hash of the plaintext token T using SHA-2: H′ = SHA2(T). Any change to the token T will result in a completely different hash value; if H ≠ H′, the token has been altered, the client can safely reject the token.

3.6.2 RSA Key Exchange and Symmetric Key Decryption

•   Let the encrypted symmetric key be: CRSA = RSAclient(Kchacha), The client decrypts the received ciphertext C_RSA using their private RSA key to recover the shared ChaCha20 key: Kchacha = RSAprivate−1(CRSA).

•   RSA Authentication

Only the server that possesses the correct private RSA key can encrypt the symmetric key that the client can then decrypt. This guarantees that the token is coming from the legitimate server and not from an attacker. CRSA = RSAserver(Kchacha).

To protect against replay attacks, a timestamp or nonce can be included with the token during generation. The client checks if the timestamp or nonce is valid (not expired or reused). This check prevents the re-use of a previously captured token, ensuring that the same token cannot be replayed in a different session. The inclusion of a timestamp or nonce (denoted as TS or N) ensures that the token is valid only within a specific time window or context. Ttoken = {T, TS, N}. If the client detects any reuse of TS or N, the token is considered invalid and discarded, ensuring replay attack resistance. This technique prevents the reuse of tokens outside their intended valid period [22]. The correctness of the proposed Hybrid Encryption Model is ensured through key cryptographic principles. RSA guarantees that only the intended recipient (the client) can decrypt the symmetric key, ensuring secure communication. ChaCha20 provides confidentiality by securely encrypting the token during transmission. SHA-2 ensures integrity, allowing both the server and client to verify that the token has not been altered.

4  Security Analysis of the Proposed Scheme

We simulated attacks such as eavesdropping, man-in-the-middle, and replay attacks. The system successfully mitigated all attacks due to the secure key exchange, token encryption, and nonce management.

4.1 Hash Consistency

•   The client computes:

Hverify = SHA2(T)

•   Because hashing is deterministic,

Hverify = HT

Equality Check

•   Since:

H′T = HT = Hverify

The verification succeeds, and thus the scheme correctly enables integrity verification of the token T.

4.2 Proof of Confidentiality (IND-CCA Security of Hybrid Scheme)

Demonstrates that the confidentiality of the transmitted data is preserved from the sender to the receiver, even in the presence of adversaries.

Game IND-CCAΠ

     i.  Challenger runs (PKR, SKR)←Gen(1λ).

    ii.  Adversary A outputs two tokens T0, T1 of equal length.

   iii.  Challenger samples b←{0, 1}, generates:

–  K←{0, 1}256

–  Hb = SHA2(Tb)

–  Ckey←RSA-OAEP.Enc(PKR, K)

–  Ctok←ChaCha20.Enc(K,nonce, Hb)

    iv.  Challenger gives ciphertext C∗ = (Ckey, Ctok, nonce) to A.

     v.  A may query a decryption oracle Dec(⋅) on any ciphertext except C∗

    vi.  A outputs guess b′.

   vii.  A wins if b′ = b.

The advantage of A is:

Adv∏ind−cca(A)=|Pr[b′=b]−12|

Setup and Notation

Let the security parameter be λ. Let our scheme Π consist of algorithms:

Π=(Gen,EncKey,DecKey,EncToken,DecToken,Verify)

where:

Gen generates RSA key pairs.

EncKey encrypts symmetric key K with RSA-OAEP.

EncToken encrypts token hash H = SHA2(T)H = SHA2(T)H = SHA2(T) using ChaCha20.

Verify accepts if the decrypted hash matches the recomputed hash.

We model the channel as controlled by a probabilistic polynomial-time (PPT) adversary A, who can intercept, modify, replay, and inject messages.

λ be the security parameter.

(PKclient, SKclient) be the client’s RSA key pair generated securely.

Kchacha ∈{0, 1}256 be the symmetric key generated uniformly at random by the server.

T be the token.

H = SHA2(T) be the hash of the token.

Ckey = RSA-OAEP.Enc(PKclient, Kchacha) be the RSA encryption of the symmetric key.

CT = ChaCha20.Enc(H, Kchacha, nonce) be the ChaCha20 encryption of the hash with a unique nonce.

Assume:

RSA is IND-CCA- Indistinguishability under Chosen Plaintext Attack secure (e.g., RSA-OAEP). ChaCha20 is IND-CPA secure, Indistinguishability under Chosen Ciphertext Attack (pseudorandom stream cipher). It is known for its speed and efficiency, particularly in constrained environments such as mobile devices [23]. Similarly, SHA2 is collision-resistant and pre-image resistant. We use RSA-OAEP (or an RSA-KEM) for encrypting the ChaCha20 key to achieve IND-CCA security.

If RSA-OAEP is IND-CCA secure and ChaCha20 is IND-CPA secure, then ∏ is IND-CCA secure.

4.3 Proof of Unforgeability

(a) Setting and Goal

•   Let T be the token and H = SHA2(T) its hash.

•   The token hash is encrypted symmetrically:

CT=ChaCha20.Enc(H,Kchacha,nonce)

•   Kchacha is securely shared between server and client.

•   The client accepts a ciphertext-token pair (C′T,T′) only if:

ChaCha20.Dec(C′T,Kchacha,nonce′)=SHA2(T′)

Unforgeability means no efficient adversary can produce a valid ciphertext-token pair (C′T, T′) different from the original that passes verification.

The integrity of the token is preserved, meaning it cannot be altered without detection since any tampering is easily identified.

(b) Adversary Model

The adversary A, a probabilistic polynomial-time adversary, meaning that the attacker operates within polynomial time and uses randomness in their approach (e.g., making probabilistic decisions or guesses). This model assumes that the adversary has computational resources similar to any reasonable attacker in a real-world scenario. The adversary has access to ciphertexts (i.e., encrypted versions of the token and its hash) that have been transmitted between the server and client. This access allows the adversary to perform various actions, like modifying the ciphertexts. The attacker can alter the encrypted token or token hash in an attempt to change the message. Replay the ciphertexts: may attempt to intercept and resend previous ciphertext-token pairs to the system, hoping to trick the client or server into accepting a duplicate token. Create New Ciphertext-Token Pairs, attempt to generate entirely new ciphertext-token pairs, and attempt to pass them off as legitimate. Despite having access to the ciphertexts, the adversary does not know the symmetric key (Kchacha20) used for token encryption. Therefore, the attacker cannot directly decrypt the token hash or manipulate the encryption process. Incorporating SHA-256 or other secure hashing algorithms in conjunction with RSA encryption can enhance the verification processes, ensuring that data integrity is maintained during transmission [24,25].

4.4 Proof (Hybrid Argument Sketch with Bound)

We use a standard hybrid proof:

•   Hybrid H0: real game.

•   Hybrid H1: replace Ckey_{key}Ckey encryption of real K with encryption of random K′.

Any distinguisher between H0 and H1 breaks RSA-OAEP IND-CCA.

•   Hybrid H2: replace ChaCha20 output with random string.

Any distinguisher between H1 and H2 breaks ChaCha20 pseudorandomness/IND-CPA.

In H2, Ctok is information-theoretically independent of b, so:

Pr[b′=b]=12

Adv∏ind−cca(A)≤AdvRSA−OAEPind−cca(B1)+AdvChaCha20ind−cpa(B2)

Integrity/Unforgeability (EUF- CMA- Style for Token Acceptance)

Our current scheme accepts a token if:

Dec(Ctok)=SHA2(T)

So the adversary wins if they can produce (Ctok,T′) such that:

ChaCha20.Dec(K,nonce′,C′tok)=SHA2(T′)

Game ForgeΠ

     i.  Challenger generates RSA keys and sends PK to adversary.

    ii.  Challenger picks symmetric key K.

   iii.  Adversary gets oracle access to:

–  EncToken(T) returns (Ctok, nonce)

   iv.  Finally, adversary outputs (T′, C′ tok, nonce′)

    v.  Adversary wins if:

–  Verify(T′, C tok, nonce′) = 1

–  and (T′, C tok′, nonce′) was not output by oracle.

The advantage is:

Adv∏forge(A)=Pr[AwinsForge∏]

Theorem 2 (Unforgeability/Integrity)

If SHA2 is collision-resistant and ChaCha20 behaves as a Pseudorandom Function stream cipher, then the scheme is unforgeable.

Proof Outline with Case Analysis + Bound

Assume A produces a successful forgery (T′, C′tok′, nonce′).

There are two cases:

Case 1: T′ ≠ T but SHA2(T′) = SHA2(T)

Then A has found a collision.

So we can build B1 that outputs a SHA2 collision whenever A forges:

Adv∏forge(A)≤AdvSHA2coll(B1)+Pr[Case2]

Case 2: SHA2 (T′) is new and yet the ciphertext decrypts correctly

Then A produced a ciphertext that decrypts under an unknown keystream into a valid digest. This breaks the pseudorandomness of ChaCha20.

So we build B2 that distinguishes ChaCha20 output from random.

Hence:

Pr[Case2]≤AdvChaCha20prf(B2)

Final bound:

Adv∏forge(A)≤AdvSHA2coll(B1)+AdvChaCha20prf(B2)

4.5 Non-Repudiation/Authentication

RSA Signature

Sig←RSA.Sign(SKS,SHA2(Ckey//Ctok//nonce))

The receiver verifies the signature with PKs, This gives true non-repudiation and authentication.

Replay Attack Resistance (Formal)

Lemma (Replay Protection):

If each nonce is unique per session and receiver rejects reused nonces or timestamps outside a window, then replay attempts fail with probability 1 (except negligible probability of nonce collision).

Nonce collision probability:

Pr[nonce_collision]≈q2297

(using birthday bound for 96-bit nonce with q transmissions)

Forgery Goal:

The adversary’s primary objective is to create a forgery, meaning they attempt to generate a new ciphertext-token pair (C′T, T′) such that:

C′T ≠ CT and ChaCha20.Dec(C′T,Kchacha,nonce′) = SHA2(T′), C′T ≠ CT: The adversary tries to generate a new ciphertext (C′T, T′) that is different from the original ciphertext (CT) of the token hash.

ChaCha20.Dec(C′T, Kchacha, nonce′) = SHA2(T′): The adversary aims to deceive the system by creating a new ciphertext (C′T) and a corresponding token (T′) such that, when decrypted using the symmetric key (Kchacha) and a nonce (nonce’), the result matches the hash of the token (SHA2(T′)).

If the adversary succeeds, the new pair (C′T, T′) would pass the client’s verification check, thereby allowing the attacker to introduce a forged, invalid token into the system.

In essence, the adversary is trying to manipulate the ciphertexts or generate new ones in a way that appears valid to the client, despite lacking knowledge of the encryption key. However, the security of the system relies on the assumption that such forgeries are computationally infeasible, meaning the adversary cannot create a valid ciphertext-token pair without the correct symmetric key and without being detected.

Proof Sketch

Step 1: Forgery implies breaking hash collision resistance or ChaCha20 security

•   Suppose adversary A produces a forgery (C′T, T′).

•   Two cases arise:

1. T ′≠T′ =T but, SHA2(T′) = SHA2(T)

This implies A found a collision in SHA-2, which is assumed computationally infeasible.

2. C′T ≠C T but decrypts to some valid hash H′ = SHA2(T′) different from original hash H.

Since adversary A does not know Kchacha, this implies A can produce a ciphertext C′T that decrypts under ChaCha20 to a valid hash, thus breaking the indistinguishability or unforgeability of ChaCha20 encryption.

Step 2: Security assumptions

•   SHA-2 collision resistance: It is infeasible to find two distinct inputs with the same hash.

•   ChaCha20 encryption security: Given a key and nonce, ciphertexts are pseudorandom and resistant to forgery without key knowledge.

•   Key secrecy via RSA: The adversary does not have access to Kchacha, as it is securely exchanged under RSA.

Step 3: Reduction

•   If A succeeds in forging a valid ciphertext-token pair, then either:

An adversary B can be constructed to find SHA-2 collisions.

Or

an adversary C can be constructed to forge ChaCha20 ciphertexts without knowing the key.

bothAdvcollisionSHA2(B)andAdvforgeChacha20(C)

Formal Bound on Forgery Advantage

Pr[ForgerysuccessbyA]≤AdvcollisionSHA2(B)+AdvforgeChacha20(C)

The proposed scheme is unforgeable under the assumptions that SHA-2 provides collision resistance, ChaCha20 ensures pseudorandomness and ciphertext unforgeability, and RSA enables secure key distribution. The integrity and authenticity of the system are guaranteed by the collision resistance of SHA-2, which prevents the generation of forged matching hashes; the security properties of ChaCha20, which safeguard against ciphertext forgery; and the secure key exchange offered by RSA, which restricts key knowledge to legitimate communicating parties.

5  Performance Evaluation

To assess the effectiveness and efficiency of the Hybrid Encryption Model for Secure Token Distribution, we conducted a performance evaluation based on key metrics.

5.1 Experimental Setup

This study evaluates the encryption and decryption performance of the proposed hybrid token transmission scheme using Python implementations. Experiments were repeated for N = 10,000 trials to ensure statistical stability. Tokens were generated at multiple sizes (32, 64, 128, 256, 512 B, 1, 4, and 16 KB) to represent typical authentication token payloads and extended workloads. Each trial used a freshly generated random token, a uniformly random 96-bit nonce, and a random 256-bit ChaCha20 session key. RSA key encapsulation employed RSA-OAEP with 2048-bit modulus, using SHA-256 as the OAEP hash function. Hash integrity checks used SHA-256 (SHA-2 family).

Benchmarking was conducted using time.perf_counter() with 1000 warm-up iterations to reduce interpreter start-up bias. All results are reported as mean ± 95% confidence intervals (CI), computed as:

CI=x−±1.96.sNCI

where x− is the mean runtime, s the standard deviation, and N the number of trials.

Hardware: Intel Core i7-9700K CPU, 16 GB RAM.

Software: Python 3.8 with PyCryptodome for RSA, PyNaCl for ChaCha20, and hashlib for SHA-2.

5.2 Hardware Portability and Scalability Considerations

Although the experimental evaluation was conducted on a desktop-class processor, the proposed hybrid encryption model is designed to be hardware-agnostic. In particular, ChaCha20 is known for its efficiency on constrained platforms, including ARM-based and IoT devices, where hardware acceleration for AES may be unavailable. RSA key exchange is performed only during session initialization, while ChaCha20 and SHA-2 dominate runtime performance during token transmission. This separation minimizes computational burden on resource-constrained devices. Based on prior empirical benchmarks reported in the literature, ChaCha20 consistently outperforms AES on low-power CPUs and embedded systems, suggesting that the relative performance advantages observed in this study are expected to hold—and potentially improve—on IoT-class hardware.

Future work will extend the experimental evaluation to heterogeneous platforms, including embedded and mobile devices, to quantify energy consumption and performance under constrained operating conditions.

Encryption/Decryption Time

Table 2 illustrates that, RSA encryption is the most time-consuming operation, as expected with the asymmetry of the algorithm. ChaCha20 encryption is very efficient, especially for larger data sizes,extremely fast, providing real-time encryption and decryption of the token hash. SHA-2 hashing is relatively fast and has minimal impact on the overall time.

5.3 Metrics’ Improvement

In Table 3, we report both latency (ms/token) and throughput (Mbps). Throughput is computed as:

Throughput(Mbps)=8⋅TokenSize(Bytes)Time(s)×10−6

5.4 Results Summary (Mean ± 95% CI)

I computed:

     i.  RSA key encapsulation time (Enc/Dec)

    ii.  ChaCha encryption time

   iii.  ChaCha decryption time

    iv.  Total time per transmission

     v.  Throughput (Mbps)

    vi.  Success rate

Key Observations

•   RSA operations dominate total time (especially decryption).

•   ChaCha20 throughput improves with larger token sizes (as expected).

•   Success rate is 100% across all sizes (no simulated corruption introduced here—this is crypto runtime benchmarking).

To ensure reproducibility, we provide the full benchmarking scripts and generated dataset. The evaluation runs N = 2000 Monte Carlo iterations per token size and reports mean ± 95% confidence intervals. RSA uses OAEP padding with SHA-256 and 2048-bit modulus, ChaCha20 uses a 256-bit key with a 96-bit nonce (ChaCha20-Poly1305). Token sizes range from 32 B to 16 KB to evaluate performance under both lightweight and heavy transmission workloads. Results are reported as latency (ms/token) and throughput (Mbps).

5.5 Key Generation Time

RSA key generation takes approximately 20 ms, which is suitable for real-time key exchange. ChaCha20 key generation is done in constant time since it is a symmetric algorithm. This timing is significant in secure communications, where the rapid establishment of secure keys is essential for low-latency interactions [26].

In Monte Carlo simulation, by running the model several times with random inputs to simulate the behavior of a system, we record some processes, such as the time taken for encryption, the probability of token integrity failure, and other system-related factors. The success rate of the token integrity verification (i.e., how often the hash comparison between the client and server passes). The following metric were also considered.

     i.  The likelihood of data being compromised during transmission, affecting the system’s reliability.

    ii.  Performance characteristics such as the time taken for encryption, decryption, and verification.

We simulated a token integrity check across multiple iterations (with random token failures), assuming:

     i.  A small probability of token corruption during transmission (e.g., 1% chance that a token’s integrity is compromised).

    ii.  A number of iterations (e.g., 10,000 trials) to simulate the system’s behavior over time.

The Monte Carlo method estimated how often the token integrity verification fails.

Fig. 2 displays Monte Carlo simulation results, illustrating the following:

Figure 2: The histogram visualizes the distribution of success and failure outcomes in the simulation.

•   Success Rate: 99.02% of the time, the token integrity check passed (meaning the hash comparison between the client and server matched).

•   Failure Rate: 0.98% of the time, the token integrity check failed (indicating potential corruption or tampering with the token during transmission). Additionally, the formulas to these results were derived from the metrics displayed in Table 4 below.

Statistical Confidence Intervals

The confidence intervals were computed using the following formula:

•   Use the formula for 95% CI:

CI=x−±1.96⋅sN

where:

•   x− = mean of the sample

•   s = standard deviation of the sample

•   N = number of trials (e.g., 10,000)

Data and Evaluations

Here is the generated dataset and statistical evaluation of the results, including:

1. Encryption time (ms)

2. Decryption time (ms)

3. Throughput (Mbps)

4. Confidence intervals (95%)

Benchmark Code (Python)

5. “““Benchmark code for Hybrid Encryption evaluation (RSA-OAEP + ChaCha20-Poly1305)

6. Reproduces performance tables in Section 6.

7. “““

8. import time, math, statistics

9. import numpy as np

10. import pandas as pd

11. from dataclasses import dataclass

12. from cryptography.hazmat.primitives.asymmetric import rsa, padding

13. from cryptography.hazmat.primitives import hashes

14. from cryptography.hazmat.primitives.ciphers.aead import ChaCha20Poly1305

15. TOKEN_SIZES = [32, 64, 128, 256, 512, 1024, 4096, 16, 384]

16. TRIALS = 2000

17. WARMUP = 200

18. RSA_KEY_SIZE = 2048

19. NONCE_SIZE = 12

20. CHACHA_KEY_SIZE = 32

21. SEED = 12,345

22. rng = np.random.default_rng(SEED)

23. def gen_token(n):

24.    return rng.bytes(n)

25. def gen_nonce():

26.    return rng.bytes(NONCE_SIZE)

27. def gen_key():

28.     return rng.bytes(CHACHA_KEY_SIZE)

29. private_key = rsa.generate_private_key(public_exponent = 65,537, key_size = RSA_KEY_SIZE)

30. public_key = private_key.public_key()

31. def rsa_oaep_enc(k: bytes) -> bytes:

32.     return public_key.encrypt(k, padding.OAEP(mgf = padding.MGF1(algorithm =        hashes.SHA256()), algorithm = hashes.SHA256(), label = None))

33. def rsa_oaep_dec(ct: bytes) -> bytes:

34.     return private_key.decrypt(ct, padding.OAEP(mgf = padding.MGF1(algorithm =        hashes.SHA256()), algorithm = hashes.SHA256(), label = None))

35. def chacha_encrypt(token: bytes, k: bytes, nonce: bytes) -> bytes:

36.    return ChaCha20Poly1305(k).encrypt(nonce, token, b”“)

37. def chacha_decrypt(ct: bytes, k: bytes, nonce: bytes) -> bytes:

38.     return ChaCha20Poly1305(k).decrypt(nonce, ct, b”“)

39. # Rest of the code to generate data and evaluate timings

40. # Complete code for benchmark

To ensure reproducibility, we provide the full benchmarking scripts and generated dataset as shown in Table 5. The evaluation runs N = 2000 Monte Carlo iterations per token size and reports mean ± 95% confidence intervals. RSA uses OAEP padding with SHA-256 and 2048-bit modulus, ChaCha20 uses a 256-bit key with a 96-bit nonce (ChaCha20-Poly1305). Token sizes range from 32 B to 16 KB to evaluate performance under both lightweight and heavy transmission workloads. Results are reported as latency (ms/token) and throughput (Mbps) as shown in Fig. 3.

Figure 3: Plot (total time vs. token size).

5.6 Other Algorithms-Selection of Commonly Used Hybrid Algorithms for Comparison

Below are three common hybrid encryption models, each incorporating a combination of well-established cryptographic algorithmic models.

(a) Model 1: Diffie-Hellman Key Exchange with AES and SHA-512

     i.  Diffie-Hellman (DH) for key exchange (asymmetric).

    ii.  AES for token encryption (symmetric).

   iii.  SHA-512 for token integrity check (hashing).

(b) Model 2: Elliptic Curve Diffie-Hellman (ECDH) with AES and SHA-256

     i.  ECDH for key exchange (asymmetric).

    ii.  AES for token encryption (symmetric).

   iii.  SHA-256 for token integrity check (hashing).

(c) Model 3: RSA with AES and SHA-256

     i.  RSA for key exchange (asymmetric).

    ii.  AES for token encryption (symmetric).

   iii.  SHA-256 for token integrity check (hashing).

After a simulation, a comparison was made. The results of the models compared to the main algorithm (RSA + ChaCha20 + SHA2) were based on success rates and failure rates for each model, presented as percentages. Table 6 and Fig. 4 illustrates success rates and failure rates for each algorithm were weighed based on the following key performance factors:

Figure 4: Comparison table with the success rates and failure rates of the different hybrid encryption models.

     i.  Key Exchange Time: How long it takes to exchange keys.

    ii.  Encryption Time: The time it takes to encrypt data.

   iii.  Resource Usage: The amount of computational power or memory required.

    iv.  Latency: The delay before or during data encryption/decryption.

     v.  Throughput: The amount of data processed in a given period.

    vi.  Scalability: How well the system performs as the load or system size increases.

5.7 Clarification of Efficiency Metric

The efficiency metric reported in Table 5 is defined as the inverse of total cryptographic processing time (Efficiency = 1/Total Time) and is intended as a normalized inverse-latency indicator, not a direct throughput measure. This formulation enables relative comparison of cryptographic responsiveness across hybrid schemes under identical simulation conditions. To align with standard performance evaluation practices, we additionally derive throughput (Mbps) from the measured encryption times and token sizes, which provides a hardware-independent and widely accepted metric for cryptographic performance comparison. The throughput-based results confirm the conclusions drawn from latency analysis. The proposed RSA + ChaCha20 + SHA2 scheme achieves the highest throughput due to ChaCha20’s stream-based design and low computational overhead. This validates that the observed performance gains are not artifacts of the efficiency formulation but are consistent with standard cryptographic benchmarking metrics

5.8 Simulation Results

The Monte Carlo simulation results for the three new key exchange models with AES and SHA hashing algorithms

i.   DH + AES + SHA-512: This model shows a moderate failure rate due to the Diffie-Hellman key exchange’s computational overhead, despite the use of the strong SHA-512 hashing algorithm.

ii.   ECDH + AES + SHA-256: This model performs well with a lower failure rate, leveraging the more efficient Elliptic Curve Diffie-Hellman (ECDH) key exchange and the widely used SHA-256 hashing algorithm.

iii.   RSA + AES + SHA-256: This model has the lowest failure rate, benefiting from the strength of RSA for key exchange and the efficiency of AES and SHA-256.

In the comparison, RSA + AES + SHA-256 offers the best performance in terms of both success rate and low failure rate, while ECDH + AES + SHA-256 is also very efficient with minimal overhead. DH + AES + SHA-512 has a slightly higher failure rate due to the complexity of Diffie-Hellman. This effectiveness is particularly notable in environments where secure data transmission is critical, as it ensures both confidentiality and data integrity in a time-efficient manner [27].

5.9 Main Hybrid Model RSA + ChaCha20 + SHA2-RSA Compared to the Selected Models

This section compares different cryptographic models that combine key exchange algorithms, encryption methods, and hashing functions, highlighting their trade-offs in security, efficiency, and performance.

5.9.1 Diffie-Hellman (DH) + AES + SHA-512

Diffie-Hellman is a secure key exchange algorithm, but it can be slower compared to RSA. It involves exponentiation and can become computationally expensive for large groups, leading to increased processing time and a higher failure rate. The computational overhead associated with DH arises from the requirement for modular exponentiation, which can result in increased processing times, particularly with larger groups [28]. This computational expense is a critical consideration, as it can lead to slower key generation and potentially higher failure rates in performance-sensitive environments [29]. The use of AES for encryption is strong, but SHA-512 (while secure) requires more processing power compared to SHA-256. The combination of these factors can lead to a higher failure rate due to the increased computational overhead.

5.9.2 Elliptic Curve Diffie-Hellman (ECDH) + AES + SHA-256

ECDH is more efficient than traditional Diffie-Hellman, as it provides a higher level of security with shorter key lengths. While it performs better than DH in many cases, it still requires more computation and overhead in key exchange compared to RSA, which is relatively faster in typical scenarios. The computational load associated with elliptic curve operations can lead to performance limitations, particularly when compared to the more straightforward processes associated with RSA key exchange [30]. AES encryption and SHA-256 hashing are both efficient and secure, but this model still faces performance limitations due to the complexities involved in ECDH key exchange.

5.9.3 RSA + AES + SHA-256

RSA is more efficient in terms of key exchange than ECDH or DH, particularly for moderate-sized keys (2048-bits or 3072-bits). AES is a very strong encryption algorithm, but it does come with more overhead than ChaCha20 for certain devices or systems with constrained resources. However, it’s still a reliable choice and commonly used in many security protocols. SHA-256 is very secure and efficient for hashing, but this model is slightly less efficient than the main algorithm, particularly due to the overhead of AES compared to ChaCha20. Research indicates that implementing AES can incur substantial communication overhead when utilizing advanced techniques, such as in secure computation environments that incorporate Yao’s garbled circuits [31]. This overhead can be significant, especially in situations where fast processing is critical or where devices have limited processing capability. In contrast, the DH (Diffie-Hellman) key exchange method combined with AES and SHA-512 experiences a slight increase in failure rates, attributed to the complexities involved in the Diffie-Hellman protocol [32]. The increased overhead stems from the need for more extensive computations and larger parameter sizes, which can contribute to errors during key negotiation and may result in time losses, particularly in situations with variable network conditions or when key exchanges are frequent [33].

The other models, while secure, incur additional computational overhead due to their more complex cryptographic processes (especially Diffie-Hellman and ECDH), which result in slightly lower success rates and higher failure rates. The RSA + ChaCha20 + SHA2 algorithm performs better than the other models due to the combination of RSA’s efficient key exchange, ChaCha20’s fast encryption, and SHA2’s reliable hashing. This model strikes an optimal balance between performance and security, particularly in environments where efficiency and low overhead are important, such as on mobile or low-resource devices.

The proposed model also performs better in terms of both success rate and failure rate compared to the other models. Table 7 summarizes the efficiency factors for cryptographic algorithms in terms of key exchange time, encryption time, resource usage, latency, throughput, and scalability.

5.10 Suitability Analysis for Resource-Constrained IoT Devices

Although the experimental evaluation of the proposed hybrid encryption scheme was conducted on a desktop-class platform (Intel Core i7), the design of the protocol is explicitly motivated by the security requirements of resource-constrained Internet of Things (IoT) environments. This subsection discusses the applicability of the proposed RSA + ChaCha20 + SHA-2 framework under typical IoT constraints in terms of computation, memory, energy consumption, and network conditions.

5.10.1 Computational Constraints

IoT devices such as sensors, wearable devices, and embedded controllers typically operate with limited CPU frequency (48–240 MHz) and memory (tens to hundreds of kilobytes). In such environments, heavyweight cryptographic operations can significantly degrade performance. The proposed scheme mitigates this challenge by restricting the use of RSA exclusively to the initial key exchange phase, while employing ChaCha20 for all bulk encryption tasks. ChaCha20 has been widely recognized for its superior performance on low-power processors compared to AES, particularly in the absence of hardware acceleration, making it well suited for IoT-class microcontrollers.

5.10.2 Memory and Energy Efficiency

Compared to block-cipher-based solutions, ChaCha20 requires minimal memory footprint and exhibits predictable execution patterns, reducing both RAM usage and energy consumption. Since IoT devices are often battery-powered, the use of a lightweight stream cipher for token protection significantly improves system sustainability. The SHA-2 hashing operation is executed only on short token payloads, further minimizing computational overhead.

5.10.3 Communication Overhead

In IoT deployments, network bandwidth is frequently constrained and unreliable. The proposed model reduces communication overhead by transmitting only encrypted token hashes rather than full token contents, thereby minimizing packet size and lowering retransmission probability in lossy networks.

5.10.4 Comparison with Typical IoT Security Stacks

Many existing IoT authentication frameworks rely on RSA + AES combinations, which impose higher computational costs on constrained devices. In contrast, the RSA + ChaCha20 + SHA-2 configuration offers a more suitable balance between security and efficiency, particularly for devices lacking cryptographic co-processors.

5.10.5 Limitations of the Current Evaluation

We acknowledge that the present experimental setup does not include deployment on physical IoT hardware such as ARM Cortex-M or ESP-class microcontrollers. However, the performance characteristics reported in this study represent an upper-bound benchmark, and the algorithmic choices are specifically aligned with lightweight cryptographic standards recommended for embedded and IoT systems. Future work will extend this evaluation to real hardware platforms to further validate energy consumption, latency, and memory footprint under realistic IoT workloads.

This analysis demonstrates that, although evaluated in a desktop environment, the proposed framework is architecturally aligned with IoT constraints and remains suitable for secure token distribution in resource-limited devices.

6  Application/Application Scenario

The Hybrid Encryption Model for Secure Token Distribution Scheme can be applied in various domains where secure token transmission is essential, such as online authentication systems, API token validation, and financial transactions. For example, consider an online banking system where users authenticate themselves via tokens during secure transactions.

In this scenario, the server (e.g., the bank’s authentication system) generates a unique token for each transaction. The server first generates an RSA key pair for asymmetric encryption and uploads its public key to a secure cloud storage. The client (the user) does the same. A random symmetric key is then generated by the server for encrypting the token with ChaCha20 encryption.

Before sending the token, the server hashes it using SHA-2, ensuring the integrity of the token. The token is then encrypted using the symmetric key and sent over a secure channel. The client receives the encrypted token, decrypts it with the shared ChaCha20 key, and verifies the token’s integrity by comparing the hash with the one computed from the received plaintext.

In modern banking and financial transactions, the importance of robust cryptographic methods, particularly regarding secure token generation and dissemination, cannot be overstated. The proposed system employs an RSA key pair for asymmetric encryption, which is critical for ensuring the confidentiality and integrity of transaction data. RSA provides a method for securely exchanging keys across an insecure medium, making it suitable for banking applications where security is paramount [34]. The generation of a unique token for each transaction enhances security by ensuring that each transaction is treated independently and recorded uniquely, thus minimizing the risks associated with replay attacks.

6.1 Quantitative Risk Assessment for Banking Scenario

To complement the qualitative application discussion, we provide a quantitative risk assessment for the online banking use case on Table 8. Risks are evaluated based on two dimensions: (i) likelihood of occurrence and (ii) potential impact, following standard information-security risk assessment practices.

The proposed hybrid encryption scheme significantly reduces the likelihood of replay, forgery, and interception attacks through nonce-based freshness, RSA-secured key exchange, and ChaCha20 encryption. Residual risks are primarily associated with operational and infrastructure-level threats rather than cryptographic weaknesses.

Medical applications have also begun to implement hybrid encryption models to protect sensitive patient data during cloud storage. Haripriya and Brintha describe a privacy-preserving medical cloud architecture that utilizes hybrid key encryption paired with blockchain-based verification [35]. This approach safeguards patient data shared across platforms by ensuring that only authorized healthcare providers can access and decrypt sensitive information, thus preventing unauthorized access and maintaining confidentiality.

The Trusted Authority (TA) can be incoporated to verify the identities of both the server and the client. The TA ensures that any dispute, such as an accusation of fraud, can be traced back to the legitimate source by checking the registered identities. The use of nonces or timestamps in the protocol ensures protection against replay attacks, as each token is unique to its transaction.

This application scenario demonstrates how the hybrid encryption scheme provides confidentiality, integrity, and authentication in a real-world environment, while protecting against common threats like Man-in-the-Middle and Replay Attacks. It can be adapted for use in other domains such as healthcare, e-commerce, or IoT-based systems, ensuring secure token transmission for sensitive data exchange.

6.2 Quantified Application-Level Evaluation

To complement the qualitative application discussion, we conducted an application-level simulation to assess the reliability of the proposed scheme in a realistic transaction environment. Using the same cryptographic configuration described in Section 6, we simulated 1000 consecutive token-based authentication transactions under a banking scenario.

Each transaction involved secure session establishment, token hashing, encryption, transmission, decryption, and integrity verification. A probabilistic fault model was applied to emulate network disturbances and random token corruption, with an assumed disturbance rate of 0.1%. Across the 1000 simulated transactions, the system achieved a success rate of 99.9%, with only a single failed verification event caused by induced transmission corruption. No instances of undetected tampering or successful replay were observed. These results indicate that the proposed hybrid encryption model maintains high reliability and operational stability under sustained transaction loads, supporting its suitability for deployment in real-world, high-availability environments such as online banking, financial APIs, and secure service authentication.

6.3 Limitations of the Proposed Scheme

Despite the advantages of the proposed hybrid encryption model, several limitations should be acknowledged. First, the scheme relies on RSA for asymmetric key exchange. While RSA remains secure against classical adversaries, it is vulnerable to future large-scale quantum computers running Shor’s algorithm. As such, the current design does not provide post-quantum security guarantees. Future work will explore integrating quantum-resistant key exchange mechanisms, such as lattice-based or code-based cryptography.

6.4 Latency and User Experience Constraints

In high-frequency transaction systems such as online banking platforms, even small cryptographic delays can negatively affect user experience. RSA-based key exchange, while secure, introduces non-trivial computational overhead during session initialization. In this context, the proposed model mitigates latency concerns by limiting RSA operations strictly to the key exchange phase, while delegating bulk token protection to ChaCha20, which provides near-real-time encryption performance. This design ensures that security does not come at the expense of system responsiveness.

6.5 Integration with Legacy Authentication Systems

Many financial institutions rely on legacy identity and access management infrastructures that were not designed for hybrid cryptographic protocols. To ensure compatibility, the proposed model is designed as a modular security layer that operates independently of backend business logic, allowing seamless integration with existing OAuth, JWT, or API gateway–based token systems without architectural overhaul. scalability remains a practical consideration in high-throughput environments. Although ChaCha20 supports fast symmetric encryption, the RSA-based key exchange may become a bottleneck in systems requiring the establishment of thousands of new secure sessions per second. In scenarios exceeding 1000 token exchanges per second, session caching or group key management techniques may be required to maintain low latency. Finally, the performance evaluation focuses primarily on computational efficiency and does not yet incorporate energy consumption or long-term key management overhead, which are important factors for large-scale deployments.

6.6 Ethical and Privacy Considerations

The proposed scheme introduces a Trusted Authority (TA) to facilitate secure key distribution, which raises important ethical and privacy considerations. While the TA improves trust and simplifies key management, it also represents a potential point of centralization and surveillance risk. Compromise or misuse of the TA could undermine user privacy and system-wide security. To mitigate these concerns, practical deployments should consider decentralizing trust through certificate transparency mechanisms, distributed key infrastructures, or blockchain-based verification services. Additionally, strict access-control policies and audit mechanisms should govern TA operations to prevent abuse.

From a privacy perspective, the system is designed to protect token confidentiality and integrity; however, metadata such as timing patterns and communication frequency may still be observable. Designers should therefore combine the proposed cryptographic protections with traffic analysis resistance techniques when deploying in sensitive environments. By explicitly acknowledging these ethical and privacy dimensions, the proposed model aligns with responsible security engineering principles and supports trustworthy real-world deployment.

6.7 Future Research Directions

Several promising research directions emerge from this work.

First, future versions of the proposed hybrid encryption model can integrate post-quantum cryptographic primitives to address the long-term vulnerability of RSA to quantum attacks. In particular, lattice-based key exchange mechanisms such as CRYSTALS-Kyber and digital signature schemes such as Dilithium offer strong candidates for replacing RSA while preserving the hybrid architecture. Second, scalability optimization represents an important avenue for further study. While the current design supports efficient token encryption using ChaCha20, large-scale systems processing thousands of tokens per second may benefit from session-key caching, group key management, or hardware-assisted acceleration. Investigating these techniques can significantly improve throughput in high-demand environments such as financial services and large IoT deployments. Third, future work will explore energy-aware implementations of the scheme on constrained platforms, including embedded and mobile devices. Evaluating energy consumption per encrypted token will provide deeper insight into the suitability of the model for battery-powered environments. Finally, automated policy-driven key management and integration with zero-trust architectures constitute an important extension. Embedding the proposed cryptographic protocol into adaptive access-control systems could enable dynamic, context-aware security for distributed and cloud-based infrastructures.

Acknowledgement: We sincerely thank all the individuals and the institution whose support and contributions have made this work possible.

Funding Statement: The authors received no specific funding.

Author Contributions: Research work was conducted by Michael Juma Ayuma, reviewed, supervised and validated by Shem Mbandu Angolo and Philemon Nthenge Kasyoka. All authors reviewed and approved the final version of the manuscript.

Availability of Data and Materials: The data used in this study is publicly available on papers published in the relevant journals as recorded in this manuscript.

Ethics Approval: Not applicable.

Conflicts of Interest: The authors declare no conflicts of interest.

References

1. Truong VT, Le L, Niyato D. Blockchain meets metaverse and digital asset management: a comprehensive survey. IEEE Access. 2023;11(1):26258–88. doi:10.1109/access.2023.3257029. [Google Scholar] [CrossRef]

2. Shaukat K, Luo S, Varadharajan V, Hameed IA, Xu M. A survey on machine learning techniques for cyber security in the last decade. IEEE Access. 2020;8:222310–54. doi:10.1109/access.2020.3041951. [Google Scholar] [CrossRef]

3. Kuppuswamy P, Al Khalidi Al-Maliki SQY, John R, Haseebuddin M, Ali Shaik Meeran A. A hybrid encryption system for communication and financial transactions using RSA and a novel symmetric key algorithm. Bull Electr Eng Informatics. 2023;12(2):1148–58. doi:10.11591/eei.v12i2.4967. [Google Scholar] [CrossRef]

4. Ugwuishiwu CH, Orji UE. An overview of quantum cryptography and shor’s algorithm. Int J Adv Trends Comput Sci Eng. 2020;9:7487–95. doi:10.30534/ijatcse/2020/82952020. [Google Scholar] [CrossRef]

5. Noor NM, Razali NAM, Malizan NA, Ishak KK, Wook M, Hasbullah NA. Decentralized access control using blockchain technology for application in smart farming. Int J Adv Comput Sci Appl. 2022;13(9):788–802. doi:10.14569/ijacsa.2022.0130993. [Google Scholar] [CrossRef]

6. Nabil B, Herráiz JJM. A robust cloud security model leveraging a hybrid of cryptography and steganography. Authorea. 2024. doi:10.22541/au.171221467.72775845/v1. [Google Scholar] [CrossRef]

7. Muhammed RK, Rashid ZN, Saydah SJ. A hybrid approach to cloud data security using ChaCha20 and ECDH for secure encryption and key exchange. Kurd J Appl Res. 2025;10(1):66–82. doi:10.24017/science.2025.1.5. [Google Scholar] [CrossRef]

8. Jadhav SV, Pise N. Securing decentralized storage in blockchain: a hybrid cryptographic framework. Cybern Inf Technol. 2024;24(2):16–31. doi:10.2478/cait-2024-0013. [Google Scholar] [CrossRef]

9. Yadav AS, Pawar V, Yadav R. IoT-enabled blockchain framework for Internet of vehicles safety monitoring in smart cities. Trans Emerging Tel Tech. 2025;36(6):e70169. doi:10.1002/ett.70169. [Google Scholar] [CrossRef]

10. Kumari KA. Cryptographic algorithms and computational complexity: a mathematical approach to securing IT networks. J Inf Syst Eng Manag. 2025;10(25s):409–20. doi:10.52783/jisem.v10i25s.4037. [Google Scholar] [CrossRef]

11. Musa A, Udoaka Otobong G. Enhanced security in post-quantum cryptography: a comprehensive lattice-based signature scheme using matrix groups. Asian J Math Comp Res. 2024;31(4):33–9. doi:10.56557/ajomcor/2024/v31i48966. [Google Scholar] [CrossRef]

12. Almatarneh R, Aljaidi M, Lsarhan AA, Alsuwaylimi AA. QR-DEF: a quantum-resistant hybrid encryption framework with dynamic entropy fusion and biomimetic obfuscation. Int J Innov Res Sci Stud. 2025;8(4):156–66. doi:10.53894/ijirss.v8i3.7747. [Google Scholar] [CrossRef]

13. Zhao C, Zhang J, Cao J, Cheng Q, Wei F. Implicit factorization with shared any bits. IACR Commun Cryptol. 2024;1(3):1–19. doi:10.62056/anjbhey6b. [Google Scholar] [CrossRef]

14. Omollo R, Okoth A. Factorization algorithm for semi-primes and the cryptanalysis of rivest-Shamir-adleman (RSA) cryptography. Asian J Res Comput Sci. 2024;17(6):85–95. doi:10.9734/ajrcos/2024/v17i6458. [Google Scholar] [CrossRef]

15. Yadav CS. Innovations in cloud security: enhanced hybrid encryption approach with authprivacychain for enhanced scalability. Nanotechnol Percept. 2024;20(S2):560–77. doi:10.62441/nano-ntp.v20is2.42. [Google Scholar] [CrossRef]

16. Parab S. A review on cryptography using SHA algorithm. Int J Sci Res Eng Manag. 2025;9(6):1–9. doi:10.55041/ijsrem50103. [Google Scholar] [CrossRef]

17. Murphy S, Player R. The role of cryptography. In: Cryptography. Oxford, UK: Oxford University Press; 2025. p. 1–5. doi:10.1093/actrade/9780192882233.003.0001. [Google Scholar] [CrossRef]

18. Verma G, Liao M, Lu D, He W, Peng X, Sinha A. An optical asymmetric encryption scheme with biometric keys. Opt Lasers Eng. 2019;116:32–40. doi:10.1016/j.optlaseng.2018.12.010. [Google Scholar] [CrossRef]

19. Tan T, Zhang L, Liu S, Wang L. An encryption algorithm based on public-key cryptosystems for vector map. Secur Priv. 2025;8(1):e458. doi:10.1002/spy2.458. [Google Scholar] [CrossRef]

20. Huynh HT, Dang TP, Tran TK, Hoang TT, Pham CK. A multimode SHA-3 accelerator based on RISC-V system. IEICE Electr Exp. 2024;21(11):20240156. doi:10.1587/elex.21.20240156. [Google Scholar] [CrossRef]

21. Salih RK, Kashmar AH. Enhancing blockchain security by developing the SHA256 algorithm. Iraqi J Sci. 2024;2024:5678–93. doi:10.24996/ijs.2024.65.10.30. [Google Scholar] [CrossRef]

22. Muhammed RK, Aziz RR, Ahmad Hassan A, Aladdin AM, Saydah SJ, Rashid TA, et al. Comparative analysis of AES, blowfish, twofish, Salsa20, and ChaCha20 for image encryption. Kurd J Appl Res. 2024;9(1):52–65. doi:10.24017/science.2024.1.5. [Google Scholar] [CrossRef]

23. Nikhitha T, Sree BR, Mahesh GU, Babu MKS, Priyanka MP. Mail encryption using ChaCha20. Int J Multidiscip Res. 2024;6(6):33051. doi:10.36948/ijfmr.2024.v06i06.33051. [Google Scholar] [CrossRef]

24. Iqbal K, Jatoi MU, Sulaman M, Abid MS. Robust multi-party computation in critical infrastructure protection using hybrid RSA-AES algorithm for enhanced security. Research Square. 2024. doi:10.21203/rs.3.rs-3884946/v1. [Google Scholar] [CrossRef]

25. Yang Q, Zhang Q, Wang Y, Xin X, Gao R, Yao H, et al. Hybrid chaotic encryption algorithm with polar coding for probabilistic shaping orthogonal frequency division multiplexing passive optical network. Opt Eng. 2025;64(2):028101. doi:10.1117/1.oe.64.2.028101. [Google Scholar] [CrossRef]

26. Awulachew G, Asferaw S. Double key pair and hidden modulus RSA cryptosystem. Research Square. 2024. doi:10.21203/rs.3.rs-4655782/v1. [Google Scholar] [CrossRef]

27. Monica T, Hadiana AI, Melina M. Question bank security using rivest Shamir adleman algorithm and advanced encryption standard. J Inform Dan Komput. 2024;7(3):175–81. doi:10.33387/jiko.v7i3.8654. [Google Scholar] [CrossRef]

28. Hou B. Number theory based modern cryptography: RSA and Diffie-Hellman algorithms. Theor Nat Sci. 2024;51(1):107–13. doi:10.54254/2753-8818/51/2024ch0180. [Google Scholar] [CrossRef]

29. Neyigapula BS. Secure AI model sharing: a cryptographic approach for encrypted model exchange. Int J Artif Intell Mach Learn. 2024;4(1):48–60. doi:10.51483/ijaiml.4.1.2024.48-60. [Google Scholar] [CrossRef]

30. Ntayagabiri JP, Ndikumagenge J, Bentaleb Y, El Makhtoum H. Comparative analysis of elliptic curve-based cryptographic approaches for Internet of Things security. Int J Sci Res Comput Sci Eng Inf Technol. 2024;10(6):1077–92. doi:10.32628/cseit2410457. [Google Scholar] [CrossRef]

31. Yan X, Lian B, Yang Y, Wang X, Cui J, Zhao X, et al. A ciphertext reduction scheme for garbling an S-box in an AES circuit with minimal online time. Symmetry. 2024;16(6):664. doi:10.3390/sym16060664. [Google Scholar] [CrossRef]

32. Abd-Aljabbar AA, Hammood DA, Abed LH. Secure cloud storage using multi-modal biometric cryptosystem: a deep learning-based key binding approach. J Al-Qadisiyah Comput Sci Math. 2025;17(1):214–29. doi:10.29304/jqcsm.2025.17.11976. [Google Scholar] [CrossRef]

33. Yao M, Xue Z, Li H, Shen S. An optimized hardware implementation of SHA-256 round computation. Comput J. 2025;68(4):355–9. doi:10.1093/comjnl/bxae116. [Google Scholar] [CrossRef]

34. Bhavsar R. Enhancing data security in banking: the power of hybrid algorithm-based solutions. JES. 2024;20(10s):1093–102. doi:10.52783/jes.5208. [Google Scholar] [CrossRef]

35. Haripriya K, Brintha NC. Privacy-preserving medical cloud architecture using hybrid key encryption and blockchain-based verification. Research Square. 2025. doi:10.21203/rs.3.rs-6474168/v1. [Google Scholar] [CrossRef]