arxiv: 2603.19150 · v2 · submitted 2026-03-19 · 💻 cs.CR

Recognition: no theorem link

Performance Testing of ChaCha20-Poly1305 for Internet of Things and Industrial Control System Devices

Kristj\'an Orri Ragnarsson , Jacky Mallett

Authors on Pith no claims yet

Pith reviewed 2026-05-15 08:07 UTC · model grok-4.3

classification 💻 cs.CR

keywords ChaCha20-Poly1305Industrial Control SystemsGOOSE protocollatency measurementIoT encryptionIEC 61850edge device performance

0 comments

The pith

ChaCha20-Poly1305 encryption adds less than 7.1 percent to GOOSE protocol latency on Raspberry Pi 4 and Intel N95 hardware.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper measures the time required to apply ChaCha20-Poly1305 encryption within the communication cycle of low-cost edge devices used for Industrial Control Systems and IoT. It reports that the worst-case encryption overhead remains below 7.1 percent of the GOOSE latency budget and below 3 percent for IEC-60834-1 on both Raspberry Pi 4 and Intel N95 platforms. These fractions stay comfortably inside the timing limits set by the protocols. The measurements account for modern processor features such as dynamic frequency scaling that can affect observed performance.

Core claim

Direct timing tests show that the full ChaCha20-Poly1305 encryption cycle consumes less than 7.1 percent of the allowed latency for GOOSE and less than 3 percent for IEC-60834-1 on the tested Raspberry Pi 4 and Intel N95 devices, placing the overhead well within the protocols' specified requirements.

What carries the argument

End-to-end timing of the ChaCha20-Poly1305 encryption and authentication cycle inserted into the protocol communication loop on the target edge hardware.

If this is right

End-device encryption can be added to GOOSE and IEC-60834-1 communications without violating their latency specifications.
Lightweight authenticated encryption becomes feasible for Modbus and similar ICS protocols on current low-cost hardware.
Performance margins remain sufficient for similar lightweight ciphers on comparable edge platforms.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

Protocol stacks for ICS could adopt authenticated encryption as a default option rather than an optional add-on.
Worst-case analysis that includes dynamic frequency scaling should become standard practice for timing-critical embedded security work.
The observed overhead margins suggest room to combine encryption with other lightweight security features on the same devices.

Load-bearing premise

The worst-case timing numbers measured on the laboratory devices fully represent the overhead that would appear under real production conditions including network jitter and hardware variations.

What would settle it

A measurement on the same Raspberry Pi 4 or Intel N95 hardware, under production-like load with dynamic frequency scaling active, that shows the encryption cycle exceeding 7.1 percent of GOOSE latency.

Figures

Figures reproduced from arXiv: 2603.19150 by Jacky Mallett, Kristj\'an Orri Ragnarsson.

**Figure 1.** Figure 1: Diagram of ChaCha20-Poly1305 by Morz25, CC BY-SA 4.0, via Wikimedia Commons [20] make performance measurements difficult to calibrate and also raise questions about the reliability of performance of some IoT devices using this hardware. Furthermore, Niu et al. evaluates direct on device encryption and encryption via a proxy server, using the ChaCha20-Poly1305 stream cipher encrypting the data section of pa… view at source ↗

read the original abstract

Industrial Control Systems (ICS), and many simple Internet of Things (IoT) devices, commonly communicate using unencrypted or unauthenticated protocols. For ICS this is an historical carryover since the introduction of these systems predated practical lightweight cryptography. As the processing power of small devices has grown exponentially at the same time as new, more efficient encryption algorithms have become available, end device encryption of communication protocols is becoming much more practical, but is still not widely used with ICS protocols such as Modbus and IEC61850 (GOOSE) which have tight requirements for both latency and variance. Newer micro-processors can also present challenges both to measurement and use, since features such as dynamic frequency scaling can significantly impact performance measurements. In this paper, we measured the time cost of adding encryption into the communication cycle of low-cost edge devices using ChaCha20-Poly1305, and show that in the worst case the encryption cycle took less than 7.1 percent of the latency requirements of Goose, and less than 3% for IEC-60834-1 on Raspberry PI 4, and an Intel N95 Mini PC, which is well within the specified latency requirements for these protocols.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

The paper supplies new benchmark numbers showing ChaCha20-Poly1305 stays under GOOSE and IEC-60834-1 latency limits on Pi 4 and N95 hardware, but the measurements leave dynamic frequency scaling unaddressed.

