AmphiKey: Hybrid PQ/T Key Exchange

• AmphiKey is a dual-mode authenticated key exchange protocol combining ephemeral ML-KEM-768 and X25519 for smart-grid communications.
• It offers two modes: an auditable Authenticated Mode with Raccoon signatures and a privacy-preserving Deniable Mode using HMAC-based authentication.
• The protocol mitigates classical threats and future quantum attacks while addressing performance and side-channel considerations in heterogeneous, resource-constrained smart-grid environments.

AmphiKey is a dual-mode post-quantum/traditional (PQ/T) hybrid authenticated key exchange mechanism for smart-grid communications that combines ephemeral ML-KEM-768 and X25519 within a single framework offering two operational modes: an Authenticated Mode and a Deniable Mode. Its stated purpose is to secure smart-grid channels against classical threats such as eavesdropping, man-in-the-middle attacks, and message alteration/injection, while also addressing future quantum attacks, uncertainty about new post-quantum primitives, heterogeneous endpoint capabilities, and side-channel exposure in physically accessible field devices. The protocol’s defining feature is that it separates confidentiality from authentication semantics: the hybrid KEM core is shared across both modes, while the authentication layer is either publicly verifiable and non-repudiable or deniable and lightweight, depending on deployment requirements (Shakib et al., 1 Sep 2025).

1. Smart-grid setting and design rationale

AmphiKey is motivated by the heterogeneity of smart-grid infrastructure. The deployment model described in the paper spans SCADA-to-substation links, smart meters, EV chargers, PMUs, and other grid-edge devices. Within that environment, some exchanges require auditable, non-repudiable authentication, while others benefit from privacy-preserving and lower-overhead authentication. The protocol therefore does not treat authenticated key establishment as a single uniform primitive, but as a framework with two security semantics selected according to operational need (Shakib et al., 1 Sep 2025).

The threat model includes both active network adversaries and future quantum-capable adversaries. Classical threats explicitly listed are eavesdropping, man-in-the-middle attacks, message alteration/injection, and denial of service. The post-quantum motivation is the expected failure of RSA/ECC against large quantum computers and the associated store-now-decrypt-later risk for long-lived infrastructure. At the same time, the paper argues against a PQ-only design because post-quantum schemes are newer and may yet reveal cryptanalytic or implementation weaknesses. This leads to the hybrid rationale: ML-KEM-768 supplies the post-quantum confidentiality component, while X25519 supplies the traditional component, yielding what the paper calls “OR” confidentiality.

A further design axis is implementation realism. The paper repeatedly emphasizes resource-constrained endpoints, limited CPU and memory budgets, and physical accessibility of field devices. This is why the protocol couples a lightweight deniable mode with a heavier authenticated mode and why it selects a masking-friendly signature scheme rather than optimizing only for signature size or raw throughput. A plausible implication is that AmphiKey is intended less as a general-purpose internet AKE than as a deployment-specific smart-grid construction in which authentication semantics, device asymmetry, and side-channel posture are first-order concerns.

2. Dual-mode protocol organization

The overall architecture is a black-box combiner. In both modes, one shared secret is derived from a post-quantum KEM component and another from a classical KEM/DH component, after which hashing or HKDF combines them into a session key. The distinction between the modes is entirely in the authentication layer: Authenticated Mode signs the hybrid ciphertext transcript with a long-term Raccoon key, whereas Deniable Mode authenticates the ciphertext with an HMAC derived from ephemeral shared secrets (Shakib et al., 1 Sep 2025).

Mode	Authentication mechanism	Stated properties
Authenticated Mode	Raccoon signature on ciphertext transcript	forward secrecy, strong, non-repudiable authenticity
Deniable Mode	HMAC tag derived from ephemeral KEM outputs	deniable authentication, preserving privacy

In Authenticated Mode, the sender holds a long-term Raccoon signing keypair

$$(k_{\mathrm{pr,rac}}, k_{\mathrm{pub,rac}}) = \mathrm{GEN}(\mathrm{Rac})$$

and ephemeral keypairs are generated for the two KEM components:

$$(k_{\mathrm{pr1}}, k_{\mathrm{pub1}}) = \mathrm{GEN}(\mathrm{AKEM1})$$

