HELO Cryptography: A Lightweight Cryptographic System for Enhancing IoT Security in P2P Data Transmission

Source: arXiv:2605.03948 · Published 2026-05-05 · By Tahsin Ahmed, Arjita Saha, Arian Nuhan, Nafim Ahmed Bin Mohammad Noor, Md Faisal Ahmed, Muhammad Iqbal Hossain

TL;DR

This paper addresses the critical challenge of securing resource-constrained IoT devices during peer-to-peer (P2P) data transmission. Traditional cryptographic algorithms such as AES and RSA demand considerable computational power and energy, making them unsuitable for lightweight IoT devices that often have limited CPU, memory, and power availability. The authors present HELO (Hybrid Encryption Lightweight Optimization), a novel cryptographic system designed specifically for IoT environments. HELO integrates multiple cryptographic primitives—including Elliptic Curve Cryptography (ECC) based key exchange (ECDH), ChaCha20 stream cipher for encryption, Poly1305 for message authentication, and ECDSA for digital signatures—while implementing chunked data processing and multithreading to improve efficiency and scalability on constrained hardware.

HELO’s key contributions center on hybridizing cryptographic mechanisms to achieve end-to-end confidentiality, integrity, authenticity, and availability without degrading performance. The system minimizes computational overhead by chunking data for partial encryption and decryption, reducing RAM and CPU consumption. The authors demonstrate strong security properties by using SHA3-256 based key derivation functions and robust signature validation. Experimental evaluation on standard datasets in a simulated desktop environment shows improved processing speeds, reduced latency, and lower power consumption compared to baseline approaches, though detailed comparative numerical results are not fully provided. The open-source implementation and web interface enable verification and further development by practitioners.

Ultimately, HELO proposes a comprehensive lightweight cryptographic framework offering strong protection and operational efficiency tailored to real-world P2P IoT data transmission, addressing essential security needs in devices with limited computational budgets.

Key findings

• HELO employs SECP256R1 curve for ECC key pairs and uses ECDH with SHA3-256 for secure key derivation, generating 256-bit derived keys.
• Chunked data processing allows partial encryption/decryption, improving fault tolerance and reducing CPU overhead by handling data segments independently.
• ChaCha20 stream cipher combined with Poly1305 MAC secures confidentiality and integrity; ciphertext size increases by only 32 bytes (16-byte nonce + 16-byte tag) over plaintext size.
• Message authenticity is verified using ECDSA signatures on plaintext with SHA3-256 digest, early terminating decryption if signature validation fails.
• Multithreading via ThreadPoolExecutor drastically improves encryption/decryption throughput by parallelizing operations on multiple files.
• Implemented on an Intel i5-9600K desktop as a proof-of-concept, HELO shows potential for IoT devices but lacks direct embedded hardware benchmarking.
• Data sets used include small text files from Kaggle capturing real IoT-like data patterns (file sizes from 15 bytes to ~1 KB), representative of constrained environments.
• The total encrypted file size is plaintext chunk size plus 32 bytes overhead, ensuring lightweight ciphertext growth suitable for bandwidth-limited IoT networks.

Threat model

The adversary is a network attacker capable of passive eavesdropping and active tampering of P2P communications between IoT nodes, including replay, message injection, and modification attempts. They do not have access to the private keys of the communicating parties and cannot break the discrete logarithm problem underlying ECC. Hardware-level attacks such as physical tampering, side-channel, or fault injection are out of scope. The adversary seeks to compromise confidentiality, integrity, and authenticity of transmitted data but cannot break strong cryptographic primitives assumed secure.

Methodology — deep read

1. Threat Model & Assumptions: HELO assumes an adversary capable of passive eavesdropping and active message tampering on P2P communications between IoT devices. Attack vectors include cryptanalysis, replay attacks, forgery, and unauthorized access. The adversary cannot break ECC discrete logarithm assumptions or forge digital signatures without private keys. The model aims to resist key compromise, MITM attacks, message injection, and ensures confidentiality, integrity, and authenticity.

2. Data: The authors evaluate on several small text datasets sourced from Kaggle representing IoT data communication patterns, such as random 3D shapes files, YOLO format TACO dataset, Python package requirement lists, and multilingual translations ranging from 15 bytes to 1 KB. Data is used in plaintext form for encryption experiments. Although run on a desktop PC, these datasets are intended to simulate constrained IoT workloads.

3. Architecture/Algorithm: HELO integrates seven key mechanisms: ECC key pair generation (using SECP256R1), ECDH key exchange with HKDF and SHA3-256 for shared key derivation, chunk size initialization for partial data processing, ChaCha20 stream cipher for encryption with a 16-byte nonce, Poly1305 MAC for message authentication, ECDSA digital signature for sender authenticity, and multithreading to parallelize workload. The workflow starts with chunking the plaintext, signing it, generating tokens (nonce), encrypting chunks with ChaCha20, appending MAC tags, then transmitting encrypted files. On reception, tags and signatures are verified before final decryption.

4. Training Regime: Not applicable for this cryptography system.

5. Evaluation Protocol: Experimental evaluation involves measuring encryption and decryption runtime, resource usage, and security properties on a Windows 11 PC with a 6-core Intel i5 @ 3.7 GHz and 16 GB RAM. Metrics include computational overhead, latency, ciphertext size overhead (+32 bytes), and correctness via signature and MAC verification. The system performance is benchmarked using various small real-world IoT datasets but lacks explicit baseline overhead numbers or attack simulations. No cross-validation or statistical tests are reported.

