A GA-Optimised Chaotic Key as an Authentication Layer for X25519 Key Exchange on ESP32 IoT Devices

1. Introduction

The IoT devices most exposed to attack are often the ones least able to pay for strong cryptography. A sensor node has a small fraction of the memory and energy that public-key cryptography was designed around, and yet an attacker can usually reach it directly over the radio. Work on lightweight cryptography has responded in two ways: by adopting compact elliptic curves such as Curve25519 [1,2], and by looking for cheaper sources of key material, where chaotic-map generators remain an active line of research [3,4,5].

Our own work has followed the second line. A simulation study evaluated a GA-optimised logistic map for lightweight key generation in IoT systems [6], and a hardware study then ran the optimised parameters (x₀* = 0.487214, r* = 3.998721) on an ESP32 and used the resulting 256-bit key for AES-256-CBC encryption [7]. Two questions were left open. Only symmetric cryptography had been tested, and since x₀* and r* are published constants, the generator produces the same key on every device and after every boot. It therefore cannot provide the fresh per-session secret that a key exchange needs.

This paper addresses both questions with a protocol in which each mechanism is given only the task it can defend. Section 4 describes a three-layer authenticated key exchange that keeps the chaotic generator structurally apart from the elliptic-curve exchange, binds the session key to both identities through a transcript-salted HKDF, and has both parties confirm the key in-band. Section 5 and Section 6 report a hardware implementation on two ESP32 boards, with every cryptographic operation timed separately over 1,000 handshakes, and an attack evaluation of five scenarios, one of which uses wrong chaotic parameters to test the chaotic layer on its own. Along the way we found and corrected an entropy-seeding defect in wolfSSL’s Arduino-ESP32 build, and an ephemeral-key uniqueness test confirms the fix.

2. Related Work

Chaos-based key generation has been studied widely for IoT. Kifouche et al. [3] built a complete chaos-based cryptosystem for IoT communication and ran it on an ARM Cortex-M3 microcontroller. Nazish et al. [4] extend the chaotic range of the logistic map to obtain a lightweight, high-speed bit generator, and Rahman et al. [5] generate AES keys from a logistic map for a smart-home system, which is the work closest to our earlier study [7]. In each of these, the chaotic output feeds a symmetric cipher.

Other work optimises the key generator itself. Hameedi et al. [8] select chaotic-map keys with the Grey Wolf Optimizer, while Kumar and Sharma [9] apply a genetic algorithm directly to elliptic-curve key generation, so that the optimiser shapes the key pairs. We take the opposite approach and keep the chaotic generator away from the elliptic-curve secret, so that its determinism has no way to weaken forward secrecy.

Chaos has also been proposed as the basis of public-key encryption [10], but such schemes were later broken [11], so our design places its hard problem on Curve25519 [1] instead. Plain Diffie–Hellman [12] is open to man-in-the-middle attacks. The SIGMA design [13] counters this by signing the ephemeral values and adding a MAC under a derived key that binds the identities, and our protocol follows the same sign-and-MAC idea, with HKDF [14] for key derivation. Hand-optimised X25519 needs 3.59 million cycles on a Cortex-M0 [15] and 0.91 million on a Cortex-M4 [16]. Our setting is different: we use a portable library on the ESP32, which is how most IoT firmware is built. Table 1 places this work against the closest related studies.

3. System and Threat Model

Two nodes, A and B, talk to each other directly over ESP-NOW. Each node generates its own long-term Ed25519 identity key on the device. At provisioning it also receives its peer’s identity public key, exchanged once out of band and then pinned, together with the chaotic configuration (x₀, r) from which it computes K_chaos. The adversary controls the radio channel and can eavesdrop on, inject, modify, replay or drop frames. It knows the protocol and, in the configuration we evaluate, also knows the published (x₀*, r*) and therefore K_chaos. It cannot read a node’s memory during a session, although it may steal a long-term key later. The protocol has five goals: (G1) mutual authentication, (G2) session-key secrecy, (G3) forward secrecy, (G4) key confirmation and transcript agreement, and (G5) configuration binding, meaning that only nodes holding the same chaotic configuration can complete a handshake. Side channels, jamming and extraction of keys from flash are outside our scope.

4. Protocol Design

Figure 1 gives the overall architecture. Both boards run the same three layers, and every handshake frame carries something from each of them: a signature from Layer 1, an ephemeral public key from Layer 2 and a chaotic HMAC tag from Layer 3.