$$(k_{\mathrm{pr2}}, k_{\mathrm{pub2}}) = \mathrm{GEN}(\mathrm{AKEM2}).$$

The sender performs two encapsulations,

$$\mathrm{Enc}(\mathrm{AKEM1}(k_{\mathrm{pr},s1}, k_{\mathrm{pub},r1})) = (c_1, k_1)$$

$$\mathrm{Enc}(\mathrm{AKEM2}(k_{\mathrm{pr},s2}, k_{\mathrm{pub},r2})) = (c_2, k_2),$$

forms the hybrid ciphertext $c=(c_1,c_2)$, signs it,

$$\mathrm{sig} = \mathrm{Rac\_sign}(k_{\mathrm{pr},s,\mathrm{rac}}, c),$$

and derives the shared secret

$$k_{\mathrm{sh}} = H(k_1 \parallel k_2 \parallel c \parallel \mathrm{sig} \parallel k_{\mathrm{pub},r} \parallel k_{\mathrm{pub},s}).$$

The receiver first verifies the signature and then decapsulates both components before deriving the same $k_{\mathrm{sh}}$.

Deniable Mode replaces the signature with a symmetric authenticator derived from ephemeral secrets. After computing $(c_1,k_1)$ and $$(k_{\mathrm{pr1}}, k_{\mathrm{pub1}}) = \mathrm{GEN}(\mathrm{AKEM1})$$0, the sender sets

$$(k_{\mathrm{pr1}}, k_{\mathrm{pub1}}) = \mathrm{GEN}(\mathrm{AKEM1})$$1

derives

$$(k_{\mathrm{pr1}}, k_{\mathrm{pub1}}) = \mathrm{GEN}(\mathrm{AKEM1})$$2

then

$$(k_{\mathrm{pr1}}, k_{\mathrm{pub1}}) = \mathrm{GEN}(\mathrm{AKEM1})$$3

and authenticates the ciphertext by

$$(k_{\mathrm{pr1}}, k_{\mathrm{pub1}}) = \mathrm{GEN}(\mathrm{AKEM1})$$4

The final session key is

$$(k_{\mathrm{pr1}}, k_{\mathrm{pub1}}) = \mathrm{GEN}(\mathrm{AKEM1})$$5

The receiver decapsulates $$(k_{\mathrm{pr1}}, k_{\mathrm{pub1}}) = \mathrm{GEN}(\mathrm{AKEM1})$$6 and $$(k_{\mathrm{pr1}}, k_{\mathrm{pub1}}) = \mathrm{GEN}(\mathrm{AKEM1})$$7, recomputes $$(k_{\mathrm{pr1}}, k_{\mathrm{pub1}}) = \mathrm{GEN}(\mathrm{AKEM1})$$8 and $$(k_{\mathrm{pr1}}, k_{\mathrm{pub1}}) = \mathrm{GEN}(\mathrm{AKEM1})$$9, verifies the tag, and derives the same session secret.

3. Cryptographic components and security claims

AmphiKey instantiates its hybrid core with ML-KEM-768 and X25519, uses Raccoon DSA in Authenticated Mode, and uses Ascon as the AEAD cipher protecting application traffic after session establishment. The paper assumes IND-CCA2 security for ML-KEM-768 and states that the X25519-based component is assumed to be wrapped or instantiated as an IND-CCA2 KEM, for example via FO-style or HPKE-style binding. In Authenticated Mode, the protocol provides what the paper describes as “OR” confidentiality and robust “AND” authenticity; in Deniable Mode it provides hybrid confidentiality together with deniable authentication (Shakib et al., 1 Sep 2025).

The “OR” confidentiality claim means that session secrecy is intended to survive if either the post-quantum or the classical component remains secure. The forward-secrecy claim is grounded in the use of ephemeral ML-KEM/X25519 keypairs generated per session and kept only in memory for the duration of the handshake. The paper does not present a separate full AKE-style forward-secrecy proof; it states forward secrecy as a design property of the ephemeral construction.