6. Reproducibility: The source code is open sourced on GitHub (https://github.com/tahsinnahmed/HELO-Cryptography.git) and a demo web app is provided. However, the evaluation uses desktop-grade hardware rather than actual embedded IoT devices, limiting direct applicability of runtime results. The dataset is publicly accessible from Kaggle repositories mentioned but exact splits or preprocessing details are not fully outlined.

Concrete Example: To encrypt a file, HELO first initializes chunk size per user. It generates ECC private/public keys using SECP256R1 and establishes a shared secret key via ECDH with SHA3-256 HKDF. The plaintext is chunked, each chunk is signed with ECDSA using the sender’s private key, then encrypted using the ChaCha20 cipher initialized with the nonce and the derived key. A Poly1305 MAC tag authenticates each ciphertext chunk. Encrypted chunks, tags, and nonce are concatenated and stored. Multithreading permits parallel encryption on multiple files. At the receiver, tags and digital signatures are verified before decrypting each chunk, ensuring integrity and authenticity before releasing the plaintext.

Technical innovations

• Hybrid combination of ECC-based key exchange (ECDH), ChaCha20 encryption, Poly1305 authentication, and ECDSA signing optimized together for lightweight IoT usage.
• Chunked data processing enabling partial encryption/decryption to reduce buffering, CPU overhead, and improve fault tolerance in IoT constrained devices.
• Use of multithreading to parallelize encryption/decryption workloads on constrained hardware for improved throughput and reduced latency.
• Platform independent lightweight cryptographic framework designed to avoid cache-timing and side-channel vulnerabilities inherent in some traditional algorithms like AES.

Datasets

• 1k Random 3D Shapes — 15 Bytes — Kaggle
• TACO Dataset YOLO Format README — 118 Bytes — Kaggle
• TF 2.16 Requirements Python package list — 171 Bytes — Kaggle
• English to French Translations — 1 Kilobyte — Kaggle

Baselines vs proposed

• AES runtime on Contiki using Cooja simulator (from related work): slower and more energy consuming vs HELO's ChaCha20 stream cipher with chunked processing (quantitative delta not fully reported).
• Hybrid AES Rail Fence (HAR) compared to AES showed higher avalanche effect but with known Rail Fence weaknesses—HELO claims stronger security via hybrid ECC-ChaCha20-Poly1305 but no direct numeric comparison provided.
• RSA and Diffie-Hellman hybrid showed increased encryption/decryption time compared to RSA alone—HELO improves over RSA by replacing RSA with ECC-based lightweight primitives.
• HELO encrypted file size overhead = plaintext size + 32 bytes (nonce + tag), representing minimal communication overhead vs AES-GCM or other authenticated encryption schemes.

Limitations

• Evaluation performed only on a desktop environment, no testing on actual resource-constrained IoT hardware such as Raspberry Pi or microcontrollers.
• Energy consumption measured through estimates rather than direct hardware power profiling, limiting claims on battery efficiency.
• No adversarial testing or formal cryptanalysis presented; resilience against advanced side-channel or fault injection attacks remains unverified.
• No benchmarking against established lightweight cryptographic standards or frameworks (e.g., NIST lightweight crypto candidates) with quantitative metrics.
• Chunk size selection is user-dependent, but no guidelines provided on optimal trade-offs between security, performance, and memory usage.
• Limited dataset sizes and variety used in experiments, raising questions on generalization to large-scale or high-throughput IoT applications.

Open questions / follow-ons

• How does HELO perform in real embedded IoT devices with constrained CPU and memory? Actual hardware benchmarks are needed.
• What are the system’s resistance levels against specific advanced attacks such as side-channel, fault injection, or MITM in IoT environments?
• How does chunk size impact performance and security trade-offs in various real-world IoT scenarios?
• Can automated key management and rekeying protocols be integrated to support large deployments securely?

Why it matters for bot defense

For bot-defense and CAPTCHA practitioners, HELO introduces a comprehensive lightweight cryptographic scheme tailored to IoT peer-to-peer communications. While HELO does not directly address bot detection or CAPTCHA design, its approach to lightweight, hybrid cryptography and chunked encrypted messaging can inform secure, low-latency data exchanges in IoT-driven bot defense architectures. The multithreaded design suggests avenues for scaling cryptographic workloads efficiently in large distributed IoT sensor networks where bot command and control communications must be intercepted or authenticated. The strong focus on integrity and authenticity verification (via Poly1305 MAC and ECDSA) provides templates for ensuring tamper-resistant interactions even on constrained devices. However, since HELO’s security evaluation lacks adversarial robustness testing and embedded device benchmarks, CAPTCHA engineers should consider these gaps and validate the approach further before deployment in bot mitigation contexts, especially where real-time performance under attack is critical.

Cite

@article{arxiv2605_03948,
  title={ HELO Cryptography: A Lightweight Cryptographic System for Enhancing IoT Security in P2P Data Transmission },
  author={ Tahsin Ahmed and Arjita Saha and Arian Nuhan and Nafim Ahmed Bin Mohammad Noor and Md Faisal Ahmed and Muhammad Iqbal Hossain },
  journal={arXiv preprint arXiv:2605.03948},
  year={ 2026 },
  url={https://arxiv.org/abs/2605.03948}
}

Read the full paper

• arXiv:2605.03948 (abstract)
• arXiv:2605.03948 (PDF)