4.1. Chaotic Pre-Shared Key

K_chaos comes from the generator of [7], used without modification. The logistic map

x_n+1 = r · x_n · (1 − x_n) (1)

is iterated from x₀* with r* in 32-bit floating point. The first 1,000 values are discarded as transients, the next 5,000 are recorded and their mean μ is computed, and the key bits are taken as

k_i = 1 if x_i > μ, otherwise 0, i = 1, …, 256 (2)

These bits are packed most-significant bit first into 32 bytes. On the ESP32 the whole computation takes 0.322 ms at boot, and the resulting key begins with 3CFF39CA1FADD856, the same value reported in [7]. K_chaos is used only as an HMAC key and plays no part in the ephemeral keys or the session key.

4.2. Handshake

Figure 2 shows the message flow. Each node P ∈ {A, B}, identified by the label id_P, generates an ephemeral key pair (e_P, E_P) from the hardware-seeded generator and computes its Ed25519 signature [17] and chaotic tag:

σ_P = Ed25519-Sign (sk_P, “C4v2-HS” ‖ id_P ‖ E_P), τ_P = HMAC-SHA256(K_chaos, type ‖ E_P ‖ σ_P) (3)

Each handshake message is 129 bytes and fits in a single ESP-NOW frame (Table 2). The responder B first checks σ_A against A’s pinned key and then τ_A against K_chaos. If either check fails, B rejects the message; only when both pass does it generate and send its own. Both sides then compute the shared secret, erase their ephemeral private keys, hash the transcript and derive the session key:

Z = X25519(e_A, E_B) = X25519(e_B, E_A) (4)

TH = SHA-256(“C4v2-TH” ‖ M_I ‖ M_R ‖ pk_A ‖ pk_B) (5)

sk = HKDF-SHA256(IKM = Z, salt = TH, info = “C4v2 session key”, L = 32) (6)

Finally, each side sends a 33-byte confirmation c_P = HMAC-SHA256(sk, “C4v2-CF” ‖ id_P ‖ TH) and checks the one it receives in constant time. The handshake succeeds only if both confirmations verify. A complete handshake uses four frames and 324 bytes. An all-zero Z, which a low-order peer point would produce, is rejected [2], and no key material is sent at any point.

4.3. Design Rationale

Three design choices need explanation. First, in a two-message exchange the initiator cannot sign the responder’s ephemeral key, because it has not yet seen it. We therefore put both messages and both identity keys into TH, which salts HKDF and is then authenticated by the confirmation tags. This mirrors the MAC-under-a-derived-key step of SIGMA [13] and prevents identity-misbinding attacks. Second, the responder never generates keys for a sender it has not authenticated, and it checks the signature before the HMAC, so every rejection can be traced to a single layer; each hash and MAC also carries its own label for domain separation. Third, K_chaos never enters X25519 or HKDF. Even when K_chaos is known, as our threat model assumes, goals G1–G4 depend only on Ed25519, X25519 and HKDF.

5. Implementation and Methodology

Table 3 lists the platform. The firmware is built on wolfSSL [18] and Espressif’s ESP-NOW interface. The same Arduino sketch runs on both boards, a single configuration line selects the role, and each board keeps its identity key in non-volatile storage.

During bring-up, two different boards printed the same “freshly generated” Ed25519 key. The cause lay in wolfSSL’s seed routine, which tests for a generic Arduino build before it tests for ESP-IDF, so every board fell back to the unseeded C function random() instead of the hardware generator. Had this gone unnoticed, every ephemeral key would have been predictable, and forward secrecy would have been lost without any visible error. We redirected the seed (CUSTOM_RAND_GENERATE_SEED) to esp_random(), which returns hardware entropy whenever the radio is on [19], and ESP-NOW keeps the radio on. Table 4 lists this problem together with the others we met during bring-up, since anyone reproducing the work is likely to meet them too.