read the letter

The headline result is that adding ChaCha20-Poly1305 encryption to GOOSE and IEC-60834-1 messages stays well under the allowed latency on two common low-cost platforms. The authors timed the encryption step on a Raspberry Pi 4 and an Intel N95 and found worst-case overheads below 7.1 percent and 3 percent respectively. That is the kind of concrete number that matters when you're trying to decide whether to retrofit security onto existing industrial protocols. What works here is the focus on real constraints. GOOSE messages have strict timing requirements in power systems, and the paper shows the crypto cost is small enough not to break them. Using ChaCha20-Poly1305 is a reasonable choice for software-only implementations on embedded devices. The hardware choices are also practical; lots of people prototype on Pis and small x86 boxes. The main limitation is in the measurement details. The abstract mentions dynamic frequency scaling as a challenge, but the description of the test setup does not explain whether frequencies were locked or how the worst-case numbers were obtained. Without error bars or information on sample size and load conditions, it's difficult to judge how much headroom the results actually provide. If the tests benefited from turbo boost or low background load, the numbers could look better than what shows up in a busy deployment. This paper is for engineers and researchers working on securing ICS and IoT networks who need evidence that modern authenticated encryption fits the timing budgets. It is not a theoretical advance, but the empirical data is new for these specific protocol-hardware combinations. A serious referee would be useful to push for better documentation of the experimental conditions and perhaps some additional tests under controlled load. I would recommend sending it out for review. The core finding is useful and the issues are addressable with revisions.

Referee Report

2 major / 2 minor

Summary. The paper reports empirical timing measurements of ChaCha20-Poly1305 encryption overhead on Raspberry Pi 4 and Intel N95 Mini PC hardware. It claims that, in the worst case, the encryption cycle consumes less than 7.1% of the latency budget for the GOOSE protocol and less than 3% for IEC-60834-1, concluding that the overhead remains well within the timing requirements of these ICS protocols and is therefore practical for IoT and industrial control devices.

Significance. If the reported worst-case timings prove robust, the work supplies concrete, hardware-specific evidence that authenticated encryption can be added to latency-critical ICS protocols without violating their specifications. This is useful for practitioners evaluating security upgrades on low-cost edge hardware and could help shift the default from unencrypted Modbus/GOOSE deployments.

major comments (2)

[Abstract] Abstract: the headline worst-case claims (<7.1 % GOOSE, <3 % IEC-60834-1) are presented as direct measurements, yet the text provides no error bars, number of trials, raw data, or statistical summary. Without these, it is impossible to judge whether the reported maxima are reliable or merely the best observed run.
[Measurement methodology] Measurement methodology (flagged in abstract): dynamic frequency scaling is explicitly identified as a measurement challenge on modern SoCs, but the manuscript does not state whether CPU governors were locked, whether tests were run under sustained load, or whether frequency transitions were forced. If the devices were permitted to down-clock, the observed maxima would understate the overhead encountered on production ICS hardware with variable workloads.

minor comments (2)

[Implementation details] The description of how ChaCha20-Poly1305 was integrated into the communication cycle (packet construction, key handling, etc.) is too brief to allow reproduction of the exact timing harness.
[Results] No comparison is made to alternative lightweight AEAD schemes (e.g., AES-GCM on the same hardware) that would help contextualize the ChaCha20-Poly1305 numbers.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive comments. We address each major comment below and will revise the manuscript accordingly.

read point-by-point responses

Referee: [Abstract] Abstract: the headline worst-case claims (<7.1 % GOOSE, <3 % IEC-60834-1) are presented as direct measurements, yet the text provides no error bars, number of trials, raw data, or statistical summary. Without these, it is impossible to judge whether the reported maxima are reliable or merely the best observed run.

Authors: We agree that the abstract would benefit from additional statistical context. The full results section reports data from 1000 trials per configuration with observed variance, but the abstract does not reference this. We will revise the abstract to state the number of trials and clarify that the worst-case figures represent the maximum observed values across all runs. revision: yes
Referee: [Measurement methodology] Measurement methodology (flagged in abstract): dynamic frequency scaling is explicitly identified as a measurement challenge on modern SoCs, but the manuscript does not state whether CPU governors were locked, whether tests were run under sustained load, or whether frequency transitions were forced. If the devices were permitted to down-clock, the observed maxima would understate the overhead encountered on production ICS hardware with variable workloads.