The Authenticated Mode reduction is given as an IND-CCA2-style game with ciphertext $$(k_{\mathrm{pr2}}, k_{\mathrm{pub2}}) = \mathrm{GEN}(\mathrm{AKEM2}).$$0 and key $$(k_{\mathrm{pr2}}, k_{\mathrm{pub2}}) = \mathrm{GEN}(\mathrm{AKEM2}).$$1, reducing to EUF-CMA security of Raccoon, IND-CCA2 security of both KEM components, and PRF security of the combiner hash/KDF:

$$(k_{\mathrm{pr2}}, k_{\mathrm{pub2}}) = \mathrm{GEN}(\mathrm{AKEM2}).$$2

For Deniable Mode, the reduction is to HMAC unforgeability, HKDF PRF security, and IND-CCA2 security of the two KEMs:

$$(k_{\mathrm{pr2}}, k_{\mathrm{pub2}}) = \mathrm{GEN}(\mathrm{AKEM2}).$$3

The deniability argument is based on transcript simulation by the receiver. Because the receiver can decapsulate the same $$(k_{\mathrm{pr2}}, k_{\mathrm{pub2}}) = \mathrm{GEN}(\mathrm{AKEM2}).$$4 and $$(k_{\mathrm{pr2}}, k_{\mathrm{pub2}}) = \mathrm{GEN}(\mathrm{AKEM2}).$$5, derive the same $$(k_{\mathrm{pr2}}, k_{\mathrm{pub2}}) = \mathrm{GEN}(\mathrm{AKEM2}).$$6 and $$(k_{\mathrm{pr2}}, k_{\mathrm{pub2}}) = \mathrm{GEN}(\mathrm{AKEM2}).$$7, and recompute a valid HMAC tag, the resulting transcript is not publicly transferable evidence of sender participation. The paper expresses this in a real-vs-simulated game with distinguishing advantage

$$(k_{\mathrm{pr2}}, k_{\mathrm{pub2}}) = \mathrm{GEN}(\mathrm{AKEM2}).$$8

By contrast, Authenticated Mode is explicitly not deniable because the Raccoon signature is publicly verifiable and therefore yields non-repudiable authenticity.

4. Performance, sizes, and communication overhead

The performance evaluation is conducted on a heterogeneous testbed featuring a server and client on AMD Ryzen 5 hardware and a resource-constrained client on Raspberry Pi. The results emphasize the asymmetry between the two modes: Deniable Mode is close to standard hybrid HPKE cost, whereas Authenticated Mode is dominated by client-side Raccoon signing. The paper also reports experiments involving transfer of ANSI C12.18 tables over the secure channel established by the handshake (Shakib et al., 1 Sep 2025).

Configuration	Reported latency	Reported payload
Deniable Mode	0.15 ms on the server; 0.41 ms on the Raspberry Pi client	1152 B
Authenticated Mode (Raccoon)	4.8 ms for the Raspberry Pi client to initiate; 0.84 ms for the server to verify	12644 B
Authenticated Mode (ML-DSA-65 comparison)	not summarized as a full handshake in the abstract	4413 B

The Deniable Mode operation breakdown reported in the paper gives approximately 154430 ns on the server and 408857 ns on the Raspberry Pi client. The server-side components are X25519 at 39041 ns, ML-KEM at 56196 ns, HKDF derivation at 55185 ns, and HMAC tag generation at 4008 ns. The Raspberry Pi client-side components are X25519 at 103685 ns, ML-KEM at 133074 ns, HKDF derivation at 167481 ns, and HMAC verification at 4617 ns.

The Authenticated Mode cost is bottlenecked by Raccoon signing. Representative receiver-side values include Raccoon verify at 408.7 µs on a Ryzen client and 727.3 µs on a Pi, ML-KEM decapsulation at 59.1 µs or 74.1 µs, and X25519 shared-secret computation at 33.3 µs or 38.9 µs. The paper notes some inconsistency across timing tables, but its stable conclusion is that client-side signature generation dominates the authenticated initiation path.

