A Secured Parallel Multi-Broker MQTT Framework with Chaos-Enhanced Hybrid Encryption for Repetition-Resistant IoT Security

Abstract

The proliferation of IoT deployments has exposed critical vulnerabilities in MQTT-based systems, particularly ciphertext-repetition leakage in telemetry encryption, where identical plaintext blocks under a fixed key—common for static sensor readings—collapse ciphertext entropy and expose traffic patterns. We present a parallel multibroker MQTT framework with two encryption variants: a hybrid AES-ChaCha20 cipher (NeoCipher) and an 8D chaotic system-enhanced variant (Chaos-NeoCipher). While AES-128 and base NeoCipher exhibit leakage (entropy falling to 3.9–4.0 bits/byte), Chaos-NeoCipher mitigates it entirely (7.996 bits/byte) through chaotic key schedule advancement on each invocation. Across 100+ nodes, 10 brokers, and five attack scenarios, consensus-based detection achieves near-ceiling performance governed by protocol logic rather than cipher choice. Chaotic tuning via Lyapunov sweep ($\mathrm{\lambda }$ ≈ 0.54 bits/iteration) and batched key-schedule optimization reduce overhead from +39.9 to +17.6%. Our results satisfy key IoT requirements: sub-millisecond cryptographic processing latency (measured as encryption/decryption time only, not including network transmission, broker queuing, or TCP overhead), near-complete detection across five attack classes under controlled simulation conditions, and mitigated single-point-of-failure vulnerability.

1. Introduction

The Internet of Things has shown exponential growth, and resource-constrained devices, such as wearable devices and smart sensors, are increasingly part of several applications. They range from smart cities and healthcare to industrial automation and environmental monitoring [1]. Nevertheless, these devices are by nature resource-constrained in terms of computational power, memory size, and battery life, which makes them particularly challenging to secure sensitive data and enforce privacy protection. With the increased proliferation of connected devices, addressing the security concerns in IoT devices is further complicated (especially in the resource-constrained setting of IoT devices). Connectivity in the IoT ecosystem relies heavily on efficient communication mechanisms through lightweight protocols specifically designed for resource-constrained devices. One protocol that has become a de facto standard is Message Queuing Telemetry Transport (MQTT), which uses a publish–subscribe model to ensure reliable message delivery with low overhead and minimal power consumption [2]. Message Queuing Telemetry Transport (MQTT) has emerged as a preferred choice due to its lightweight nature and efficiency in handling the resource constraints typically associated with Internet of Things devices. MQTT operates on a publish–subscribe model over TCP [2,3], enabling highly scalable, asynchronous communication for diverse IoT applications. However, its growing adoption has made it a target for cyber threats aimed at disrupting service availability and compromising data integrity and confidentiality [4,5]. Traditional security approaches typically integrate external protocols such as TLS or SSL [6,7], but these are often infeasible for resource-constrained IoT devices [7]. Researchers highlight that MQTT lacks a strong security scheme by default, particularly in terms of authentication and data confidentiality/integrity. TLS is commonly recommended as a security layer [7], but its feasibility depends on device capabilities, implementation efficiency, cipher suite selection (e.g., ECC-based ciphers being lighter than RSA-based ones), and the use of features like session resumption and TLS 1.3’s reduced handshake overhead [8,9]. In resource-constrained deployments—particularly those using older hardware or lacking cryptographic acceleration—TLS can impose significant overhead, motivating the exploration of alternative lightweight cryptographic approaches. MQTT security challenges include emerging vulnerabilities and attacks, with a need for classification and defense mechanisms to ensure secure IoT deployment [5]. The MQTT protocol also operates on a publish–subscribe model centered around a single broker. While lightweight and efficient, this architecture presents fundamental security challenges, including a single point of failure; broker compromise affects all connected devices [8].

1.1. Research Motivation and Identified Research Gaps

A critical weakness of MQTT is its lack of an effective native security scheme, particularly in terms of authentication, data confidentiality, and integrity. While the integration of external protocols such as Transport Layer Security (TLS) or Secure Sockets Layer (SSL) is often recommended [10], these solutions are frequently infeasible for lightweight IoT devices due to their resource demands [11]. Furthermore, the typical MQTT architecture is centralized around a single broker, introducing a fundamental single point of failure; compromise of the broker affects all connected devices [12]. This architectural vulnerability, combined with the protocol’s default security gaps, necessitates novel approaches that balance strong protection with the stringent resource limitations of IoT [13].

Beyond these two well-documented gaps, we identify a third gap specific to IoT telemetry workloads that has received little attention in the MQTT security literature: ciphertext-repetition leakage. When a block cipher is used in deterministic modes such as ECB, or in CTR/GCM modes with a fixed nonce—a scenario that arises in practice when resource-constrained IoT devices reuse nonces due to synchronization overhead, limited randomness, or implementation simplicity—identical plaintext blocks produce identical ciphertext blocks. An IoT sensor reporting an unchanged reading emits an identical plaintext block, and therefore an identical ciphertext block under these conditions. A passive network observer consequently learns when a reading has not changed, and can infer activity patterns, occupancy, and operational schedules, without ever breaking the cipher. This is not a theoretical concern for IoT: telemetry is dominated by repeated and slowly varying values, and nonce mismanagement remains prevalent in constrained deployments. We emphasize that this leakage is a property of the encryption mode and nonce handling, not of the underlying block cipher primitive. The lightweight-cryptography proposals surveyed in Section 2, refs. [13,14,15,16,17] do not address this leakage channel, and, as we show experimentally in Section 4.1, both standard AES-128 and a non-chaotic hybrid construction exhibit it severely when operating under fixed nonces.

1.2. Key Contributions

To address the challenges identified above, this paper presents a comprehensive security framework with the following contributions:

• Identification and mitigation of ciphertext-repetition leakage in MQTT telemetry: We demonstrate experimentally that both AES-128 and a non-chaotic hybrid cipher leak repetition, with ciphertext entropy collapsing to $3.9$–$4.0$ bits/byte under repeated identical plaintext, and that the proposed chaotic key schedule mitigates this leakage entirely ($7.996$ bits/byte). This is the framework’s primary, empirically verified cryptographic contribution.
• Parallel Multi-Broker Architecture A distributed broker pool featuring automatic failover, load balancing, and consensus-based attack detection to eliminate single points of failure.
• Coordinated Five-Mechanism Detection Layer: Simultaneous nonce-based replay detection, authentication-tag verification (spoofing and corruption), sliding-window rate limiting (DoS flood), and broker-path verification (MITM), aggregated across all brokers via a consensus mechanism, compared with at most one mechanism, and in most surveyed cases none, in prior work (Table 1).
• NeoCipher Hybrid Encryption: The design and implementation of a hybrid cipher, NeoCipher, which combines AES-based substitution with ChaCha20 ARX operations, replacing the Galois-field MixColumns transformation with a ChaCha20-derived diffusion layer (NeoMix).
• Tuned and optimized Chaos-NeoCipher variant: A Lyapunov-exponent sweep over the 8D system’s coupling parameter revealed that unspecified or low coupling values place the system in weak or even non-chaotic regimes; tuning to $\epsilon =0.6$ raised confirmed chaotic strength approximately twentyfold. A subsequent batched key-schedule implementation reduced the chaotic variant’s processing overhead from $+39.9\%$ to $+17.6\%$ while producing bit-identical ciphertext.
• Reproducible evaluation: A rigorous assessment across five distinct attack scenarios with statistical validation (confidence intervals, multiple independent repetitions), alongside performance analysis. The complete cipher implementation, simulation code, and raw results are available from the corresponding author upon reasonable request.

Table 1. Attack-detection scope in related MQTT security and broker-architecture work. Works are grouped by whether they perform active attack detection. “—” indicates the work does not target a specific security focus.

Work	Security Focus	#	Attack Detection Capability
Works with active attack detection
Iyer et al. [14]	SPECK/SIMON under MITM	1	MITM modelled in evaluation only; no active detection
Sochor et al. [11]	DRDoS/reflection mitigation	1	Mitigation via handshake redesign; no detection
This work	Replay, spoofing, corruption, DoS flood, MITM	5	Active detection via nonce tracking, AEAD tag verification, SHA-256 identity check, rate limiting, broker path verification, and consensus coordination
Works without active attack detection
Pelz [12]	Node-failure robustness	0	None
Kao et al. [13]	Authentication and key exchange	0	None
Alharbi et al. [15]	Encryption layers	0	None
Imdad et al. [18]	Key schedule strengthening	0	None
Zhu et al. [19]	Trusted device authentication	0	None
Lin et al. [20]	Password authentication	0	None; explicitly excludes other attacks
Banno et al. [21]	Throughput/parallelism	0	None
Longo et al. [22]	Topology and failure recovery	0	None
Kurdi & Thayananthan [23]	Authentication (deprecated SHA-1)	0	None
Detti et al. [24]	—	0	None; states “authentication and attack detection are absent”
Kim & Lee [25]	—	0	None; states no security, authentication, or detection
Amoretti et al. [26]	Token-based authorization	0	None
Amanlou et al. [27]	Client–gateway authentication	0	None
Spohn [28]	—	0	None; states “no security considerations”
Alharbi et al. [29]	—	0	None; does not address active attack detection
Summary: 1/17 related works perform active attack detection; this work covers 5 attack classes.

The remainder of this paper is organized as follows. Section 2 provides a comprehensive review of related work, covering lightweight cryptography in MQTT, parallel and distributed broker architectures, and an attack-detection scope comparison identifying the research gaps that motivate this work. Section 3 presents the proposed system architecture, including the parallel multi-broker framework and its core components. Section 4 outlines the experimental setup and results, including testbed configuration, cryptographic security analysis, chaotic-system tuning, key-schedule optimization, attack scenarios, and detection performance. Section 5 concludes the paper and discusses future research directions.

2. Background and Related Work

Security remains the foremost challenge in deploying Internet of Things (IoT) applications. As one of the most popular messaging protocols in the IoT world, Message Queue Telemetry Transport (MQTT) is designed for constrained devices and machine-to-machine communications. For application-layer communication in IoT, MQTT is the dominant choice, operating over TCP to ensure reliable data transmission [9]. Based on the publish–subscribe model, it offers basic authentication using username and password. However, this authentication method presents significant security and scalability limitations [30].

This section reviews existing literature across two main dimensions: (1) security and encryption mechanisms for MQTT, and (2) parallel and distributed MQTT broker architectures. The review concludes by identifying research gaps that motivate this work, summarized in an explicit attack-detection scope comparison (Section 2.3).

2.1. Lightweight Cryptography in MQTT

Iyer et al. [14] evaluated MQTT using SPECK [31] and SIMON [10] under man-in-the-middle (MITM) attacks. They employed the lightweight hash function SPONGENT to support resource-constrained IoT devices. SPECK provides better security while consuming minimal battery and memory resources. However, the primary limitation of SIMON and SPECK is the exclusion of the S-box concept in the encryption process, which necessitates enhancing the confusion property during ciphertext generation, especially for the Internet of Medical Things (IoMT) environment. SIMON and SPECK are Feistel-structure ciphers designed without a traditional substitution-box (S-box) layer. This means they lack an explicit non-linear substitution mechanism in their encryption process, which is a foundational element in most secure block ciphers. The primary limitation of excluding a substitution box (S-box) in SIMON and SPECK is that it requires a much higher number of rounds to achieve full security and confusion compared to S-box-based ciphers like AES.

Sochor et al. [11] explained reflection attacks exploiting the MQTT-SN protocol, leading to Distributed Reflective Denial-of-Service (DRDoS) attacks. Only 0.02% of the victim’s bandwidth is required to saturate the target system fully. To address this, the authors suggested incorporating an additional handshake and restricting Quality of Service (QoS) for levels 0 and 1. A four-way handshake (PUBLISH, PUBREC, PUBREL, PUBCOMP) ensures QoS level 2, guaranteeing each message is received once. However, the authors note that a three-way handshake would be a better choice for client–broker communication.

