Key Encapsulation Mechanism-Based Integrated Encryption Scheme (KEM-IES) Abel C. H. Chen Information & Communications Security Laboratory, Chunghwa Telecom Laboratories Taoyuan, Taiwan Email: [email protected]; ORCID: 0000-0003-3628-3033 Abstract—The Elliptic Curve Integrated Encryption Scheme (ECIES) is widely regarded as a practical method and has been adopted by multiple standards. However, the advancement of quantum computing technologies poses potential security risks to ECIES. Therefore, this study proposes a Key Encapsulation Mechanism-Based Integrated Encryption Scheme (KEM-IES), which enhances resistance to quantum attacks by incorporating a Post-Quantum Cryptography (PQC)-based Key Encapsulation Mechanism (KEM). Furthermore, the study integrates the Ascon algorithm, released by the National Institute of Standards and Technology (NIST) in August 2025, to further improve computational efficiency and enable applicability to embedded systems. The proposed KEM-IES and its Ascon-based variant are implemented on a Raspberry Pi 4, and evaluations are conducted to compare the performance of ECIES and KEM-IES. Keywords—ECIES, ML-KEM, Ascon, KEM-IES, Hybrid IES
I. INTRODUCTION Quantum computing technologies have continued to advance, bringing increased attention to the issue of “Harvest Now, Decrypt Later” (HNDL) [1]. The Elliptic Curve Integrated Encryption Scheme (ECIES) is one of the mainstream encryption mechanisms in current use [2], and a number of standards (e.g., IEEE 1609.2 [3], IEEE 1609.2.1 [4], and IETF RFC 8446 [5]) still rely on ECIES and Elliptic Curve Diffie-Hellman (ECDH) for encryption and key exchange. However, quantum computing has the potential to compromise the security of the Elliptic Curve Discrete Logarithm Problem (ECDLP) and Elliptic Curve Cryptography (ECC) [6]. As a result, both ECIES and ECDH lack quantum resistance and face increasing vulnerability under HNDL-style threats. Given these concerns, the design of an Integrated Encryption Scheme (IES) with quantum-resistant properties has become an urgent challenge. Therefore, this study proposes a Key Encapsulation Mechanism-Based IES (KEMIES) that incorporates Module Lattice-Based Key Encapsulation Mechanisms (ML-KEM) [7] or Hamming Quasi-Cyclic (HQC) [8], both of which are Post-Quantum Cryptography (PQC) algorithms selected by the National Institute of Standards and Technology (NIST). These mechanisms provide the foundation for achieving quantum security. Furthermore, the study integrates the lightweight cryptography algorithm (i.e., Ascon algorithm [9]) to further enhance computational efficiency. The proposed design is implemented and evaluated on a Raspberry Pi 4 to validate its effectiveness through empirical analysis. The main contributions of this study are summarized as follows. • Quantum Security: The proposed KEM-IES employs a ML-KEM during the key exchange phase. Its underlying mathematical hardness relies on the Shortest Vector Problem (SVP) and the Learning With
Errors (LWE) problem, thereby providing resistance against quantum computational attacks. • Lightweight Cryptography: The Ascon-based KEMIES variant proposed in this study enhances encryption performance. By utilizing Ascon in both the key derivation and encryption phases, the scheme achieves improved computational efficiency. • Empirical Evaluation: To assess performance on embedded systems, the study implements the proposed KEM-IES and the Ascon-based KEM-IES on a Raspberry Pi 4. Their performance is practically compared with that of ECIES. II. RELATED WORK Section II.A explains the flows of the ECIES, while Section II.B describes how ECIES is applied in V2X communications and outlines the structure of the encrypted SPDU. A. Elliptic Curve Integrated Encryption Scheme In ECIES, the process begins with an ECDH key exchange to establish a Key-Encryption Key (KEK), denoted as z1. As illustrated in Fig. 1, assume that Bob’s ECC public key vb is publicly available and known to Alice. Alice then generates an ephemeral ECC key pair (e.g., a NIST P-256 key pair), consisting of her private key ua and corresponding public key va. Alice transmits va to Bob, after which both parties compute a shared elliptic-curve point by multiplying their private key with the other party’s public key. The xcoordinate of this shared point is extracted and used as z1 the result of the key exchange. The KEK z1, along with the shared contextual information p (e.g., the hash value of the request message for integrity checking), is then passed into a Key Derivation Function (KDF). In this scheme, KDF2 based on the Secure Hash Algorithm 256 (SHA-256) is used to derive a 256-bit value. The first 128 bits of the output are taken as k1, and the remaining 128 bits as k2. Alice subsequently generates an AES-128–based Data-Encryption Key (DEK), denoted as s, and uses k1 to encrypt s, producing the encrypted DEK c, which is then sent to Bob. In the IEEE 1609.2 [3] and IEEE 1609.2.1 [4] standards, the encryption of s is performed using 𝑐 = 𝑠⨁𝑘1 . Therefore, once Bob obtains z1 and completes the KDF computation, he can recover the DEK by computing 𝑠 = 𝑐⨁𝑘1 . Finally, the encrypted DEK c and k2 are input into a keyed-Hash Message Authentication Code (HMAC) function to generate the Message Authentication Code (MAC) t, which serves as a tag. Alice transmits t to Bob, who recomputes the MAC using c and k2 and verifies whether it matches the received tag. Successful verification confirms
message integrity, allowing both parties to use the DEK s with AES-128 for subsequent data encryption and decryption.
IEEE 1609.2 Data IEEE 1609.2 Content Encrypted Data
Recipients (PK Recipient Info) EncryptedDataEncryptionKey
va c Alice Key Exchange Based on Asymmetric Encryption
Bob
Ephemeral ECC Key Pair Generation
ua vb
Shared Secret Generation Based on ECDH
p
KDF Based on SHA2
ub
va
Integrity Check Based on HMAC
KDF Based on SHA2
k2
p
Fig. 2. The structure of encrypted SPDU in IEEE 1609.2 [3].
k1
c
Symmetric Encryption
c
Nonce CCM Ciphertext
z1
k1 s
Ciphertext (AES-128 Ciphertext)
Shared Secret Generation Based on ECDH
z1 Key Derivation Based on KDF
t
Symmetric Decryption
k2
s
c
HMAC Based on SHA2
HMAC Based on SHA2
t
t Check the value of tag t
Alice Key Exchange Based on Asymmetric Kb,pub Encryption
Fig. 1. The flows of ECIES. B. The Encrypted Secure Protocol Data Unit in IEEE 1609.2 As described in Section II.A, the ECIES process requires Alice to transmit three items to Bob: Alice’s ECC public key va (which functions as the encrypted KEK), the encrypted DEK c, and the tag t. Accordingly, IEEE 1609.2 [3] specifies the EncryptedDataEncryptionKey structure to encapsulate these elements. Furthermore, the actual application data to be transmitted is encrypted using the DEK s as the AES-128 key, together with a randomly generated nonce. The data are encrypted under the AES-128 Cipher Block Chaining (CBC)MAC Mode (CCM), producing the CCM ciphertext. IEEE 1609.2 [3] defines the Ciphertext structure to store both the nonce and the resulting CCM ciphertext. Finally, the EncryptedDataEncryptionKey structure and the Ciphertext structure are combined to form the encrypted SPDU, as illustrated in Fig. 2. III. THE PROPOSED METHODS Section III.A explains the flows of the proposed KEM-IES. Section III.B then integrates ECIES and KEM-IES to construct a hybrid IES. Finally, Section III.C describes how the proposed schemes are applied to V2X communications and presents the revised encrypted SPDU structure. A. Key Encapsulation Mechanism-Based Integrated Encryption Scheme In the KEM-IES, the process begins with establishing the KEK z2 using a PQC-based Key Encapsulation Mechanism (KEM). As illustrated in Fig. 3, assume that Bob’s KEM public key Kb,pub is publicly available and held by Alice. Using Kb,pub, Alice executes the PQC-based KEM to generate the shared secret z2 (i.e., the KEK) and the encapsulated key value e (i.e., the encrypted KEK). Alice then sends e to Bob. Bob applies his KEM private key Kb,priv to decapsulate e to obtain the KEK z2.
p Key Derivation Based on KDF
Bob Kb,priv
Key Encapsulation Based on ML-KEM
z2 KDF Based on SHA2, SHA3, or Ascon-Hash
k2
p
k1
c
Symmetric Encryption
c Integrity Check Based on HMAC
Key Decapsulation Based on ML-KEM
z2 KDF Based on SHA2, SHA3, or Ascon-Hash
k1 s
e
Symmetric Decryption
k2
s
c
HMAC Based on SHA2, SHA3, or Ascon-Hash
HMAC Based on SHA2, SHA3, or Ascon-Hash
t
t Check the value of tag t
Fig. 3. The flows of KEM-IES. Modifications can be made to the key derivation and integrity checking processes based on ECIES. In ECIES, the KDF is constructed using SHA-2; this may be replaced with SHA-3 or Ascon-Hash. After inputting the KEK z2 together with the shared contextual information p, the derived outputs k1 and k2 are obtained. Alice then generates a DEK s, where the symmetric encryption algorithm may be AES or Ascon128 Authenticated Encryption with Associated Data (AEAD). Using k1, Alice encrypts s to form the encrypted DEK c, which is subsequently transmitted to Bob. For integrity checking, the hash function used in the HMAC computation may likewise be replaced with SHA-3 or AsconHash. The tag t is then produced by applying the HMAC function to the encrypted DEK c together with k2. B. Hybrid Integrated Encryption Scheme In the proposed hybrid IES, Alice is assumed to possess both Bob’s ECC public key vb and Bob’s KEM public key Kb,pub. She executes the ECDH key exchange described in Section II.A, as well as the PQC-based KEM described in Section III.A, thereby generating her ECC public key va and the encapsulated key value e. These values are transmitted to Bob. Both parties can then compute the results z1 and z2, as illustrated in Fig. 4. In the key derivation process, three inputs are provided to the KDF: z1, z2, and the shared contextual information p. The KDF then produces the derived keys k1 and k2. While the original KDF is based on SHA-2, it may be replaced with SHA-3 or Ascon-Hash. Subsequently, k1 is used to encrypt
the DEK s, producing the encrypted DEK c, which is transmitted to Bob. For integrity checking, the hash function in the HMAC computation can similarly be replaced with SHA-3 or Ascon-Hash, and the tag t is calculated by applying the HMAC to the encrypted DEK c together with k2.
Alice
Key Exchange Based on Asymmetric Encryption
Ephemeral ECC Key Pair Generation
ua
vb
Key Derivation Based on KDF
va Shared Secret Generation Based on ECDH
KDF Based on SHA2, SHA3, or Ascon-Hash
z2
KDF Based on SHA2, SHA3, or Ascon-Hash Symmetric Decryption
k2
c
HMAC Based on SHA2, SHA3, or Ascon-Hash
t
t
(b)
IEEE 1609.2 Data
p
k1
k2
HMAC Based on SHA2, SHA3, or Ascon-Hash
(a)
z1
c
Symmetric Encryption
c Integrity Check Based on HMAC
z2
k1 s
ub
Based on ML-KEM
Shared Secret Generation Based on ECDH
z1 p
Bob
Kb,priv Key Encapsulation e Key Decapsulation Based on ML-KEM
reported in milliseconds. ML-KEM demonstrates the highest efficiency in key pair generation and key encapsulation, resulting in significantly lower computation times compared with other methods, as observed in Fig. 6, Fig. 7, and Fig. 8. In contrast, HQC exhibits the lowest efficiency in key pair generation and key encapsulation, leading to notably higher computation times than the other methods. ECIES, which is based on ECC, achieves computational efficiency between that of ML-KEM and HQC. In the hybrid IES, both the ECDH key exchange and the PQC-based KEM are executed, resulting in computation times approximately equal to the sum of those for ECIES and KEM-IES.
s
IEEE 1609.2 Data
IEEE 1609.2 Content
IEEE 1609.2 Content
Encrypted Data
Encrypted Data
Recipients (PK Recipient Info)
Recipients (PK Recipient Info)
EncryptedDataEncryptionKey
EncryptedDataEncryptionKey
e
e || va
c
c
t
t
Ciphertext (AES or Ascon Ciphertext)
Ciphertext (AES or Ascon Ciphertext)
Nonce
Nonce
CCM Ciphertext
CCM Ciphertext
Check the value of tag t
Fig. 4. The flows of Hybrid-IES. C. The Revised Encrypted SPDU In the KEM-IES, Alice transmits three items to Bob: the encapsulated key value e (e.g., the encrypted KEK), the encrypted DEK c, and the tag t. In the hybrid IES, Alice transmits four items: her ECC public key va (i.e., part of the encrypted KEK), the encapsulated key value e (i.e., the other part of the encrypted KEK), the encrypted DEK c, and the tag t. Accordingly, the EncryptedDataEncryptionKey structure can be revised to accommodate the encrypted KEK designed in this study: in KEM-IES, the encrypted KEK consists of e, whereas in the hybrid IES, the encrypted KEK consists of e || va, as illustrated in Fig. 5. The formats of the encrypted DEK c and the tag t remain unchanged. Similarly, the Ciphertext structure retains the same formats for the nonce and CCM ciphertext fields, although the symmetric encryption algorithm may be either AES or Ascon. IV. PRACTICAL EXPERIMENTAL RESULTS AND DISCUSSIONS
Fig. 5. Revised encrypted SPDU structures based on IEEE 1609.2: (a) for KEM-IES and (b) for Hybrid IES.
Fig. 6. The comparison of key generation time (unit: ms).
A. Practical Experimental Environment To evaluate and compare the ECIES, the KEM-IES, and the hybrid IES, implementations were conducted on a Raspberry Pi 4. In these implementations, ECIES utilized the ECC P-256 curve, while KEM-IES employed ML-KEM-512 and HQC-128 for PQC-based KEM. For hash computations, SHA-256, SHA3-256, SHAKE-128, and Ascon-Hash256 were implemented and compared. Furthermore, symmetric encryption performance was evaluated using both AES-128 and Ascon-AEAD128. B. Computation Time Comparison This study compares the key generation time (Fig. 6), KEK encryption time (Fig. 7), DEK encryption time (Fig. 8), and data encryption time (Fig. 9), with all measurements
Fig. 7. The comparison of KEK encryption time (unit: ms).
while KEM-IES offers quantum security, their main drawback is the comparatively large length of the encapsulated key values. TABLE I THE SIZE COMPARISON OF EncryptedDataEncryptionKey IES
Fig. 8. The comparison of DEK encryption time (unit: ms). For data encryption, the Ascon series implementations in this study employed Ascon-AEAD128, while other implementations used AES-128. As shown in Fig. 9, encryption using Ascon-AEAD128 requires less computation time than AES-128, demonstrating higher computational efficiency.
ECIES Based on P256 [2], [3], [4] KEM-IES Based on ML-KEM-512 KEM-IES Based on HQC-128 Hybrid IES Based on P-256 and ML-KEM512 Hybrid IES Based on P-256 and HQC-128
Size of encrypted KEK
Size of c
Size of t
Total
33
16
32
81
x
768
16
32
816
x
4433
16
32
4481
x
801
16
32
849
x
4466
16
32
4514
Quantum Safe
V. CONCLUSIONS AND FUTURE WORK The KEM-IES proposed in this study employs a PQCbased KEM during the key exchange phase, enhancing resistance to quantum computing attacks. Furthermore, Ascon-AEAD128 is utilized for symmetric encryption, further improving computational efficiency. Future research could focus on designing PQC-based KEMs with shorter encapsulated key values to reduce the size of the SPDU, achieving both quantum security and suitability for transmission in V2X communications. REFERENCES [1]
[2]
Fig. 9. The comparison of data encryption time (unit: ms). Due to page limitations, only the comparison of encryption computation times is presented; however, the results for decryption computation times are consistent with those observed for encryption. C. SPDU Size Comparison This section discusses the sizes of the EncryptedDataEncryptionKey required by each integrated encryption method when applied to V2X communications. The comparison results are summarized in Table I. ECIES requires the shortest total size because the encrypted KEK based on ECC is the shortest. Among KEM-IESs, ML-KEM produces a shorter encapsulated key value than HQC, resulting in the second-shortest total size. In the hybrid IES, the encrypted KEK size is the sum of the ECC public key and the encapsulated key value, making its EncryptedDataEncryptionKey longer than those of the other schemes. Although ECIES achieves the shortest SPDU length, it does not provide quantum resistance. Conversely,
[3]
[4]
[5]
[6]
[7]
[8]
[9]
L. Yao et al., "Breaking the Trilemma: Toward Efficient, PrivacyPreserving, and Forward-Secure Data Sharing in the Post-Quantum Era," in IEEE Transactions on Information Forensics and Security, doi: 10.1109/TIFS.2025.3637717. M. Xie et al., "Traceability and Identity Protection in Smart Agricultural IoT System Framework Based on Blockchains," in IEEE Transactions on Dependable and Secure Computing, vol. 22, no. 5, pp. 5335-5351, Sept.-Oct. 2025, doi: 10.1109/TDSC.2025.3565593. "IEEE Draft Standard for Wireless Access in Vehicular Environments-Security Services for Application and Management Messages," in IEEE P1609.2/D5, September 2025, pp.1-376, 2 Oct. 2025. "IEEE Draft Standard for Wireless Access in Vehicular Environments (WAVE) - Certificate Management Interfaces for End Entities," in IEEE P1609.2.1/D2, September 2025, pp.1-259, 9 Oct. 2025. E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3," in Internet Engineering Task Force (IETF) Request for Comments (RFC) 8446, pp.1-160, August 2018, doi: 10.17487/RFC8446. B. Bera, A. K. Das and B. Sikdar, "Quantum-Resistant Secure Communication Protocol for Digital Twin-Enabled Context-Aware IoT-Based Healthcare Applications," in IEEE Transactions on Network Science and Engineering, vol. 12, no. 4, pp. 2722-2738, JulyAug. 2025, doi: 10.1109/TNSE.2025.3553044. "Module-Lattice-Based Key-Encapsulation Mechanism Standard," in Federal Information Processing Standards, FIPS 203, pp.1-47, 13 August 2024, doi: 10.6028/NIST.FIPS.203. G. Alagic et al., "Status Report on the Fourth Round of the NIST PostQuantum Cryptography Standardization Process," in NIST Interagency/Internal Report, NIST IR 8545, pp. 1-27, March 2025, doi: 10.6028/NIST.IR.8545. M. S. Turan, K. A. McKay, D. Chang, J. Kang and J. Kelsey, "AsconBased Lightweight Cryptography Standards for Constrained Devices," in NIST SP 800-232, pp.1-41, 2025.