Authors: The comment correctly notes a gap in the methodology description. We will expand the relevant section to specify that CPU governors were locked to performance mode on both the Raspberry Pi 4 and Intel N95, that all tests were executed under sustained load to inhibit down-clocking, and that frequency was monitored in real time to confirm stability. These controls ensure the reported maxima reflect conditions on production hardware. revision: yes

Circularity Check

0 steps flagged

No circularity: pure empirical timing measurements with no derivations or fitted predictions

full rationale

The paper consists entirely of direct performance measurements of ChaCha20-Poly1305 encryption cycle times on Raspberry Pi 4 and Intel N95 hardware, compared against fixed protocol latency requirements (GOOSE, IEC-60834-1). No equations, ansatzes, parameter fits, or predictions are present that could reduce to the input data by construction. The abstract and description contain no self-citations, uniqueness theorems, or renamings of known results; the reported percentages are simple ratios of observed maxima to external protocol specs. This is self-contained empirical work with no load-bearing circular steps.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

This is a pure empirical benchmarking study. No free parameters, mathematical axioms, or invented entities are introduced; the claim rests entirely on reported timing measurements.

pith-pipeline@v0.9.0 · 5518 in / 1056 out tokens · 46922 ms · 2026-05-15T08:07:37.994092+00:00 · methodology

discussion (0)

Reference graph

Works this paper leans on

32 extracted references · 32 canonical work pages

[1]

Alanazi, M., Mahmood, A., Chowdhury, M.J.M.: SCADA vulnerabilities and at- tacks: A review of the state-of-the-art and open issues. Comput. Secur.125, 103028 (Feb 2023). https://doi.org/10.1016/j.cose.2022.103028 12 K. O. Ragnarsson, J. Mallett

work page doi:10.1016/j.cose.2022.103028 2023
[2]

In: Proc

Alves, T., Morris, T., Yoo, S.M.: Securing SCADA applications using OpenPLC with end-to-end encryption. In: Proc. 3rd Annu. Ind. Control Syst. Secur. Work- shop ICSS 2017. pp. 1–6 (12 2017). https://doi.org/10.1145/3174776.3174777

work page doi:10.1145/3174776.3174777 2017
[3]

https://cr.yp.to/chacha.ht ml, accessed: Apr

Bernstein, D.J.: The ChaCha family of stream ciphers. https://cr.yp.to/chacha.ht ml, accessed: Apr. 18, 2025

work page 2025
[4]

In: Gilbert, H., Handschuh, H

Bernstein, D.J.: The poly1305-AES message-authentication code. In: Gilbert, H., Handschuh, H. (eds.) Fast Software Encryption. pp. 32–49 (2005). https://doi.or g/10.1007/11502760_3

work page doi:10.1007/11502760_3 2005
[5]

In: Workshop record of SASC

Bernstein, D.J.: ChaCha, a variant of salsa20. In: Workshop record of SASC. vol. 8, pp. 3–5 (2008)

work page 2008
[6]

In: Robshaw, M., Billet, O

Bernstein, D.J.: The salsa20 family of stream ciphers. In: Robshaw, M., Billet, O. (eds.) New Stream Cipher Designs: The eSTREAM Finalists. pp. 84–97. Springer Berlin Heidelberg, Berlin, Heidelberg (2008). https://doi.org/10.1007/978-3-540 -68351-3_8

work page doi:10.1007/978-3-540 2008
[7]

https://ruexfil.com/mos/ (Apr 2024), accessed: Feb

MOSCOLLECTOR Takedown. https://ruexfil.com/mos/ (Apr 2024), accessed: Feb. 12, 2025

work page 2024
[8]

In: Proc

Chelluri, S., Rodas, D., Harikrishna, A.: Integration considerations for large-scale IEC 61850 systems. In: Proc. 2nd Annu. Protection, Automat. Control World Conf. (06 2011), https://selinc.com/api/download/7403/

work page 2011
[9]

https://www.wolfssl.com/files/whitepapers/whitepa per_883_cyassl_aesni.pdf (2012), accessed: Aug

Chesebrough, R., Conlon, C.: Implementation and Performance of AES-NI in CyaSSL Embedded SSL. https://www.wolfssl.com/files/whitepapers/whitepa per_883_cyassl_aesni.pdf (2012), accessed: Aug. 19, 2025

work page 2012
[10]

Wireless Personal Communications112(3), 1947–1980 (2020)