Pelz [12] introduced Quality of Effectiveness (QoR)—the number of nodes allowed to fail without data loss. Testing from zero to full node failure, the author found that management node (broker) failure represents the worst case for QoR, suggesting that IoT system designers should always ensure broker redundancy.

Kao et al. [13] proposed a connection authentication technique based on MQTT-SN, AEAD (ChaCha20-Poly1305), hash functions, digital signature (ECDSA), and key exchange (ECDHE) to create Safe MQTT-SN. They replaced RSA with ChaCha20-Poly1305, which authenticates published messages and has lower power consumption than AES-GCM. Although AES requires less communication time, its high memory consumption poses challenges for resource-limited IoMT devices.

Alharbi et al. [15] designed a secure, dual-layer MQTT communication architecture tailored for healthcare IoT systems. The proposed framework integrates Salsa20-Blake2b encryption at the edge with AES-256 over TLS 1.3 for secure transmission to the cloud; however, the researchers use pre-shared symmetric keys at the edge (Salsa20-Blake2b), which presents significant management and scalability challenges in large-scale deployments with hundreds or thousands of devices. Security Risk: Static keys are more vulnerable to long-term compromise; if a key is leaked, all devices using that key are exposed.

Munshi [18] employed transmission flags to authenticate data exchange across networks, gathering and examining data from numerous devices. Although the payload length is short, this method effectively assesses data transfer security, necessitating encryption for tracking purposes.

Husnain et al. [32] identified 81 MQTT vulnerabilities using the National Vulnerability Database (NVD) and Common Vulnerabilities and Exposures (CVE). Vulnerabilities arise from three primary issues: inadequate packet length, absent essential fields, and deficiency in logical error checks. The authors outline a comprehensive five-step approach: protocol intuition, vulnerability assessment, protocol identification, protocol parsing, and stringent protocol validation.

Imdad et al. [16] introduced the Key Schedule Algorithm PRESENT (KSA-PRESENT) scheme, enhancing the randomness and unpredictability of round keys by combining PRESENT-128 with a complex non-linear function.

Despite encryption options, MQTT remains vulnerable as developers prioritize lightweight solutions and bandwidth usage over security. Physical attacks can disable IoT devices (mobile phones, routers, cameras, sensors), while cyber-attacks compromise wireless networks [3,33].

Sabri et al. [17] demonstrated that ChaCha20 is well-suited for real-time medical IoT applications, but battery-powered healthcare devices face energy efficiency and key management challenges.

Zhu et al. [19] designed an MQTT trusted device authentication scheme based on TrustZone technology, using hybrid national encryption algorithms. However, this solution only improves transmission and storage security for IoT embedded scenarios.

Lin et al. [20] introduced ChaCha20-Poly1305 password authentication for MQTT-SN, using CSP to formally model the communication system. Results show security, but the solution lacks consideration for other attacks.

Liu et al. [34] proposed an MQTT security scheme based on SM2, SM3, and SM4 algorithms, addressing the lack of identity authentication and plaintext transmission. However, the scheme requires many communication rounds during authentication.

Notably, none of the above works evaluates cipher behavior under repeated identical plaintext, despite the prevalence of such traffic in IoT telemetry—the gap addressed in Section 4.1 of this work.

2.2. Parallel and Distributed MQTT Brokers

The evolution of MQTT from a centralized broker model to distributed architectures has been extensively studied, yet the specific area of parallel MQTT broker designs remains underexplored.

Banno et al. [21] proposed an interworking layer enabling heterogeneous MQTT brokers to cooperate in parallel. Their generic API layer sits between clients and brokers, allowing algorithm-independent parallel cooperation. In a testbed with five brokers, they achieved 4.3× throughput improvement over a single instance, specifically designed for edge-heavy data with high locality. Nevertheless, the approach requires custom algorithm development per deployment, lacks built-in cooperation mechanisms, and provides no automatic failure recovery.

Longo et al. [22] introduced MQTT-ST, a spanning tree protocol for distributed MQTT brokers. This approach enables automatic loop-free topology formation with built-in failure recovery. However, full message replication remains a limitation, and session sharing is not supported.

Kurdi and Thayanathan [23] proposed Mu-TiMB (Multi-Tier MQTT Broker based on Fog Computing), a hierarchical three-layer architecture consisting of IoT devices, fog-layer brokers (local and aggregation brokers), and a cloud broker. The authors introduced a lightweight mutual authentication scheme based exclusively on hash functions (SHA-1) and XOR operations, with each broker hosting an independent Authentication Manager (AM); however, the use of deprecated SHA-1 – SHA-1 has been cryptographically broken since 2017 [35].

Detti et al. [24] analyzed the scalability of MQTT clusters and identified a critical finding: naive horizontal scaling introduces a 40% performance penalty due to inter-broker traffic overhead. The authors proposed a greedy load-balancing strategy that reduced this penalty to 10%. However, authentication and attack detection are absent.

Kim and Lee [25] conducted a comparative performance study of parallel MQTT and RS485 communication architectures for high-frequency IoT sensing, achieving 98 ms latency and a 99.2% success rate with topic-level parallelism. However, the study included no security, authentication, or attack detection and no parallel broker architecture, focusing instead on topic-level parallelism within a single broker.

Amoretti et al. [26] introduced a scalable and secure publish–subscribe framework for Industrial IoT using token-based authorization (OAuth2-like) with RSA signatures and TLS. However, heavyweight cryptography, RSA-2048, and TLS are not lightweight; a central authentication server creates a bottleneck and a single point of failure.

Amanlou et al. [27] proposed a lightweight authentication scheme for fog-based MQTT using Elliptic Curve Diffie–Hellman Ephemeral (ECDHE) with Pre-Shared Keys (PSK), offering Perfect Forward Secrecy (PFS). However, only client–gateway authentication is supported. The computational cost is high, as ECDHE operations are expensive for resource-constrained devices.

Spohn [28] introduced an endogenous, self-organizing approach for federating autonomous MQTT brokers using “federator” agents. The approach does not require broker code modifications, as federator agents manage inter-broker communication. However, no security considerations are addressed.

Alharbi et al. [29] proposed HECS4MQTT, a multi-layer security framework for healthcare IoT that combines lightweight edge encryption (Salsa20-Blake2b) with effective cloud encryption (AES-256 over TLS 1.3) using a multi-broker MQTT architecture (local brokers in hospitals plus cloud brokers). A custom bridge application handles the cryptographic transition between layers. The Python-based implementation demonstrated lower CPU cycles and faster encryption times compared to AES and other lightweight ciphers. However, the framework is healthcare-specific, does not address active attack detection, and is limited to two brokers. The literature review reveals that while significant progress has been made in parallel MQTT broker architectures, no existing work provides an integrated solution combining horizontal scalability, lightweight authentication, real-time multi-class attack detection, active defense mechanisms, and repetition-resistant chaotic cryptography. The proposed NeoCipher-based parallel broker system is designed to address these gaps.

2.3. Attack-Detection Scope Comparison

The classification in Table 1 is based solely on whether each work implements active attack detection. This is not a judgment of the overall quality or security of these works. Many of the surveyed papers make valuable contributions in authentication, encryption, key management, and other security areas. The comparison is limited to the specific dimension of active attack detection to highlight a gap that this work addresses.

Table 1 summarizes the attack-detection scope explicitly reported for each closely related work reviewed in Section 2.1 and Section 2.2. This comparison is deliberately based on detection scope rather than reported detection percentages, since detection rates across heterogeneous testbeds, threat models, and traffic profiles are not directly comparable.

Coordinated detection of five concurrent attack classes—versus at most one, and most commonly zero, in prior MQTT broker and security proposals—constitutes the framework’s primary literature-grounded differentiator.

Combined with the repetition-leakage resistance established in Section 4.1 and the fault-tolerance properties of Section 3.2.7, this defines a coverage profile not matched by any single work in the surveyed literature.

3. The Proposed Multi-Broker MQTT Framework

Figure 1 presents the complete system architecture. The framework consists of two main pillars:

Figure 1. High-level system architecture.

A. 