Each operation is timed on its own with the microsecond timer. For every trial the firmware logs all timings, both ephemeral public keys and a four-byte fingerprint of the session key (never the key itself), and all printing happens outside the timed regions. Experiment E1 consists of 1,000 honest handshakes with Board A as initiator. In Experiment E2, Board A acts as the attacker and runs 100 trials in each of five scenarios; purely for logging, the responder returns a two-byte notice giving the reason for each rejection. Since the attacker knows K_chaos, it recomputes a valid HMAC in scenarios 1 and 2, so any rejection there must come from the signature layer. In scenario 3 the HMAC is keyed with a key generated from r = 3.998722. In scenario 5 the attacker replays a recorded genuine message, whose ephemeral private key has already been erased, and then answers with a random confirmation tag. All statistics were computed offline from the raw logs, with exact Clopper–Pearson intervals.

6. Results and Discussion

6.1. Reliability and Key Uniqueness

All 1,000 handshakes in E1 completed with both confirmation tags verified (100%; 95% Clopper–Pearson interval 99.63–100%), with no timeouts and no authentication failures (Table 5). The session-key fingerprints, logged separately by each board, matched in all 1,000 trials, and the 2,000 ephemeral public keys were all distinct. This confirms the seeding fix; before it, every board produced the same key.

6.2. Per-Operation Cost

Ed25519 verification is the most expensive operation, taking 2.12 times as long as a key generation. This is expected, since verification needs a double scalar multiplication, whereas key generation, signing and the shared-secret computation each need only one [17]. The chaotic layer, by contrast, costs almost nothing: generating and checking the tag took 0.341 ms and 0.350 ms. The total handshake time is not the sum of the initiator’s operations. Board A computes for 1,818.61 ms and spends 1,471.31 ms (44.7%) waiting for Board B, which itself needs 1,464.30 ms for verification, key generation, signing and tagging before it replies; the remainder is radio latency. The small standard deviations show that the timings are repeatable, but they are not evidence of constant-time behaviour.

Table 6. Per-operation timing on the initiator (E1, N = 1,000); all values in ms.

Operation	Mean	SD	Median	Min	Max
X25519 ephemeral key generation	353.58	0.006	353.58	353.57	353.73
Ed25519 signing	361.76	0.004	361.76	361.75	361.81
Chaotic-HMAC tag generation	0.341	0.001	0.341	0.339	0.361
Wait for peer’s handshake message	1,471.31	5.02	1,470.13	1,469.11	1,543.14
Ed25519 signature verification	748.40	0.006	748.40	748.38	748.44
Chaotic-HMAC tag verification	0.350	0.001	0.349	0.348	0.352
X25519 shared secret	353.24	0.004	353.24	353.23	353.26
Transcript hash + HKDF	0.937	0.001	0.937	0.935	0.948
Key-confirmation exchange	0.667	0.002	0.667	0.662	0.672
Total handshake	3,290.79	5.02	3,289.60	3,288.58	3,362.60

Table 6. Per-operation timing on the initiator (E1, N = 1,000); all values in ms.

Operation	Mean	SD	Median	Min	Max
X25519 ephemeral key generation	353.58	0.006	353.58	353.57	353.73
Ed25519 signing	361.76	0.004	361.76	361.75	361.81
Chaotic-HMAC tag generation	0.341	0.001	0.341	0.339	0.361
Wait for peer’s handshake message	1,471.31	5.02	1,470.13	1,469.11	1,543.14
Ed25519 signature verification	748.40	0.006	748.40	748.38	748.44
Chaotic-HMAC tag verification	0.350	0.001	0.349	0.348	0.352
X25519 shared secret	353.24	0.004	353.24	353.23	353.26
Transcript hash + HKDF	0.937	0.001	0.937	0.935	0.948
Key-confirmation exchange	0.667	0.002	0.667	0.662	0.672
Total handshake	3,290.79	5.02	3,289.60	3,288.58	3,362.60

6.3. Attack Evaluation

Every one of the 500 attempts was rejected at the check the design predicts, and none was accepted. Scenarios 1 and 2 show that the signature layer on its own stops key substitution and impersonation, even when the attacker can compute valid chaotic tags. Scenario 3 tests the chaotic layer directly. Changing r by 10⁻⁶ alters 127 of the 256 key bits (49.6%), and every handshake attempted with that key was rejected even though its signature was valid. In scenarios 1–4 the rejection comes after about one signature verification, before any key material is generated. A replayed message behaves differently. It passes both the signature and the HMAC checks, so it costs the responder a full handshake (1.83 s), but the attacker cannot derive sk and always fails key confirmation.

Table 7. Attack evaluation (E2, 100 trials per scenario).