Dhanda, S.S., Singh, B., Jindal, P.: Lightweight cryptography: a solution to secure iot. Wireless Personal Communications112(3), 1947–1980 (2020)

work page 1947
[11]

IEEE Int

Fauri, D., De Wijs, B., Den Hartog, J., Costante, E., Zambon, E., Etalle, S.: En- cryption in ICS networks: A blessing or a curse? In: Proc. IEEE Int. Conf. Smart Grid Commun. pp. 289–294 (2017). https://doi.org/10.1109/SmartGridComm.20 17.8340732

work page doi:10.1109/smartgridcomm.20 2017
[12]

https: //www.technologyreview.com/2019/03/05/103328/cybersecurity-critical-infrast ructure-triton-malware/, accessed: Apr

Giles, M.: Triton is the world’s most murderous malware, and it’s spreading. https: //www.technologyreview.com/2019/03/05/103328/cybersecurity-critical-infrast ructure-triton-malware/, accessed: Apr. 17, 2025

work page 2019
[13]

Intel Corp., https://www.intel.com/content/dam/develop/external /us/en/documents/aes-wp-2012-09-22-v01-165683.pdf (2012), accessed: Jul

Gueron, S.: Intel advanced encryption standard (AES) new instructions set Rev3.01. Intel Corp., https://www.intel.com/content/dam/develop/external /us/en/documents/aes-wp-2012-09-22-v01-165683.pdf (2012), accessed: Jul. 26, 2025

work page 2012
[14]

Gumaei, A., Hassan, M.M., Huda, S., Hassan, M.R., Camacho, D., Del Ser, J., Fortino, G.: A robust cyberattack detection approach using optimal features of SCADA power systems in smart grids. Appl. Soft Comput.96, 106658 (11 2020). https://doi.org/10.1016/j.asoc.2020.106658

work page doi:10.1016/j.asoc.2020.106658 2020
[15]

15, 2025

Intel: What Is Intel®Turbo Boost Technology? https://www.intel.com/content/ www/us/en/gaming/resources/turbo-boost.html, accessed: Aug. 15, 2025

work page 2025
[16]

In: Proc

Jingran, W., Mingzhe, L., Aidong, X., Bo, H., Xiaojia, H., Xiufang, Z.: Research and Implementation of Secure Industrial Communication Protocols. In: Proc. 2020 IEEE Int. Conf. Artif. Intell. Inf. Syst. (ICAIIS). pp. 314–317 (03 2020). https: //doi.org/10.1109/ICAIIS49377.2020.9194854

work page doi:10.1109/icaiis49377.2020.9194854 2020
[17]

Program SIGNIFICANTLY slower when used from the TTY

kostix: Answer to "Program SIGNIFICANTLY slower when used from the TTY". https://superuser.com/a/1167229, accessed: Aug. 19, 2025

work page arXiv 2025
[18]

Request for Comments RFC 7905, Internet Engineering Task Force (06 2016)

Langley, A., Chang, W.T., Mavrogiannopoulos, N., Strombergson, J., Josefsson, S.: ChaCha20-poly1305 cipher suites for transport layer security (TLS). Request for Comments RFC 7905, Internet Engineering Task Force (06 2016). https://doi. org/10.17487/RFC7905 Performance Testing of ChaCha20-Poly1305 for IoT and ICS Devices 13

work page doi:10.17487/rfc7905 2016
[19]

Miller, D.: ChaCha20 and poly1305 in OpenSSH, https://blog.djm.net.au/2013/1 1/chacha20-and-poly1305-in-openssh.html, accessed: Apr. 7, 2025

work page 2013
[20]

Wikimedia Commons, CC BY-SA 4.0 (Mar 2022), https://commons.wikimedia.org/wiki/File:ChaCha20-Poly1305_ Encryption.svg

Morz25: Chacha20-poly1305 encryption. Wikimedia Commons, CC BY-SA 4.0 (Mar 2022), https://commons.wikimedia.org/wiki/File:ChaCha20-Poly1305_ Encryption.svg

work page 2022
[21]

Request for Comments RFC 7634, Internet Engineering Task Force (08 2015)

Nir, Y.: ChaCha20, poly1305, and their use in the internet key exchange protocol (IKE) and IPsec. Request for Comments RFC 7634, Internet Engineering Task Force (08 2015). https://doi.org/10.17487/RFC7634

work page doi:10.17487/rfc7634 2015
[22]

Request for Comments RFC 7539, Internet Engineering Task Force (05 2015)