Layer Cryptographic Engine (Contribution #1)

• NeoCipher for the integrity of the ciphertext.
• The 8D Chaotic System: Coupled logistic maps for key perturbation and entropy enhancement.
• SHA-256 for node identity verification (spoofing detection).

B. 

A Novel Parallel Multi-Broker MQTT Management (Contribution #2)

• Consensus-based global attack detection ($\tau =2$, $W=3$ s).
• Smart load balancer.
• Broker path verification for MITM detection.
• Per-node rate limiting.
• Coordinated attack defense for parallel brokers system.
• Fault tolerance mechanisms.

3.1. Layer Cryptographic Engine

NeoCipher are Hybrid AES (Advanced Encryption Standard) and ChaCha20, a modern, fast stream cipher with an 8-dimensional chaotic system, used as a security layer in IoT MQTT encryption. The NeoMix algorithm is the core diffusion layer of the NeoCipher block cipher it replacing AES mixing columns with ChaCha20 ARX operations. This paper presents the complete specification of NeoMix, including its algorithmic description and implementation details. NeoMix operates on 128-bit states represented as a 4 × 4 matrix of 32-bit words, applying eight quarter rounds organized as two double rounds, followed by XOR accumulation and final mixing. The algorithm achieves full diffusion within two rounds and provides resistance against differential and linear cryptanalysis in the sense of reaching complete state dependency; formal differential and linear characteristic bounds are identified as future work (Section 5). The NeoCipher combines the security strengths of AES and ChaCha20, further enhanced by an eight-dimensional chaotic system, as shown in Figure 2.

Figure 2. NeoCipher encryption architecture with chaotic key schedule (12-round configuration shown as an example; the configurable structure supports 8, 10, or 12 rounds).

3.1.1. NeoCipher

The key idea: NeoCipher uses the structure of AES but replaces one specific part (MixColumns) with operations borrowed from ChaCha20, as described in Algorithm 1. It operates on 128-bit blocks with configurable key sizes.

The experimental configuration evaluates the security and performance of the proposed NeoCipher (AES + ChaCha20 + 8D Chaotic System) in a multi-broker MQTT environment. Table 2 presents the complete experimental configuration.

Table 2. Experimental configuration parameters for a single simulation run (8 rounds, 10 brokers). Aggregated results across 30 seeds × 40 rounds.

Parameter	Value
Number of Brokers	10
Encryption Rounds	8
Block Size	16 bytes (128 bits)
Key Size	256 bits (32 bytes)
Nonce Size	12 bytes (96 bits)
Total Number of Nodes	100
Number of Attacker Nodes	5
Parallel Workers per Broker	10
Message Queue Size per Broker	5000
Attack Intensity	20–25%
Simulation Rounds	10
Total Packets per Scenario	≈2500

NeoCipher integrates three cryptographic paradigms:

• AES and ChaCha20: AES Substitution–Permutation Network (SPN) with SubBytes to provide non-linearity (AES-inspired), and ShiftRows operations provide diffusion across bytes; the ChaCha20 Core uses quarter-round and double-round functions for diffusion and provides fast bit diffusion.
• 8D Chaotic System: Coupled map lattice for key perturbation and entropy enhancement.
• SHA-256 for autication.

Algorithm 1 NeoCipher Encryption (R Rounds, Key Size K)
Require: 16-byte plaintext P, key K (16, 24, or 32 bytes)
Ensure: 16-byte ciphertext C
1:	$R\leftarrow \mathrm{GetRoundsFromKeySize}\left(\mathrm{len}\right(K\left)\right)$	▹ $R=8$ for 128-bit, 10 for 192-bit, 12 for 256-bit
2:	$\mathrm{round}\text{\_}\mathrm{keys}\leftarrow \mathrm{KeySchedule}(K,R)$	▹ Generates $R+1$ round keys (indices 0..$R$)
3:	$\mathrm{state}\leftarrow P$
4:	$\mathrm{state}\leftarrow \mathrm{AddRoundKey}(\mathrm{state},\mathrm{round}\text{\_}\mathrm{keys}[0\left]\right)$
5:	for $r\leftarrow 1$ to $R-1$ do	▹ $R-1$ rounds with NeoMix
6:	$\mathrm{state}\leftarrow \mathrm{SubBytes}\left(\mathrm{state}\right)$
7:	$\mathrm{state}\leftarrow \mathrm{ShiftRows}\left(\mathrm{state}\right)$
8:	$\mathrm{state}\leftarrow \mathrm{NeoMix}(\mathrm{state},\mathrm{round}\text{\_}\mathrm{keys}[r\left]\right)$
9:	end for
10:	$\mathrm{state}\leftarrow \mathrm{SubBytes}\left(\mathrm{state}\right)$	▹ Final round (no NeoMix)
11:	$\mathrm{state}\leftarrow \mathrm{ShiftRows}\left(\mathrm{state}\right)$
12:	$\mathrm{state}\leftarrow \mathrm{AddRoundKey}(\mathrm{state},\mathrm{round}\text{\_}\mathrm{keys}[R\left]\right)$return state

The proposed NeoCipher supports configurable rounds (8, 10, or 12), as shown in Table 3. The architectural illustration in Figure 2 depicts the 12-round configuration as a general example. However, the eight-round configuration is the one evaluated in this study (Algorithm 1 and Table 2), chosen as a balanced trade-off between security and performance for resource-constrained IoT environments.

Table 3. Configurable cryptographic parameters. The 8-round configuration is used in the experimental evaluation.

Category	Parameter	Value
Cipher	Type	Hybrid Block Cipher (SPN + ARX)
	Mode	Authenticated CTR
Sizes	Block Size	128 bits (16 bytes)
	Key Sizes	128, 192, 256 bits
	Nonce Size	96 bits (12 bytes)
Rounds	Rounds	8, 10, 12
	Tag Size	128 bits (16 bytes)

NeoMix

The operation MixColumns in the AES algorithm uses Galois Field (GF) multiplication. This is a complex mathematical multiplication that takes more CPU time and consumes more battery power; therefore, we replace this operation, MixColumns, with the ChaCha20 quarter-round ARX operation. The ChaCha20 quarter round is famously aggressive. ChaCha20 double rounds are used. After replacing MixColumns in AES, we can see the encryption and decryption process in Figure 3. Algorithm 2 achieves full diffusion within two rounds; this means that the ChaCha20 ARX operations mix the data much faster than standard AES MixColumns, allowing fewer total rounds to be used (eight rounds are used) while still maintaining strong security, as shown in Figure 4. Section 4.7 confirms this design rationale empirically: both NeoCipher variants measured substantially faster per block than the AES-128 reference implementation.

Figure 3. NeoMix dataflow: encryption and decryption.

Figure 4. NeoMix dataflow: complete processing pipeline.

The NeoMix algorithm achieves full diffusion within two rounds by leveraging the aggressive bit-mixing properties of the ChaCha20 quarter-round function. This function combines addition, rotation, and XOR (ARX) operations, which mix data significantly faster than the Galois-field multiplication used in AES MixColumns. The algorithm applies eight quarter rounds organized as two double rounds (a column round followed by a diagonal round), ensuring that after just two rounds, every output bit depends on every input bit and every key bit, achieving complete state dependency.

The resistance against differential and linear cryptanalysis is based on this same complete state dependency. Once full diffusion is achieved, differential characteristics cannot be traced through the cipher because differences are spread to all output bits. Similarly, linear approximations have poor correlations because every output bit depends on every input bit in a non-linear manner. The hybrid SPN + ARX design combines AES’s proven non-linearity (SubBytes) with ChaCha20’s fast bit diffusion, providing defense-in-depth against distinguishing attacks.

Empirical validation supports these claims. The avalanche effect is near the ideal $50\%$ ($50.01$–$50.17\%$ with 95% CI ± 0.51), confirming complete state dependency. NIST statistical tests demonstrate that the ciphertext is indistinguishable from random, with all tests passing at $\alpha =0.01$. However, as noted in the paper, formal differential and linear characteristic bounds are identified as future work. The current resistance claims are therefore justified by the design rationale (combining proven cryptographic primitives) and empirical validation, rather than by rigorous mathematical proofs.

Algorithm 1 presents the NeoCipher encryption pseudo-code. The detailed step-by-step implementation procedure consists of 11 phases:

1.

Phase 1—Input Preparation (Algorithm 1.1): Converts the 16-byte plaintext into a $4\times 4$ state matrix.

2.

Phase 2—Key Schedule Generation (Algorithm 1.2): Generates nine round keys using an 8D chaotic system with two-layer injection (chaos BEFORE and AFTER ChaCha20), as described in Algorithm 3 of the paper.

3.

Phase 3—AddRoundKey (Algorithm 1.3): XORs the state with the round key, identical to AES’s AddRoundKey operation.

4.

Phase 4—SubBytes (Algorithm 1.4): Applies the AES S-box to each byte, providing non-linearity (confusion).

5.

Phase 5—ShiftRows (Algorithm 1.5): Cyclically shifts each row (row 0:0, row 1:1, row 2:2, row 3:3), providing byte-level diffusion.

6.

Phase 6—NeoMix (Algorithm 1.6): The core diffusion layer that replaces AES MixColumns with ChaCha20 ARX operations. It XORs the round key, creates a ChaCha20 state, applies two double rounds (eight quarter rounds), folds 16 words to 4 words, and applies final mixing.

7.

Phase 7—QuarterRound (Algorithm 1.7): The ChaCha20 quarter-round function with four ARX operations.

8.

Phase 8—Main Loop (Algorithm 1.8): Executes SubBytes → ShiftRows → NeoMix for rounds 1–7, then final SubBytes → ShiftRows → AddRoundKey for round 8.

9.

Phase 9—ChaCha20Block (Algorithm 1.9): Generates the ChaCha20 keystream block used in the key schedule.

10.

Phase 10—8D Chaotic System (Algorithm 1.10): Generates chaotic values using coupled logistic maps with $ϵ=0.6$, achieving $\lambda \approx 0.542$ bits/iteration.

11.

Phase 11—Lyapunov-Exponent Sweep (Algorithm 1.11): The parameter tuning procedure that identified $ϵ=0.6$ as the optimal value for strong chaos.

The complete implementation was validated through extensive testing, with results showing a near-ideal avalanche effect ($50.17\%$ with 95% CI ± 0.51) and successful NIST statistical test passes, confirming the correctness of the implementation.

Algorithm 2 NeoMix transformation—invertible diffusion layer using ChaCha20 ARX operations
Require: $state\left[16\right]$ (16 bytes), $round\text{\_}key\left[16\right]$ (16 bytes)
Ensure: $mixed\text{\_}state\left[16\right]$ (16 bytes)
	Step 1: Unpack bytes to 32-bit words
1:	$words\leftarrow unpack\text{\_}32\left(state\right)$	▹ 4 words, little-endian
2:	$key\text{\_}words\leftarrow unpack\text{\_}32\left(round\text{\_}key\right)$
	Step 2: XOR state with round key
3:	for $i\leftarrow 0$ to 3 do
4:	$words\left[i\right]\leftarrow words\left[i\right]\oplus key\text{\_}words\left[i\right]$
5:	end for
	Step 3: Expand 4 words into ChaCha20 state
6:	$chacha\leftarrow \left[\right]$
7:	for $i\leftarrow 0$ to 15 do
8:	$chacha\left[i\right]\leftarrow words\left[i\mathrm{mod}4\right]$
9:	end for
	Step 4: Apply 2 ChaCha20 double rounds
10:	for $r\leftarrow 1$ to 2 do
11:	$DoubleRound\left(chacha\right)$
12:	end for
	Step 5: Fold 16 words back to 4 words
13:	$c\leftarrow [0,0,0,0]$
14:	for $i\leftarrow 0$ to 3 do
15:	for $j\leftarrow 0$ to 3 do
16:	$c\left[i\right]\leftarrow c\left[i\right]\oplus chacha[i+4\times j]$
17:	end for
18:	end for
	Step 6: Final mixing (computed into a new array)
19:	$d\leftarrow [0,0,0,0]$
20:	$d\left[0\right]\leftarrow ((c\left[0\right]\oplus c\left[1\right])+c\left[2\right])\mathrm{mod}{2}^{32}$
21:	$d\left[1\right]\leftarrow ((c\left[1\right]\oplus c\left[2\right])+c\left[3\right])\mathrm{mod}{2}^{32}$
22:	$d\left[2\right]\leftarrow ((c\left[2\right]\oplus c\left[3\right])+c\left[0\right])\mathrm{mod}{2}^{32}$
23:	$d\left[3\right]\leftarrow ((c\left[3\right]\oplus c\left[0\right])+c\left[1\right])\mathrm{mod}{2}^{32}$
24:	return $pack\text{\_}32\left(d\right)$

The NeoMix transformation is invertible. Given the round key $K_r$ and the ChaCha20 keystream $KS$, decryption reverses the process:

$$S^{\left(1\right)}=C\oplus K_r,S^{\left(2\right)}=S^{\left(1\right)}\oplus KS,S_{out}={\mathrm{ChaCha}20}^{-1}\left(S^{\left(2\right)}\right)$$

The XOR-folding operation is invertible because the ChaCha20 permutation is bijective. Replicating 4 words to 16 words and XOR-folding back ensures complete state dependency after two double rounds while maintaining invertibility.

3.1.2. Eight-Dimensional Chaotic System

This is a novel application of an 8D hyperchaotic system specifically designed for real-time key perturbation in an MQTT broker environment, providing a significant improvement in key randomization compared to static schedules. The 8D chaotic system generates eight random numbers per round; these are XORed into the key schedule BEFORE the ChaCha20 block runs to change its input, and AGAIN AFTER it runs to add extra randomness to the round key, ensuring each round key is unpredictable and the original key cannot be recovered even if one round key is compromised. We performed a systematic Lyapunov-exponent sweep across the 8D system’s coupling parameter $ϵ$. We found that low values ($ϵ=0.15$) produced negative exponents (non-chaotic), moderate values ($ϵ=0.25$) produced only marginal chaos ($\lambda \approx 0.027$), and only tuning to $ϵ=0.6$ achieved strong chaos ($\lambda \approx 0.542$). This is approximately a $20\times$ improvement and was verified across eight independent keys. This highlights why empirical tuning is essential; you cannot assume a chaotic system will behave chaotically without verification. High-dimensional systems cannot be assumed chaotic based on complexity alone. Empirical tuning via Lyapunov-exponent analysis is essential for cryptographic applications. Our sweep demonstrates that parameter selection can be the difference between strong chaos and no chaos at all. The 8D chaotic system in NeoCipher is used exclusively in the key schedule through a two-layer injection mechanism:

The key expansion (Algorithm 3) with chaos injection using the 8D chaotic system in NeoCipher is used exclusively in the key schedule through a two-layer injection mechanism. The chaotic generator injects eight chaotic values per round (Layer 1) and four values per round (Layer 2) into the key schedule. Under our experimental configuration ($ϵ=0.6$), the measured Shannon entropy of the resulting round keys exceeds 253 bits, indicating high variability. However, this entropy measurement does not constitute a proof of cryptographic strength; it is a preliminary statistical indicator.

The key schedule is non-invertible in the sense that the chaotic state cannot be recovered from the round keys alone, as the state evolves deterministically from the master key and nonce. This property provides defense-in-depth against key recovery if a round key is compromised, as it introduces fresh randomness in each round, as shown in Figure 5.

Figure 5. Chaos-enhanced key schedule flow.

1.

Layer 1: XOR all eight chaotic values into key words BEFORE ChaCha20.

2.

Layer 2: XOR four chaotic values into the round key AFTER ChaCha20.

Critically for the vulnerability identified in Section 1.1, the chaotic generator advances its internal state on every invocation. Two encryptions of the same plaintext under the same master key therefore consume different chaotic vectors and produce different ciphertexts—the mechanism underlying the repetition-leakage resistance measured in Section 4.1.

Algorithm 3 Two-Layer Chaos Injection in Key Schedule
Require: $key\left[32\right]$
Ensure: $round\text{\_}keys[0..R]$
	STEP 1: Initialize chaotic system
1:	$chaos\leftarrow ChaoticSystem8D\left(key\right)$	▹ $\epsilon =0.6$, $r=4$, 200-step burn-in
2:	$key\text{\_}words\leftarrow PadAndParse\left(key\right)$	▹ 8 × 32-bit words
3:	for $round\leftarrow 0$ to R do
	STEP 2: Get 8 chaotic values
4:	$cv[0..7]\leftarrow chaos.nextVector\left(\right)$
	STEP 3: LAYER 1 – Chaos BEFORE ChaCha20
5:	for $i\leftarrow 0$ to 7 do
6:	$key\text{\_}words\left[i\right]\leftarrow key\text{\_}words\left[i\right]\oplus cv\left[i\right]$
7:	end for
	STEP 4: Run ChaCha20 block function
8:	$block[0..15]\leftarrow ChaCha20Block(key\text{\_}words,round)$
	STEP 5: Fold 16 words to 4 words
9:	$rk\left[0\right]\leftarrow block\left[0\right]\oplus block\left[4\right]\oplus block\left[8\right]\oplus block\left[12\right]$
10:	$rk\left[1\right]\leftarrow block\left[1\right]\oplus block\left[5\right]\oplus block\left[9\right]\oplus block\left[13\right]$
11:	$rk\left[2\right]\leftarrow block\left[2\right]\oplus block\left[6\right]\oplus block\left[10\right]\oplus block\left[14\right]$
12:	$rk\left[3\right]\leftarrow block\left[3\right]\oplus block\left[7\right]\oplus block\left[11\right]\oplus block\left[15\right]$
	STEP 6: LAYER 2 – Chaos AFTER ChaCha20
13:	$rk\left[0\right]\leftarrow rk\left[0\right]\oplus cv\left[4\right]$
14:	$rk\left[1\right]\leftarrow rk\left[1\right]\oplus cv\left[5\right]$
15:	$rk\left[2\right]\leftarrow rk\left[2\right]\oplus cv\left[6\right]$
16:	$rk\left[3\right]\leftarrow rk\left[3\right]\oplus cv\left[7\right]$
	STEP 7: Store round key
17:	$round\text{\_}keys\left[round\right]\leftarrow Pack\left(rk\right)$
	STEP 8: Mutate for next round
18:	for $i\leftarrow 0$ to 7 do
19:	$key\text{\_}words\left[i\right]\leftarrow (key\text{\_}words\left[i\right]\oplus block\left[i\right])\mathrm{mod}{2}^{32}$
20:	end for
21:	end for
22:	return $round\text{\_}keys$

The 8D chaotic system generates eight random numbers per round; these are XORed into the key schedule BEFORE the ChaCha20 block runs to change its input, and AGAIN AFTER it runs to add extra randomness to the round key. This approach delivers an effective cryptographic foundation by ensuring high entropy exceeding 253 bits across all round keys, thereby providing defense in depth against key recovery attacks through a non-invertible key schedule. The chaotic generator advances its internal state on every invocation. Two encryptions of the same plaintext under the same master key therefore consume different chaotic vectors and produce different ciphertext. Chaos-NeoCipher retains near-ideal entropy (7.996 bits/byte) in this condition because its chaotic generator advances state on every encryption invocation.

The chaotic key schedule is deterministic given the master key and a 96-bit nonce. For each encryption operation, the chaotic system is initialized as follows:

$$seed=SHA-256\left(maste{r}_{k}ey\right|\left|nonce\right)$$

The system generates round-specific chaotic vectors that are injected into the key schedule, as described in Algorithm 3. The nonce is transmitted in plaintext alongside the ciphertext. This design ensures that the decrypting party can reconstruct the identical chaotic state without requiring inter-broker state synchronization, as the state is derived independently from the shared key and per-message nonce. Because each message carries its own independent nonce, out-of-order delivery, retransmissions, and broker failover do not affect synchronization.

Nonce Management in Distributed Environment

Chaos-NeoCipher requires a unique 96-bit nonce per encryption. Each MQTT client maintains a monotonically increasing counter as its nonce source:

$$\mathrm{nonce}=(\mathrm{random}\text{\_}\mathrm{seed}\ll 64)\mid \mathrm{counter}$$

where random_seed is a 32-bit unique per-device value and counter is a 64-bit monotonically increasing counter. This approach provides three essential properties: (1) uniqueness across all messages from a given sender, (2) predictability for the receiver to verify freshness, and (3) replay resistance, reinforced by the consensus-based detection layer (Section 3.2.4). The nonce is transmitted in plaintext preceding the ciphertext, as standard AEAD practice, with the authentication tag protecting against tampering. The receiver reconstructs the identical chaotic state from the shared master key and transmitted nonce. In the event of counter desynchronization, the system falls back to random nonce generation with full 96-bit entropy, providing negligible collision probability $2^{-96}$. Because the chaotic state depends only on (master_key, nonce), retransmissions, out-of-order delivery, and broker failover are handled without synchronization issues, as shown in Table 4.

Table 4. Handling of retransmissions and out-of-order delivery.

Scenario	Handling
MQTT QoS retransmission	Same nonce reused; receiver caches decrypted messages by nonce
Out-of-order delivery	Each message carries independent nonce; decryption order unaffected
Broker failure/redirection	Any broker with master key can reconstruct chaotic state independently

No broker maintains persistent per-client nonce state, enabling horizontal scalability, fault tolerance, and load balancing.

3.1.3. Two-Layer Authentication (AEAD for Integrity and SHA-256 for Identity)

An important architectural decision in our framework is keeping SHA-256 authentication separate from NeoCipher’s encryption. This separation creates defense in depth:

1.

NeoCipher’s AEAD tag verifies ciphertext integrity (detects corruption attacks).

2.

SHA-256 authentication verifies node identity (detects spoofing attacks).

If an attacker breaks one component, the other still provides protection. Two different attacks (corruption vs. spoofing) require two different defense mechanisms.

AEAD is a cryptographic mode that simultaneously provides authentication and encryption, as shown in Table 5.

Table 5. Two-layer authentication architecture.

Layer	Mechanism	Purpose	Attack Detected
Layer 1	NeoCipher AEAD Tag	Verifies ciphertext integrity	Corruption
Layer 2	SHA-256 Authentication	Verifies node identity	Spoofing

Each message consists of the following three components:

1.

Nonce (96 bits): A unique number used once per encryption operation to ensure that identical plaintexts encrypt to different ciphertexts. It is transmitted in plaintext alongside the ciphertext.

2.

Ciphertext (variable length): The encrypted payload produced by NeoCipher in authenticated CTR mode. Only authorized parties with the correct key can decrypt this to recover the plaintext.

3.

AEAD Tag (128 bits): A cryptographic authentication tag that provides the following:

• Integrity verification: Ensures the ciphertext has not been altered in transit.
• Message authentication: Verifies the message originates from a legitimate source.
• Corruption detection: Any modification of the message results in tag mismatch.

The AEAD tag is computed using the nonce, ciphertext, and associated data (such as node ID or message metadata). Upon reception, the receiver recomputes the tag and compares it with the transmitted tag. If they match, the message is accepted; otherwise, it is rejected as corrupted or tampered.

Formally, the sender generates the SHA-256 authentication tag by hashing the concatenation of the plaintext data, the node identifier, and the nonce, then truncating to 128 bits, as specified in Algorithm 4. On reception, the receiver recomputes the expected tag from the decrypted data, the claimed sender ID, and the transmitted nonce, and compares it to the received tag, as specified in Algorithm 5. If the two tags match, the message is accepted; otherwise, the spoofing counter is incremented, and the message is rejected.

This structure ensures that the framework provides both confidentiality (via encryption) and integrity (via AEAD tag verification), forming the first layer of defense against active attacks such as message tampering and forgery, as shown in Figure 6:

Algorithm 4 SHA-256 Authentication Tag Generation (Sender)
Require: Plaintext data $data$, Node ID $node\text{\_}id$, Nonce $nonce$
Ensure: Authentication tag (128 bits)
1:	$input\leftarrow data.encode\left(\right)\Vert str\left(node\text{\_}id\right).encode\left(\right)\Vert nonce$
2:	$hash\leftarrow SHA-256\left(input\right)$
3:	$tag\leftarrow hash[0:16]$
4:	return $tag$

Algorithm 5 SHA-256 Authentication Verification (Receiver)
Require: Decrypted data $data$, Sender ID $sender$, Nonce $nonce$, Received tag $tag$
Ensure: Authentication success or failure
1:	$expected\leftarrow SHA-256(data.encode()\Vert str(sender).encode()\Vert nonce)[0:16]$
2:	if $expected=tag$ then
3:	return True
4:	else
5:	$spoofing\text{\_}detected\leftarrow spoofing\text{\_}detected+1$
6:	return False
7:	end if

Figure 6. Two-layer authentication flow: AEAD tag verification followed by SHA-256 identity verification. Red dashed arrows indicate rejected messages.

3.2. Parallel Multi-Broker MQTT Management

The novel architecture consists of six core components. The components work together to provide coordinated security responses, fault tolerance, and dynamic load balancing in a distributed MQTT environment.

3.2.1. Parallel Multi-Broker Architecture:

Each broker maintains state $S\in$ {ACTIVE, DEGRADED, OVERLOADED, OFFLINE,

RECOVERING}. Status transitions occur based on load factor ℓ:

$$\mathcal{\ell }={\displaystyle \frac{|Q_{\mathrm{pending}}|}{Q_{\max }}}$$

$$S=\left\{\begin{array}{cc}\mathrm{ACTIVE}\hfill & \mathcal{\ell }<0.7\hfill \\ \mathrm{DEGRADED}\hfill & 0.7\le \mathcal{\ell }<0.9\hfill \\ \mathrm{OVERLOADED}\hfill & \mathcal{\ell }\ge 0.9\hfill \end{array}\right.$$

The performance targets in Table 6 are derived from architectural reasoning:

Table 6. Comparison: single vs. parallel broker architecture.

Aspect	Single Broker	Parallel Brokers ($\mathit{N}\ge 4$)
Fault Tolerance	Single point of failure	Redundant, no single failure point (design objective)
Scalability	Vertical scaling only	Horizontal scaling
Attack Response	Local only	Coordinated across all brokers
Load Distribution	None	Dynamic balancing
Availability	∼95–99% (estimated)	≥99.99% (design target)
Throughput	∼2000 msg/s (estimated)	≥8000 msg/s (design target)

• Availability (≥99.99%): With $N\ge 4$ brokers and heartbeat-based failure detection (≤1.5 s detection, ≤3 s recovery), the theoretical availability is $1-{\left(\mathrm{failure}\text{\_}\mathrm{probability}\right)}^N$, which exceeds 99.99% for $N\ge 4$ assuming independent failures.
• Throughput (≥8000 msg/s): With 10 brokers × 2000 msg/s per broker (estimated from per-broker capacity) = 20,000 msg/s theoretical maximum. The 8000+ msg/s target accounts for approximately 40% inter-broker overhead based on Detti et al. [24]. These are design targets, not measured results. Experimental validation in a real deployment is identified as future work (Section 5).

3.2.2. Inter-Broker Communication Bus

Traditional MQTT deployments rely on a single broker architecture, creating a central point of failure and limiting coordinated security responses. Our proposed distributed architecture addresses these limitations through an Inter-Broker Communication Bus that connects N ≥ 4 parallel brokers. This bus serves as the backbone for three essential communication types:

A.

Heartbeat: The heartbeat messages enable the real-time health monitoring of all brokers. Every broker sends a heartbeat every 0.5 s. If a broker misses three consecutive heartbeats (1.5 s), it is considered failed.

The HEARTBEAT message is the foundation of the entire parallel multi-broker architecture. It provides the following:

• Real-time health monitoring through frequent updates.
• Dynamic load balancing by reporting current load metrics.
• Failure detection by tracking missed heartbeats.
• System visibility by making every broker’s status known to all others A.

Every 0.5 s, every broker shares five critical metrics that together paint a complete picture of its current state. This constant stream of health information enables the system to make intelligent decisions about load distribution, failure recovery, and attack response-all in real-time, without human intervention. The result is a self-healing, self-balancing, highly available MQTT cluster that can automatically detect and respond to changing conditions; see Algorithm 6.

B.

Forward: Forward messages enable dynamic load redistribution. When a broker becomes overloaded, it sends a forward message to redirect traffic to less-loaded brokers.

C.

Attack-Alert: Attack-Alert messages enable coordinated security responses. When any broker detects an attack, it broadcasts an Attack-Alert to all other brokers, triggering simultaneous defense activation.

We note that the Inter-Broker Communication Bus, load balancer, and consensus detector are themselves potential dependencies that require redundancy to avoid introducing new single points of failure. In our architecture, these components are designed as replicated services, though fault-injection validation is identified as future work.

Algorithm 6 Inter-Broker Bus Operation
	Data Structures:
1:	$subscribers\leftarrow \left\{\right\}$	▹ broker_id → MessageQueue
2:	$history\leftarrow \left\{\right\}$	▹ Set of processed message IDs
3:	procedure Publish($msg$, $source$)
4:	if $msg.id\in history$ then
5:	return
6:	end if
7:	$history.add(msg.id)$
8:	if $msg.target$ is specified then
9:	$subscribers[msg.target].put\left(msg\right)$
10:	else
11:	for each broker b in $subscribers$ with $b\ne source$ do
12:	$subscribers\left[b\right].put\left(msg\right)$
13:	end for
14:	end if
15:	end procedure
16:	procedure Receive($broker\text{\_}id$)
17:	return $subscribers\left[broker\text{\_}id\right].get(timeout=0.001)$
18:	end procedure

The Inter-Broker Communication Bus is implemented as a logically centralized but physically distributed publish–subscribe channel, with each broker running an independent bus agent connected in a fully redundant mesh topology. This design mitigates the bus as a single point of failure: if any broker fails, the remaining bus agents continue communication through alternate paths. Messages are multicast with retry mechanisms to ensure delivery even under partial network failure. The logical centralization simplifies coordination semantics, while the physical distribution ensures resilience.

3.2.3. Smart Load Balancer

The load balancer uses inverse load-factor weighting: brokers with lower load receive higher weights, making them more likely to receive new connections. The Smart Load Balancer is a critical component of the parallel multi-broker architecture. It continuously monitors broker loads through heartbeat messages, calculates dynamic weights using an inverse load factor formula, and performs weighted random selection to distribute new connections. The system is self-balancing, adaptive, and fault-tolerant.

By ensuring that no single broker becomes overloaded, the load balancer enables the entire cluster to operate efficiently and reliably.

The Smart Load Balancer is a dynamic traffic distribution system that decides which broker should receive new client connections. Unlike simple round-robin or random selection, this balancer uses real-time load information to make intelligent decisions. The core principle is simple: brokers with lower load get more connections, while brokers with higher load get fewer connections. The system continuously adapts as loads change. In essence, the Smart Load Balancer turns a collection of individual brokers into a unified, scalable, and resilient system that can handle varying workloads without manual intervention.

The Smart Load Balancer dynamically distributes client connections across brokers through four integrated mechanisms:

1.

Continuous Load Monitoring: Every 0.5 s, each broker reports its current load factor (ℓ = pending messages/maximum queue capacity) via heartbeat messages, providing real-time visibility into each broker’s state.

2.

Dynamic Weight Calculation: Using an inverse load-factor formula $w$ = 1.0/load_factor + 0.01, brokers with lower loads receive higher weights, while heavily loaded brokers receive lower weights.

3.

Weighted Random Selection: The load balancer probabilistically selects brokers based on their calculated weights—lower-loaded brokers have higher selection probabilities, ensuring traffic is directed to the least congested brokers.

4.

Continuous Adaptation: As broker loads change over time, weights are automatically recalculated, and selection probabilities adjust accordingly, ensuring the system remains self-balancing without manual intervention.

This approach ensures no single broker becomes overloaded, the cluster operates efficiently, and the system is self-balancing, adaptive, and fault-tolerant—automatically handling broker failures and recoveries see (Algorithm 7).

The Smart Load Balancer uses an inverse load-factor weighting formula:

$$w={\displaystyle \frac{1}{\mathcal{\ell }+0.01}}$$

where ℓ is the load factor. The constant $0.01$ prevents division by zero and bounds the maximum weight to 100, ensuring no single broker receives excessive traffic. This feedback mechanism prevents oscillatory load redistribution, with empirical convergence observed within 3–5 heartbeat intervals.

Algorithm 7 Smart Load Balancer
1:	Data: $metrics=\left\{\right\}$	▹ broker_id → load_factor
2:	Data: $brokers=\left[\right]$	▹ List of available broker IDs
3:	procedure Update($broker\text{\_}id$, $load\text{\_}factor$)
4:	$metrics\left[broker\text{\_}id\right]\leftarrow load\text{\_}factor$
5:	end procedure
6:	procedure SelectBroker
7:	$weights\leftarrow \left[\right]$
8:	$total\text{\_}weight\leftarrow 0$
9:	for each $broker\text{\_}id$ in $brokers$ do
10:	$w\leftarrow 1.0/\left(metrics\right[broker\text{\_}id]+0.01)$
11:	$weights.\mathrm{append}\left(w\right)$
12:	$total\text{\_}weight\leftarrow total\text{\_}weight+w$
13:	end for
14:	$r\leftarrow \mathrm{random}(0,total\text{\_}weight)$
15:	$cumulative\leftarrow 0$
16:	for $i=0$ to $\mathrm{len}\left(weights\right)-1$ do
17:	$cumulative\leftarrow cumulative+weights\left[i\right]$
18:	if $r\le cumulative$ then
19:	return $brokers\left[i\right]$
20:	end if
21:	end for
22:	return $brokers\left[0\right]$	▹ Fallback
23:	end procedure

3.2.4. Consensus-Based Global Attack Detection

The method detects global attacks by aggregating broker reports within a 3 s window and triggering an alert only when at least $\tau =2$ brokers independently report the same attack type. This consensus rule ensures reliable detection while suppressing false alarms from individual compromised or faulty brokers. Algorithm 8 presents the mechanism.

$$\mathrm{GlobalAlert}=\left\{\begin{array}{cc}\mathrm{True},\hfill & \mathrm{if}\left|\right\{\mathrm{brokers} \mathrm{reporting} \mathrm{same} \mathrm{attack}\left\}\right|\ge \tau \hfill \\ \mathrm{False},\hfill & \mathrm{otherwise}\hfill \end{array}\right.$$

(1)

where $\tau =2$ and reports are only considered within a $W=3$ second sliding window.

Algorithm 8 Global Attack Detection with Consensus
Require: Attack reports from brokers, Window $W=3$ s, Threshold $\tau =2$
Ensure: Global alert if consensus reached
1:	$reports\leftarrow \left[\right]$
2:	loop
3:	$r\leftarrow waitForReport\left(\right)$
4:	$reports.append\left(r\right)$
5:	$reports\leftarrow removeReportsOlderThan\left(W\right)$
6:	for each attack type A do
7:	$B_A\leftarrow$ {broker_id∣report of A from broker}
8:	if $|B_A|\ge \tau$ and $A\notin activeThreats$ then
9:	$activeThreats.add\left(A\right)$
10:	$broadcastAlert(A,B_A)$
11:	$activateDefenseMode\left(\right)$
12:	end if
13:	end for
14:	end loop

Now, we analyze the consensus mechanism ($\tau =2$, $W=3$ s) across six threat scenarios:

• Compromised brokers: One malicious broker cannot trigger a global alert; detection remains $99.07\%$ with zero FPR.
• Malicious false alerts: $\tau =2$ prevents single-source false alarms. Two colluding brokers increase FPR to $0.12\%$, mitigated via a proposed reputation system (future work).
• Correlated alarms: Evidence-based verification requires consistent attack evidence across reporting brokers, preventing false consensus.
• Clock skew: The 3 s window accommodates $\pm 500$ ms skew; detection remains $>99\%$ with NTP synchronization.
• Network delays/partitions: Delays $>3$ s reduce detection to ≈94%; mitigations include heartbeat monitoring and local logging.
• Varying active brokers: $\tau =2$ remains effective for $N\ge 4$; with $N<4$ system transitions to local detection.

Table 7 reports the trade-off across $\tau \in \{1,2,3,4\}$ for $N=10$ brokers. $\tau =2$ is optimal, it provides zero FPR, tolerates one compromised broker, maintains $>99\%$ detection, and achieves $1.2$ s latency—the best balance among all thresholds.

Table 7. Consensus threshold ($\tau$) trade-off analysis ($N=10$ brokers).

$\mathit{\tau }$	Detection Rate (%)	FPR (%)	Latency (s)	Malicious Brokers Tolerated
1	99.91	0.12	0.5	0
2	99.07	0.00	1.2	1
3	97.84	0.00	2.1	2
4	94.23	0.00	3.0	3

The consensus mechanism tolerates up to $\tau -1=1$ malicious broker and up to $N-\tau =8$ failed brokers. With NTP synchronization ($\pm 500$ ms), detection remains $>99\%$. For $N<4$, the system transitions to local detection mode.

3.2.5. Broker Path Verification for MITM Detection

Algorithm 9 detects MITM attacks by verifying that a message arrives via the correct broker. It retrieves the expected broker ID and searches for the actual broker that has the sender in its subscriber list. If the actual broker differs from the expected broker, a spoofing attempt is detected; the algorithm increments the counter, reports the incident, and rejects the message. Otherwise, the message is accepted as legitimate. The algorithm presents the broker path verification method. MITM attacks are defined as broker-substitution scenarios where an attacker redirects traffic to an unauthorized broker or impersonates a legitimate broker. The broker-path verification mechanism detects such attacks by checking path mismatches. MITM attacks occurring transparently along the legitimate path without altering broker identity (e.g., passive eavesdropping, link-layer interception) are outside this mechanism’s scope and are addressed by the cryptographic layer (NeoCipher encryption and authentication). Each node maintains an expected broker mapping from the load balancer. When receiving a message, the node verifies the broker path.

The per-node rate limiting mechanism prevents any single node from exceeding a configurable maximum message rate. In our experimental configuration, we set this threshold to $R=50$ messages per second, chosen to reflect the traffic characteristics of typical IoT sensing applications (periodic sensors, event-driven reporting) in our testbed. However, we emphasize that this threshold is application-dependent. IoT devices vary considerably in legitimate transmission frequency: industrial sensors may publish at 1–10 Hz, healthcare monitors at 10–100 Hz, multimedia sensors at higher rates, and event-driven actuators sporadically. The threshold should be configured per deployment based on expected legitimate traffic profiles. The sliding window algorithm itself is threshold-agnostic and applies to any configured R value, making it suitable for diverse IoT applications with appropriate parameter tuning.

Algorithm 9 Broker Path Verification for MITM Detection
Require: Message with sender ID, receiving node’s broker reference
Ensure: MITM detection if path mismatch
1:	expected_broker ← self.broker.broker_id
2:	actual_broker ← None
3:	for each bid, broker in self.broker.balancer.metrics do
4:	if sender ∈ broker.subscribers then
5:	actual_broker ← bid
6:	break
7:	end if
8:	end for
9:	if actual_broker ≠ None ∧ actual_broker ≠ expected_broker then
10:	spoofing_detected ← spoofing_detected + 1
11:	detector.report(broker_id, “MITM ”, details)
12:	return False	▹ Reject message
13:	end if
14:	return True

Threat Model, Detection Scope, and Limitations of Broker-Path Verification

Algorithm 9 verifies that an incoming message arrives via the broker the receiving node expects, based on the node-to-broker binding from the Smart Load Balancer (node_map[node_id]). It compares the expected broker (self.broker.broker_id, recorded at registration) with the actual broker at runtime (the broker whose subscriber list contains the sender). A mismatch increments spoofing_detected, reports MITM to the Global Attack Detector, and rejects the message.

The expected broker is recorded at node registration; the actual broker handled the packet at runtime. The two can legitimately diverge because ParallelSecureBroker.publish() forwards traffic to another broker when status == OVERLOADED and not defense_mode, emitting a FORWARD message with a new target_broker. This rerouting changes the handling broker without changing the node’s expected broker, so Algorithm 9 flags it as a path deviation. In the current implementation, legitimate overload forwarding can be misclassified as MITM unless the forward is tagged and trusted. Distinguishing legitimate FORWARD traffic from adversarial rerouting is identified as required future work.

The framework authenticates nodes (SHA-256) and payloads (NeoCipher AEAD), but not brokers or inter-broker control messages. An attacker on the inter-broker bus can redirect traffic to a rogue broker by injecting unsigned FORWARD messages, forging HEARTBEATs with load_factor ≈ 0 to maximize inverse-load weight, or overloading a legitimate broker so publish() forwards to the already top-weighted rogue broker. The attacker can impersonate a legitimate broker by registering a colliding broker ID, forging heartbeats with another broker’s source_broker, or broadcasting forged ATTACK_ALERTs to suppress consensus or force defense_mode.

3.2.6. Per-Node Rate Limiting

Algorithm 10 maintains a timestamp history for each node and applies a sliding window filter to retain only messages received within the last second. When a new message arrives, the system appends the current timestamp, removes all entries older than one second, and counts the remaining timestamps. If the count surpasses the threshold of 50, the node is immediately added to a blocklist and its message is rejected. Otherwise, the message is accepted for normal processing. This approach ensures accurate, real-time rate enforcement while avoiding the boundary burst vulnerabilities inherent in fixed-window algorithms, making it ideal for protecting distributed messaging systems from denial-of-service attacks.

Algorithm 10 Per-Node Rate Limiting with Sliding Window
Require: Node ID, current timestamp $now$, max rate $R=50$ msg/s
Ensure: Block node if rate exceeded
1:	$timestamps\leftarrow$ node_msg_count[node_id]
2:	$timestamps.\mathrm{append}\left(now\right)$
3:	$timestamps\leftarrow \{t\mid t\in timestamps\wedge t>now-1 \mathrm{s}\}$
4:	node_msg_count[node_id] $\leftarrow timestamps$
5:	if $\left|timestamps\right|>R$ then
6:	blocked_nodes.add(node_id)
7:	return False	▹ Skip processing
8:	end if
9:	return True

3.2.7. Fault Tolerance Mechanisms

The system uses heartbeat messages for failure detection with a coordinated recovery process. Each broker sends a heartbeat every 0.5 s to the Inter-Broker Bus. If a broker misses three consecutive heartbeats (1.5 s total), it is declared failed, and all other brokers are notified via Attack-Alert. The failure detection and recovery Algorithm 11 is shown below.

Algorithm 11 Failure Detection and Recovery
1:	Data: $missed\text{\_}heartbeats=\left\{\right\}$	▹ broker_id → count
2:	Data: $brokers=\left[\right]$	▹ List of all brokers
3:	Data: $subscribers=\left\{\right\}$	▹ broker_id → list of subscribers
4:	procedure CheckHeartbeats
5:	for each $broker\text{\_}id$ in $brokers$ do
6:	if no HEARTBEAT received from $broker\text{\_}id$ in last 1.5 s then
7:	$missed\text{\_}heartbeats\left[broker\text{\_}id\right]\leftarrow missed\text{\_}heartbeats\left[broker\text{\_}id\right]+1$
8:	if $missed\text{\_}heartbeats\left[broker\text{\_}id\right]\ge 3$ then
9:	Declare $broker\text{\_}id$ as OFFLINE
10:	Redistribute subscribers of $broker\text{\_}id$ to active brokers
11:	Update Load Balancer to exclude $broker\text{\_}id$
12:	Broadcast ATTACK_ALERT to all brokers
13:	Continue operation with $N-1$ brokers
14:	end if
15:	else
16:	$missed\text{\_}heartbeats\left[broker\text{\_}id\right]\leftarrow 0$	▹ Reset counter
17:	end if
18:	end for
19:	end procedure
20:	procedure RecoverBroker($broker\text{\_}id$)
21:	Detect $broker\text{\_}id$ sending new HEARTBEAT
22:	Mark $broker\text{\_}id$ as ACTIVE
23:	Add $broker\text{\_}id$ back to Load Balancer
24:	Redistribute subscribers to include $broker\text{\_}id$
25:	Update all brokers with new state
26:	end procedure

Recovery Time Objectives (RTO)

To ensure high availability, the system maintains strict recovery time objectives. Table 8 summarizes the key performance metrics for failure detection and recovery.

Table 8. Failure recovery performance metrics.

Metric	Value
Heartbeat Interval	0.5 s
Failure Detection Time	≤1.5 s
Subscriber Redistribution	<100 ms
Load Balancer Update	<50 ms
Broker Recovery	<1 s
Total Recovery Time	≤3 s

Failure Recovery Process

When a broker fails, the system executes the following steps, as shown in Table 9. The failure recovery process follows these sequential steps:

Table 9. Broker failure recovery process.

Step	What Happens	Time	Result
1. Broker Fails	A broker crashes unexpectedly	Instant	—
2. Detection	System notices three missed heartbeats	≤1.5 s	Triggers recovery
3. Redistribution	Clients moved to healthy brokers	<5 s	No data loss
4. Recovery	System fully restored	<5 s	Back to normal

• Detection Phase (0–1.5 s): Each broker monitors heartbeats from all other brokers. Three consecutive missed heartbeats trigger failure detection.
• Failure Declaration: The detecting broker declares the unresponsive broker as OFFLINE and alerts the Global Attack Detector.
• Subscriber Redistribution: All subscribers from the failed broker are automatically redistributed to the remaining active brokers using the Smart Load Balancer.
• Load Balancer Update: The failed broker is removed from the load balancer’s active pool, and weights are recalculated.
• Normal Operation: The system continues with $N-1$ brokers, maintaining service availability.
• Recovery Phase: When the failed broker recovers and sends a new heartbeat, it is automatically rejoined to the pool.

Subscriber Redistribution Mechanism

When a broker is declared OFFLINE, the remaining brokers use the Smart Load Balancer’s weighted selection (Algorithm 7, weight $w$ = 1/(ℓ + 0.01)) to reassign each orphaned subscriber one at a time. After each assignment, the selected broker’s effective load is incremented so later draws see the updated weight, preventing concentration on a single broker. The failed broker is removed from the active pool, and node_map[node_id] is updated for every reassigned node so its expected broker points to the new broker. This update is essential: without it, Algorithm 9 would flag the next message as MITM (Section 3.2.5). When the broker recovers, Algorithm 11 (Section 3.2.7) (RECOVERBROKER) re-adds it to the pool; existing subscribers stay put until the next rebalance, avoiding unnecessary churn.

Resilience Metrics

To ensure high availability and minimal disruption during broker failures, the system is designed to meet the following key resilience targets. These metrics define the maximum allowable time for failure detection, client redistribution, and full system recovery, as shown in Table 10. The system successfully balances security and availability. The resilience metrics ensure this even during broker failures or active attacks.

Table 10. Fault tolerance metrics.

Metric	Value	Description
Failure Detection Time	≤1.5 s	Three missed heartbeats
Subscriber Redistribution	<5 s	Move clients to healthy brokers
System Recovery	<5 s	Full recovery after failure
Availability	>99.99%	With $N\ge 4$ brokers
Data Loss	None	Messages redistributed

4. Experimental Analysis and Results

The eight-round, 10-broker system implements a comprehensive security architecture with multi-layer attack detection, including replay detection, rate limiting (50 msg/s), MAC verification, integrity checks, and behavioral anomaly detection. The system features adaptive defense mechanisms that increase drop rates during global threats, consensus-based global detection across brokers, and weighted load balancing for optimal performance. With NeoCipher encryption (AES + ChaCha20 hybrid with 8D chaos) and parallel processing (10 worker threads per broker), the architecture demonstrates production-ready security capabilities. The system maintains broker health through active monitoring and automatic degradation handling.

4.1. Simulation Environment and Phases

The Chaos-Enhanced Parallel Multi-Broker MQTT Simulation is a comprehensive IoT security testing framework that implements the following:

• 10 Parallel Brokers with load balancing and fault tolerance.
• Chaos-Enhanced NeoCipher: Hybrid AES + ChaCha20 + 8D Chaotic System.
• 100 IoT Nodes with secure MQTT communication.
• Five Attacker Nodes executing six attack types.
• Global Attack Detection using consensus mechanism ($\tau =2$, $W$ = 3 s).

The 10-round configuration in Table 2 represents the base simulation loop for a single experimental run, while the 30 seeds × 40 rounds represent the aggregated validation across multiple independent runs. Specifically:

The rate limit of $R=50$ msg/s was selected based on the traffic characteristics of our simulated IoT environment, which included periodic sensors (40%), event-driven sensors (30%), high-rate sensors (20%), and actuators (10%). This threshold is specific to our experimental configuration and is not intended as a universal recommendation. In production deployments, the threshold should be tuned according to the expected legitimate traffic of each device type.

4.1.1. Phase 1: Environment Setup

• Import required libraries (hashlib, random, threading, queue, matplotlib).
• Define AttackType Enum (eight attack types).
• Define BrokerStatus Enum (five status states).
• Create data classes (PacketMetrics, BrokerMetrics, AttackConfig).
• ConFigure matplotlib for 1024 × 720 pixel output.

4.1.2. Phase 2: Encryption Implementation

• Implement GF256 for Galois Field operations.
• Generate AES S-box and inverse S-box.
• Implement ChaCha20 ARX operations.
• Create 8D Chaotic System with coupled maps.
• Implement NeoMix (replaces AES MixColumns).
• Create Chaos-Enhanced Key Schedule.
• Implement NeoCipher block cipher.
• Implement CTR mode with authentication.

Crucially for experimental validity, the chaotic injection is implemented as a single switchable parameter, so that NeoCipher and Chaos-NeoCipher differ in exactly one variable. This isolates the chaotic contribution and makes the comparison in Section 4.2, Section 4.3, Section 4.4, Section 4.5, Section 4.6 and Section 4.7 a controlled ablation of a comparison between two independently built systems.

4.1.3. Phase 3: Communication Infrastructure

• InterBrokerBus: Message passing between brokers.

  -

  Heartbeat messages (every 0.5 s).

  -

  Attack alerts (global broadcast).

  -

  Message forwarding (load redistribution).

• SmartLoadBalancer: Weighted distribution.
• GlobalAttackDetector.

4.1.4. Phase 4: Broker Pool Creation

The parallel broker pool is initialized with 10 brokers, each configured with a message queue (5000 messages), 10 worker threads, and security modules, including encryption, authentication, and defense mechanisms. Listing 1 shows the broker initialization code.

Listing 1. Broker Initialization.

class ParallelSecureBroker:   def  __init__(self, broker_id, bus, balancer, detector):     self.msg_queue = queue.Queue(maxsize = 5000)     self.executor = ThreadPoolExecutor(max_workers = 10)     self.defense_mode = True         self.drop_rate = 0.05     self.max_rate = 50  # messages per second     self.node_msg_count = defaultdict(list)

def start(self):     Thread(target=self._heartbeat, daemon=True).start()     Thread(target=self._processor, daemon=True).start()     Thread(target=self._listener, daemon=True).start()

4.1.5. Phase 5: Node Creation

Table 11 presents the distribution of nodes in the simulation environment, comprising 100 legitimate IoT devices and five attacker nodes executing malicious operations.

Table 11. Node types and counts.

Node Type	Count	Description
SecureMQTTNode	100	Normal IoT devices with NeoCipher encryption
AttackerNode	5	Malicious nodes executing attacks

4.1.6. Phase 6: Simulation Loop

The simulation executes ten rounds, where each round processes legitimate messages from all 100 nodes and attack messages from the five attacker nodes based on the configured attack intensity (20–25%). Listing 2 presents the main simulation loop implementation.

Listing 2. Main Simulation Loop.

for  round_num in range(10):  # 10 rounds      # All 100 nodes publish normal messages      with ThreadPoolExecutor(max_workers = 8) as ex:          futures = [ex.submit(n.publish) for n in nodes]          for f in as_completed(futures):              all_metrics.append(f.result())

# Attackers conduct attacks      for atk in attackers:          if random.random() < intensity:              attack_metrics.append(atk.conduct_attack())

# Progress reporting      if (round_num + 1) % 3 == 0:          print(f"Round␣{round_num + 1}:␣{stats[’total_msgs’]}␣msgs")

4.1.7. Phase 7: Message Processing

1.

Rate limiting (50 msg/s per node).

2.

Queue processing (10 worker threads).

3.

Load monitoring (ACTIVE/DEGRADED/OVERLOADED).

4.

Attack detection (five mechanisms).

5.

Defense mode activation.

4.2. Ciphertext-Repetition Leakage (Primary Cryptographic Result)

The repetition-leakage experiment was conducted as a controlled comparison where all three ciphers-AES-128, base NeoCipher, and Chaos-NeoCipher-operated under identical conditions with fixed key, nonce, and counter parameters. This methodology isolates the chaotic key perturbation as the sole variable, thereby demonstrating the structural vulnerability of deterministic encryption when operating under fixed parameters. We acknowledge that proper nonce management with unique nonces per encryption would produce different ciphertexts for repeated plaintext in any CTR-mode cipher. However, our contribution addresses the practical constraints of resource-constrained IoT deployments, where many devices lack the capability for proper nonce management due to synchronization overhead, limited randomness sources, and implementation complexity.

The chaotic key schedule offers a practical and self-contained solution by eliminating repetition leakage even when nonces remain fixed, without imposing additional nonce management overhead. This represents a key contribution of our work, providing an effective mitigation for a practical IoT vulnerability that existing lightweight cryptography proposals have not addressed.

This experiment tests the vulnerability identified in Section 1.1, which is specific to IoT telemetry workloads and is not captured by conventional cryptographic evaluation on high-entropy inputs. A single fixed key encrypts 3000 consecutive plaintext blocks under four input conditions, and the Shannon entropy of the resulting ciphertext stream is measured. Shannon entropy is computed over the byte distribution of the full ciphertext stream; the theoretical maximum is 8.000 bits/byte, as shown in the Table 12.

Table 12. Ciphertext entropy (bits/byte) under four input conditions; ideal = 8.000.

Input Condition	AES-128	NeoCipher (Base)	Chaos-NeoCipher
Random plaintext	7.996	7.996	7.996
Structured text payloads	7.996	7.996	7.996
Repeated identical block (fixed key)	4.000	3.875	7.996
Cycling byte pattern	7.954	7.958	7.997

Formally, $H=-{\sum }_{b}p\left(b\right){log}_{2}p\left(b\right)$ over byte values $b\in \{0,\dots ,255\}$, where $p\left(b\right)$ is the empirical frequency of byte b in the concatenated 3000-block ciphertext stream; the maximum is ${log}_2\left(256\right)=8.000$ bits/byte.

Under non-repeating input, all three ciphers are statistically indistinguishable and near-ideal, the expected result, and a useful correctness check on the implementation. Under repeated identical plaintext, however, AES-128 and base NeoCipher lose more than half of their ciphertext entropy. The mechanism is structural rather than a weakness of either cipher’s round function: identical input under an identical key deterministically produces identical output, so a stream of repeated blocks yields a stream of repeated ciphertext blocks, and the byte distribution collapses onto a small support set. Chaos-NeoCipher retains near-ideal entropy (7.996 bits/byte) in this condition because its chaotic generator advances state on every encryption invocation (Section 3.1.2), so the same plaintext under the same master key produces different ciphertext on each call. The practical consequence for MQTT telemetry is direct: a passive observer of an encrypted MQTT stream can distinguish “reading unchanged” from “reading changed” under AES-128 or base NeoCipher, inferring occupancy, activity schedules, and operational state without breaking the cipher, and cannot do so under Chaos-NeoCipher. This constitutes the framework’s clearest and most practically relevant cryptographic contribution for IoT deployment.

To complement the entropy analysis, we measured ciphertext block repetition frequency under repeated identical plaintext. AES-128 and base NeoCipher exhibit repetition rates of $0.998$ and $0.997$, respectively-meaning a passive observer would see nearly identical ciphertext blocks for every unchanged sensor reading. In contrast, Chaos-NeoCipher exhibits a repetition rate of $0.0003$, effectively indistinguishable from random. (5) Under AES-128 in CTR mode with fixed key, nonce, and counter, the keystream is identical for every message, so identical plaintext blocks produce byte-identical ciphertext blocks. A passive observer can partition the ciphertext into 16-byte blocks and test for equality without holding the key. A run of repeated blocks reveals an unchanged reading; a new block reveals a change; a return to a prior block reveals a return to a prior state. The measured entropy of $4.000$ bits/byte and repetition rate of $0.998$ under repeated identical plaintext quantify the leak. Under Chaos-NeoCipher, the repetition rate falls to $0.0003$, and the observer sees no such pattern. This direct repetition metric confirms the practical leakage mechanism: an observer can trivially distinguish “reading unchanged” from “reading changed” under deterministic ciphers, while Chaos-NeoCipher provides no such observable pattern.

4.3. Avalanche Effect

The avalanche effect measures the sensitivity of an encryption algorithm to input changes. A good cipher should produce a significant change in ciphertext when a single bit of plaintext or key is modified. The ideal avalanche effect is 50%, where half of the output bits change. Table 13 reports single-bit-flip avalanche across 300 independent trials per cipher, each using a freshly generated random key and plaintext, with a randomly selected bit position. Confidence intervals are reported at the 95% level.

Table 13. Avalanche effect, single-bit plaintext flip, $n=300$ trials per cipher; ideal = 50%.

Cipher	Mean Avalanche (%)	Std. Dev.	95% CI (±)
AES-128 (reference)	50.15	4.62	0.52
NeoCipher (base)	50.17	4.54	0.51
Chaos-NeoCipher	50.01	4.58	0.51

All three ciphers converge to the ideal 50% within overlapping confidence intervals, and the differences between them are not statistically significant. This is the expected outcome once full diffusion is achieved and is reported here as a correctness check rather than as evidence of a chaos-driven improvement: since 50% is itself the target, deviating further from it in either direction would not constitute better performance. We note this explicitly because avalanche differences of one to two percentage points are sometimes reported in the literature as cipher improvements without accompanying confidence intervals; at n = 300, the confidence interval half-width here is approximately 0.5 percentage points, so differences below roughly one point cannot be distinguished from sampling noise.

4.4. Statistical Randomness

The cryptographic strength of the ciphertext streams was evaluated using the complete NIST SP 800-22 statistical test suite. Table 14 testing was conducted across the following:

Table 14. NIST SP 800-22 aggregate results.

Cipher	Tests Passed ($\mathit{\alpha }=0.01$)	Pass Rate (Proportion)	p-Value Uniformity (${\mathit{\chi }}^2$)
NeoCipher (base)	14/15	0.947	${\chi }^2=8.2$, $p=0.41$
Chaos-NeoCipher	15/15	0.983	${\chi }^2=6.7$, $p=0.57$

Proportion = sequences passing/total sequences. Pass rate target $\ge 0.96$ per NIST guidelines.

• 10 independent keys (randomly generated).
• 100 sequences per key ($1\times {10}^6$ bits each, generated in CTR mode).
• Total: 1000 sequences × 15 tests = 15,000 test instances.

Table 15, both variants meet the NIST acceptance criteria (proportion $>0.96$) for the full 15-test battery, with Chaos-NeoCipher achieving a higher pass rate and more uniform p-value distribution. The p-value uniformity analysis (${\chi }^2$ test across 10 intervals) confirms that the p-values are uniformly distributed, indicating no systematic bias in the randomness assessment.

Table 15. NIST SP 800-22 detailed results by test type.

Test Name	NeoCipher (Base)	Chaos-NeoCipher	Pass Rate Target
Frequency (Monobit)	0.983	0.997	≥0.96
Block Frequency	0.971	0.989	≥0.96
Cumulative Sums	0.965	0.992	≥0.96
Runs	0.927	0.981	≥0.96
Longest Run	0.959	0.988	≥0.96
Rank	0.973	0.994	≥0.96
FFT	0.941	0.979	≥0.96
Non-overlapping Templates	0.938	0.976	≥0.96
Overlapping Templates	0.962	0.985	≥0.96
Universal	0.948	0.982	≥0.96
Approximate Entropy	0.933	0.977	≥0.96
Random Excursions	0.954	0.983	≥0.96
Random Excursions Variant	0.942	0.976	≥0.96
Serial	0.956	0.988	≥0.96
Linear Complexity	0.969	0.991	≥0.96
Overall Pass Rate	0.947	0.983	≥0.96

4.5. Key-Schedule Optimization

Execution profiling of the chaotic variant identified chaotic-vector generation in the key schedule as the dominant source of its processing overhead, accounting for approximately 17% of total encryption time. A batched generator was therefore implemented, producing 64 steps of chaotic state per invocation and serving individual vectors from an internal buffer, with the ring-coupling indices unrolled (eliminating modulo operations at each step) and loop constants hoisted to local scope. The mathematical map, coupling topology, coupling strength $\mathsf{ϵ}$, clamping behavior, and burn-in procedure are unchanged by this optimization; it is a pure implementation-level speedup with no algorithmic or security implications. Equivalence was verified in two ways: the optimized generator was confirmed to produce bit-identical output to the reference generator across 500 consecutive chaotic vectors, and the resulting cipher was confirmed to produce bit-identical ciphertext on full-block encryption, as shown in Table 16.

Table 16. Per-block encryption latency (mean ± std dev).

Configuration	Mean (ms)	Std. Dev. (ms)	Overhead
NeoCipher (base)	$0.158\pm 0.012$	0.012	—
Chaos-NeoCipher (unoptimized)	$0.221\pm 0.018$	0.018	+39.9%
Chaos-NeoCipher (optimized)	$0.186\pm 0.014$	0.014	+17.6%
AES-128 (reference)	$0.362\pm 0.031$	0.031	+129%

All pairwise differences significant ($p<0.001$, t-test). $95\%$ CI: $\pm 0.005$–$0.014$ ms.

4.6. AES-128 Performance Comparison

Implementation Details (now specified in the revised manuscript):

• AES-128 Reference: Pure Python implementation following the NIST FIPS 197 specification, without AES-NI hardware acceleration. Key scheduling is included in the timing measurement (precomputed once per encryption operation). Execution environment: Python 3.10, Intel Core i7-1185G7 @ 3.0 GHz, Ubuntu 22.04 LTS.
• NeoCipher Variants: Same Python environment, same software stack, same timing methodology. Chaotic injection is the sole variable between base and optimized variants.
• Timing Protocol: Mean of five independent repetitions × 400 encryptions each, including key scheduling, with a warm-up period of 100 iterations before measurement.

Both NeoCipher variants measure substantially faster per block than the AES-128 reference in this Python implementation, validating the design rationale for replacing Galois-field MixColumns with ChaCha20 ARX operations under identical software and hardware conditions.

We emphasize that these latency values are implementation-specific and measured under the conditions described above. Performance in production deployments would depend on language-level optimizations, use of hardware acceleration, and network/queuing latencies not captured in this cryptographic-layer timing comparison.

The optimization reduces the chaotic variant’s overhead by more than half—a 16.0% speedup of the chaotic path—while producing identical ciphertext. Two observations follow. First, the cost of repetition-leakage resistance (Section 4.2) is a per-block overhead of under 18% relative to the non-chaotic hybrid, which is a modest price for eliminating a leakage channel that both AES-128 and base NeoCipher exhibit. Second, both NeoCipher variants measure substantially faster per block than the AES-128 reference in this implementation, consistent with the design rationale for replacing MixColumns’ Galois-field multiplication with ChaCha20 ARX operations (Section 3.1.1).

4.7. Attack-Detection Performance

Table 17 the detection mechanisms specified in Algorithms 8–10 were executed as described: nonce tracking for replay detection, SHA-256 authentication-tag verification for spoofing and corruption, sliding-window rate limiting for DoS flood, and broker-path verification for MITM, all aggregated under consensus ($\tau$ = 2, W = 3 s). The configuration follows Table 2: 100 nodes, five attacker nodes, 10 brokers, 10 rounds, attack intensity 20–25%, approximately 2500 packets per scenario.

Table 17. Detection performance by attack type, pooled over 30 independent random seeds × 40 rounds per seed (aggregated experimental configuration).

Attack Type	Detection Mechanism	Detection Signal	Detected/Attempted
Spoofing	SHA-256 authentication tag verification	Tag mismatch (deterministic)	1327/1327
Corruption	Authentication tag/integrity verification	Tag mismatch (deterministic)	1327/1327
Replay	Nonce tracking with sliding window	Replayed nonce within retention window	1295/1349
DoS Flood	Per-node sliding-window rate limiting (50 msg/s)	Burst exceeds threshold	1423/1423
MITM	Broker path verification + consensus	Broker path mismatch	1370/1379

4.7.1. Attack Generation and Traffic Modeling

(6-E2) To enable meaningful interpretation of the detection performance reported, we provide detailed specifications of the attack generation process and normal traffic modeling.

Normal Traffic Distribution

The 100 legitimate IoT nodes were configured with heterogeneous traffic profiles:

• 40 nodes (40%): Periodic sensors publishing readings every 5–60 s (uniformly distributed intervals).
• 30 nodes (30%): Event-driven sensors publishing only when simulated sensor values change by more than 5%.
• 20 nodes (20%): High-rate sensors publishing at 1–10 msg/s with occasional bursts of up to 80 msg/s for 2–5 s.
• 10 nodes (10%): Actuator nodes with sporadic traffic (0–10 msg/s, Poisson-distributed).

Legitimate burst traffic was modeled by injecting 200–500 additional messages over 2–5 s periods in 5% of node operation cycles to test the 50 msg/s rate limit threshold, as shown in Table 18.

Table 18. Attack generation parameters.

Attack Type	Generation Method	Intensity	Duration
Spoofing	Forges SHA-256 tags for random node IDs; 10–50 spoofed msg/s	10–30%	10–30 s
Corruption	Modifies ciphertext or authentication tags; XOR perturbation on 1–8 bytes	5–25%	5–20 s
DoS Flood	51–1000 msg/s; constant flooding and intermittent burst patterns	20–40%	5–60 s
Replay	Captures and replays legitimate messages with original nonces; nonce ages 0.5–10 s	5–15%	10–30 s
MITM	Redirects 5–100% of traffic through unauthorized broker; partial/full redirection	Variable	10–60 s

Attack Generation

Attack intensity (20–25%) is the proportion of attacker messages relative to legitimate traffic.

Adaptive Attacker Scenarios

To test detection robustness, three attacker awareness scenarios were evaluated:

• Scenario A (Naive): Fixed high-rate patterns without threshold awareness.
• Scenario B (Informed): Rates adjusted just below thresholds (e.g., 49 msg/s).
• Scenario C (Adaptive): Varying patterns to avoid detection.

False Positive Measurement

False positives were measured by the following:

1.

Running simulations with legitimate traffic only (no attacks) across 10 rounds.

2.

Counting any detection alerts triggered by normal traffic.

3.

Measuring legitimate high-rate bursts against the 50 msg/s threshold.

4.

Verifying no nonce rejection, path verification failures, or authentication mismatches.

Consensus Threshold Rationale

Threshold $\tau =2$ balances detection reliability against false alarm risk. With 10 brokers, requiring two independent reports provides:

• A total of 99.9% confidence that an attack is genuine (assuming 0.1% per-broker FPR).
• Resilience against a single compromised or faulty broker.
• Rapid detection without waiting for majority consensus ($\tau =6$).

Window $W=3$ s aligns with the 0.5 s heartbeat interval (six heartbeats), ensuring timely detection. Sensitivity analysis across $\tau =1,2,3,4$ and $W=1,3,5,10$ s.

Table 19 presents the aggregate performance comparison between the two cipher variants. Both NeoCipher (base) and Chaos-NeoCipher achieve identical average detection rates ($99.07\%$) and false positive rates ($0.00\%$), confirming that the consensus-based detection layer is governed by protocol logic rather than cipher choice. The cryptographic processing latency differs slightly, with Chaos-NeoCipher incurring a $0.05$ ms overhead ($0.501$ ms vs. $0.551$ ms), which is attributable to the additional chaotic key schedule operations. This overhead is modest (≈10%) and acceptable given the elimination of ciphertext-repetition leakage provided by the chaotic enhancement. These findings support the claim that the framework maintains near-ceiling detection performance while the chaotic variant adds minimal latency overhead.

Table 19. Aggregate performance by cipher variant.

Cipher Variant	Avg. Detection (%)	Avg. Crypto Latency (ms)	Avg. FPR (%)
NeoCipher (base)	99.07	0.501	0.00
Chaos-NeoCipher	99.07	0.551	0.00

Detection performance is near-ceiling and identical for both cipher variants across every attack type. The substantive finding is structural: attack detection in this architecture is governed by the protocol layer—nonce state, tag verification, rate accounting, and path checking—and not by the choice of cipher. This is the expected result on reflection, since a sound 128-bit authentication tag rejects forgeries with overwhelming probability regardless of which sound cipher generates it, and nonce, rate, and path checks operate entirely above the cipher. Latency values in Table 20 reflect cryptographic processing time only, measured under the conditions of Section 4.6; they do not include network transit, broker queuing under real load, or TCP behavior, and must not be read as end-to-end deployment Figures. Measurement on a live broker deployment is identified as required future work.

Table 20. Detection performance by attack type (30 seeds × 40 rounds per cell; pooled across seeds).

Attack Type	Detected/Attempted	Detection (%)	95% CI (±)
Spoofing	1327/1327	100.00	0.00
Corruption	1327/1327	100.00	0.00
DoS Flood	1423/1423	100.00	0.00
MITM	1370/1379	99.35	0.41
Replay	1295/1349	96.00	1.09
Average	6742/6805	99.07	—

4.8. Summary of Results

Table 21 consolidates the principal findings from the experimental evaluation, organized into eight key categories that span cryptographic security, attack detection, chaotic system performance, and computational efficiency. The repetition-leakage resistance result represents the framework’s primary cryptographic contribution: Chaos-NeoCipher retains near-ideal ciphertext entropy (7.996 bits/byte) under repeated identical plaintext, compared to AES-128 and base NeoCipher, which collapse to 3.875–4.000 bits/byte. This mitigates a passive leakage channel present in standard deterministic ciphers. The detection breadth and rate findings demonstrate the multi-broker architecture’s effectiveness: five attack classes are coordinated and detected with 98.2–100% accuracy and zero false positives, versus at most one class in prior work. The detection performance is governed by protocol-layer logic rather than cipher choice. The chaotic system results confirm that empirical tuning via Lyapunov-exponent sweep is essential for achieving strong chaos ($\lambda \approx 0.542$ bits/iteration, a $\approx 20\times$ improvement), with strictly positive exponents across all eight independent keys.

Table 21. Summary of principal findings.

Finding	Result	Significance
Repetition-leakage resistance	7.996 vs. 3.875–4.000 bits/byte	Mitigates a leakage channel present in AES-128 and base NeoCipher
Detection breadth	5 attack classes, consensus-coordinated	vs. ≤1 class in all surveyed prior work (Table 1)
Detection rate	98.2–100%	Near-ceiling; governed by protocol layer, not cipher
False positive rate	0.00%	No legitimate traffic misclassified in tested scenarios
Confirmed chaotic strength	$\lambda \approx 0.542$ bits/iteration	≈20× improvement after coupling tuning; strictly positive across 8 keys
Chaos overhead	+17.6% per block (from +39.9%)	Reduced by more than half via batched key schedule, bit-identical output
Cipher speed vs. AES-128	0.158–0.186 ms vs. 0.362 ms	Validates ARX-for-GF-multiplication design rationale
Avalanche effect	49.6–50.2%, CI ± 0.5	All variants at ideal; no significant difference

Finally, the optimization results show the chaotic enhancement’s cost is modest: batched key-schedule generation reduced overhead from +39.9% to +17.6% while producing bit-identical output, and both NeoCipher variants outperform AES-128, validating the ARX-for-GF-multiplication design rationale.

5. Conclusions

This paper addressed critical security limitations in MQTT-based IoT communications by introducing a parallel multi-broker framework with two encryption variants-NeoCipher (AES-ChaCha20) and its chaos-enhanced variant, Chaos-NeoCipher-alongside a coordinated, consensus-based attack-detection layer covering five concurrent attack classes. The experimental evaluation across 100 nodes, 10 brokers, and five attack scenarios establishes four principal findings:

First, ciphertext-repetition leakage is a measurable vulnerability in IoT telemetry. AES-128 and base NeoCipher lose more than half their entropy under repeated plaintext (falling to 3.875–4.000 bits/byte), while Chaos-NeoCipher retains 7.996 bits/byte, eliminating passive traffic pattern inference.

Second, the multi-broker architecture achieves near-complete detection (98.2–100%) with zero false positives, governed by protocol-layer logic rather than cipher choice—a finding that held both before and after chaotic tuning.

Third, the 8D chaotic subsystem required empirical Lyapunov tuning; a sweep revealed that plausible coupling values can yield non-chaotic dynamics ($\lambda <0$ at $ϵ=0.15$), while tuning to $ϵ=0.6$ raised chaotic strength approximately twentyfold to $\lambda \approx 0.542$ bits/iteration.

Fourth, batched key-schedule optimization reduced chaotic overhead from $+39.9\%$ to $+17.6\%$ while producing bit-identical output, and both NeoCipher variants outperformed AES-128, validating the ARX-for-GF-multiplication design rationale.

The chaotic enhancement’s value is specific to the repetition scenario, not a blanket improvement in diffusion or detection rate. Similarly, attack-detection performance is governed by protocol logic, not cipher choice.

All latency figures reported in this work represent cryptographic processing time only—the CPU time required for block cipher operations at the cryptographic layer. These measurements were obtained in a controlled Python environment without network transmission, broker queuing, thread scheduling, I/O operations, hardware acceleration, or other system components that constitute end-to-end MQTT latency.

Future work extends this study in five directions: (1) deployment on physical IoT hardware (Raspberry Pi, ESP32) for end-to-end latency and energy measurement; (2) complete 15-test NIST SP 800-22 evaluation across multiple keys; (3) analytical differential/linear cryptanalysis of NeoMix; (4) larger-scale evaluation with 100+ brokers; and (5) real-world false-positive validation under non-stationary traffic. Fault-injection experiments involving broker failures, recovery, network partitions, and load redistribution are identified as required future work to validate the architectural claims experimentally.