Scenario	Expected check	Rejected	At expected check	Accepted	Mean time to reject (ms)
1. Tampered ephemeral key (valid HMAC)	Signature	100	100	0	755.86
2. Impostor identity (unpinned key)	Signature	100	100	0	756.82
3. Wrong chaotic parameters (r = 3.998722)	HMAC	100	100	0	757.65
4. Tampered HMAC tag	HMAC	100	100	0	756.16
5. Replay of a recorded message	Key confirmation	100	100	0	1,828.13

Table 7. Attack evaluation (E2, 100 trials per scenario).

Scenario	Expected check	Rejected	At expected check	Accepted	Mean time to reject (ms)
1. Tampered ephemeral key (valid HMAC)	Signature	100	100	0	755.86
2. Impostor identity (unpinned key)	Signature	100	100	0	756.82
3. Wrong chaotic parameters (r = 3.998722)	HMAC	100	100	0	757.65
4. Tampered HMAC tag	HMAC	100	100	0	756.16
5. Replay of a recorded message	Key confirmation	100	100	0	1,828.13

6.4. Resource Footprint and Comparison

The values in Table 8 cover the whole firmware, including the Arduino core, the Wi-Fi stack and the 20 KB buffer of the chaotic generator, not just the cryptographic code. Even so, the handshake leaves most of the heap free. Table 9 converts our mean times into clock cycles at 240 MHz and sets them beside published microcontroller results. The large gap reflects hand-optimised assembly on one side and a portable library compiled with memory-optimised arithmetic on the other; it says little about the protocol itself.

7. Security Analysis

Our arguments rely on the unforgeability of Ed25519 [17], the Diffie–Hellman assumption on Curve25519 [1], and HMAC and HKDF behaving as pseudo-random functions [14,20]. They are informal arguments rather than a machine-checked proof. For G1, a node accepts a message only if it carries a valid signature under the peer’s pinned key over a label, the sender id and E_P, so substitution or impersonation would require a forgery, as scenarios 1 and 2 confirm. For G2 and G3, sk is derived from Z, and computing Z requires an ephemeral private key that is generated from hardware entropy, never transmitted and erased after use; stealing an identity key later therefore reveals nothing about earlier sessions. For G4, TH covers both messages and both identities, salts HKDF and is authenticated by both confirmation tags, which rules out misbinding. Because no replay cache is kept, a replayed message does pass the first checks, but it then fails key confirmation (scenario 5). Replay costs the responder time; it does not compromise a session. Table 10 links each goal to the evidence for it.

The chaotic layer (G5) needs a more careful reading. Because (x₀*, r*) are published, anyone can compute K_chaos, so in the configuration tested here the layer shows that a node holds the correct configuration, not that it holds a secret. K_chaos is also fixed by two 32-bit floating-point values, so its effective key space is far smaller than 256 bits. A real deployment should provision secret parameters for each deployment and treat the layer as configuration binding and defence in depth. None of G1–G4 depends on K_chaos being secret.

8. Limitations

This study has several limitations. We measured only wolfSSL’s memory-optimised arithmetic; the default arithmetic should be considerably faster, at the cost of more flash. All measurements used Board A as initiator, and although the firmware is symmetric, the run was not repeated with the roles swapped. The security analysis is informal, and a ProVerif or Tamarin model, or a proof in a standard key-exchange model, would strengthen it. The uniqueness test catches gross seeding failures but is not a NIST SP 800-90B entropy assessment [21]. Finally, side channels, energy per handshake, a replay window and group key agreement across many nodes were not evaluated.

9. Conclusion

This paper has shown how a GA-optimised chaotic key can take on a concrete, verifiable role in authenticated public-key key exchange without its determinism ever touching the session secret. The protocol combines Ed25519 identities, hardware-seeded X25519 with a transcript-bound HKDF key schedule and key confirmation, and an HMAC keyed by the unmodified chaotic generator. On two ESP32 boards, all 1,000 handshakes reached confirmed key agreement in 3,290.79 ms on average, all ephemeral keys were distinct, and all 500 attacks were rejected, including every attempt with chaotic parameters off by 10⁻⁶. The chaotic layer cost 0.69 ms per handshake. We also found and corrected an entropy-seeding defect in wolfSSL’s Arduino-ESP32 build that would otherwise have silently undermined forward secrecy.

Data availability: The firmware, analysis scripts and raw serial logs are available from the corresponding author on reasonable request.