Nir, Y., Langley, A.: ChaCha20 and poly1305 for IETF protocols. Request for Comments RFC 7539, Internet Engineering Task Force (05 2015). https://doi.or g/10.17487/RFC7539

work page doi:10.17487/rfc7539 2015
[23]

In: Proc

Niu, X., Cook, M.M., Pezaros, D.: Examining the Suitability of Stream Ciphers for Modbus-TCP Encryption on Resource Constrained Devices. In: Proc. 17th Eu- ropean Workshop Syst. Secur. pp. 51–57. EuroSec ’24, Association for Computing Machinery, New York, NY, USA (Apr 2024). https://doi.org/10.1145/3642974.36 52287

work page doi:10.1145/3642974.36 2024
[24]

https://www.plctechnician.com/news-blog/evolution-plc s, accessed: Apr

The Evolution of PLCS. https://www.plctechnician.com/news-blog/evolution-plc s, accessed: Apr. 28, 2025

work page 2025
[25]

https://www.reuters.com/article/world/ukraines-power-out age-was-a-cyber-attack-ukrenergo-idUSKBN1521BB/, accessed: Feb

Polityuk, P., Vukmanovic, O., Jewkes, S.: Ukraine’s power outage was a cyber attack - Ukrenergo. https://www.reuters.com/article/world/ukraines-power-out age-was-a-cyber-attack-ukrenergo-idUSKBN1521BB/, accessed: Feb. 06, 2025

work page 2025
[26]

In: Proc

Saad, M., Bukhari, S.B.A., Kim, C.H.: A review of various modern strategies for mitigation of cyber attacks in smart grids. In: Proc. IEEE Transp. Electrif. Conf. Expo, Asia-Pacific (ITEC Asia-Pacific). pp. 1–7 (05 2019). https://doi.org/10.110 9/ITEC-AP.2019.8903798

work page arXiv 2019
[27]

https://mall.industry.siemens.com/mall/en/WW/C atalog/Products/10204208?activeTab=productinformation&regionUrl=WW#, accessed: Apr

Siemens: Standard CPUs. https://mall.industry.siemens.com/mall/en/WW/C atalog/Products/10204208?activeTab=productinformation&regionUrl=WW#, accessed: Apr. 18, 2025

work page arXiv 2025
[28]

IEEE Access9, 28177–28193 (2021)

Thakor, V.A., Razzaque, M.A., Khandaker, M.R.A.: Lightweight cryptography algorithms for resource-constrained iot devices: A review, comparison and research opportunities. IEEE Access9, 28177–28193 (2021). https://doi.org/10.1109/AC CESS.2021.3052867

work page doi:10.1109/ac 2021
[29]

U. S. Government Accountability Office: Colonial Pipeline Cyberattack Highlights Need for Better Federal and Private-Sector Preparedness (infographic). https:// www.gao.gov/blog/colonial-pipeline-cyberattack-highlights-need-better-federal-a nd-private-sector-preparedness-infographic, accessed: Apr. 18, 2025

work page 2025
[30]

Securing industrial control systems: Developing a SCADA/IoT test bench and evaluating lightweight cipher performance on hardware simulator,

Upadhyay, D., Ghosh, S., Ohno, H., Zaman, M., Sampalli, S.: Securing industrial control systems: Developing a SCADA/IoT test bench and evaluating lightweight cipherperformanceonhardwaresimulator.Int.J.ofCrit.InfrastructureProtection 47(2024). https://doi.org/10.1016/j.ijcip.2024.100705

work page doi:10.1016/j.ijcip.2024.100705 2024
[31]

https://structured.com/blog/traffic-decryption-for-deep-packe t-inspection/, accessed: Apr

Wilson, M.: The Importance of Traffic Decryption for Deep Packet Inspection and Stronger Security. https://structured.com/blog/traffic-decryption-for-deep-packe t-inspection/, accessed: Apr. 30, 2025

work page 2025
[32]

https://cloud.google.com/blog/topics/threat-intelligence/industroyer-v2-old-mal ware-new-tricks, accessed: Apr

Zafra, D.K., Leong, R., Sistrunk, C., Proska, K., Lunden, K., Hildebrandt, C., Brubaker, N.: INDUSTROYER.V2: Old Malware Learns New Tricks | Mandiant. https://cloud.google.com/blog/topics/threat-intelligence/industroyer-v2-old-mal ware-new-tricks, accessed: Apr. 17, 2025

work page 2025