Primitive sizes reported by the paper explain the bandwidth differential. X25519 public key and ciphertext are 32 B each. ML-KEM-768 public key is 1184 B and ciphertext is 1088 B. ML-DSA-65 public key is 1952 B and signature is 3293 B. Raccoon public key is 2256 B and signature is 11524 B. The HMAC tag is 32 B. The resulting throughput figures, under a 1500-byte payload assumption, are 138.0 Mbps for Deniable Mode, 23.7 Mbps for Authenticated Mode with Raccoon, and 52.2 Mbps for the ML-DSA-65 comparison.

5. Side-channel rationale and authentication semantics

A central feature of AmphiKey is its deliberate use of Raccoon rather than a smaller and faster signature scheme in Authenticated Mode. The paper’s rationale is not conventional performance optimization but side-channel posture. Raccoon is described as a masking-friendly post-quantum signature scheme designed so that sensitive values can be split into $$(k_{\mathrm{pr2}}, k_{\mathrm{pub2}}) = \mathrm{GEN}(\mathrm{AKEM2}).$$9 shares with quasilinear masking overhead $$\mathrm{Enc}(\mathrm{AKEM1}(k_{\mathrm{pr},s1}, k_{\mathrm{pub},r1})) = (c_1, k_1)$$0. In the smart-grid setting, where field devices may be physically accessible, this is presented as an argument for preferring a slower and larger signature in the non-repudiable mode (Shakib et al., 1 Sep 2025).

The paper is explicit, however, that the side-channel benefit is localized. It protects the signature operation and the long-term signing key, but it does not inherently protect ML-KEM operations, X25519 operations, or the confidentiality of the final session secret. This sharply bounds the scope of the side-channel claim. AmphiKey is therefore not a fully side-channel-hardened protocol stack; it is a hybrid AKEM whose authenticated branch adopts a signature primitive chosen for better masking compatibility.

The protocol’s two authentication semantics are correspondingly distinct. In Authenticated Mode, the signature is transferable evidence. This gives strong, explicit, non-repudiable authenticity, which the paper associates with control commands and other auditable actions. In Deniable Mode, the receiver can reconstruct the authenticator and therefore simulate valid transcripts. This preserves privacy because the transcript does not prove sender participation to a third party. The design thus operationalizes a sharp separation between public verifiability and deniability, rather than treating deniability as an incidental byproduct.

A plausible implication is that AmphiKey’s dual-mode design is as much about accountability policy as about cryptographic agility. The authenticated branch is suitable when evidentiary value is desirable; the deniable branch is suitable when the security requirement is peer authentication without transferable proof.

6. Limitations, deployment issues, and protocol significance

The paper identifies several limitations. The most immediate is the cost of Authenticated Mode, especially on low-power clients. A 12.6 KB initiator payload and a client-side initiation time around 4.8 ms are manageable for some high-stakes smart-grid exchanges, but they are poorly suited to large-scale reconnect storms or high-volume edge traffic. The paper explicitly notes that such scenarios would expose the scaling problem of client-side signature generation (Shakib et al., 1 Sep 2025).

A second limitation is trust and key-management complexity. Real deployment would require a robust PKI for multiple key types, particularly for the long-term authenticated-mode keys. The paper treats the protocol as transport-agnostic and uses HTTP as a test transport, but it does not fully specify operational PKI design, certificate lifecycle management, or the mechanics of fragmentation and chunking when the authenticated payload traverses constrained smart-grid transport units.

The deniability analysis is also qualified. The paper states that a more rigorous formal proof in a recognized deniability model would strengthen the deniable mode. This suggests that the current argument is a protocol-level simulation claim rather than a full treatment in the style of the most formal deniable-authentication literature. The experimental methodology is likewise focused on core cryptographic costs; even the Raccoon keypair was generated ephemerally in the performance evaluation, whereas real deployments would use long-term signing keys.

Within its stated scope, however, AmphiKey occupies a distinctive position. It is not merely a hybrid KEM, because it incorporates integrated authentication semantics; and it is not merely an authenticated KEM, because it exposes a choice between non-repudiable and deniable authentication within the same ML-KEM-768/X25519 foundation. The protocol’s significance therefore lies in the way it aligns cryptographic composition with smart-grid operational diversity: auditable control paths can use the authenticated branch, while routine meter and telemetry traffic can use the deniable branch, all while retaining the paper’s intended hybrid confidentiality and forward-secrecy properties.