Adapting the BIKE Key Encapsulation Mechanism to Memory-Constrained IoT Devices

Abstract

Post-quantum cryptography represents one of the most promising areas of modern cryptography. The development in this discipline significantly accelerated after it became of interest to the National Institute of Standards and Technology (NIST). One of the important research directions in this area is the practical deployment of post-quantum cryptographic algorithms on resource-constrained devices. In this article, we investigate the possibility of deploying post-quantum cryptography on small processors with limited random access memory (RAM) capacity. These processors are commonly used in Internet of Things (IoT) devices, where the practical deployment of post-quantum algorithms remains challenging due to computational and memory constraints. We select a suitable algorithm and perform several implementation modifications that enable its execution on microcontrollers with limited memory resources.

1. Introduction

The use of cryptography ensures the protection of information from unauthorized people or systems. In practice, cryptography performs several key functions. These include confidentiality, which ensures that only authorized persons have access to sensitive data; integrity, which ensures that the information has not been changed during transmission; authentication, i.e., verification of the identity of the communicating parties; and non-repudiation, which ensures that the sender cannot deny the authorship of the message. The confidentiality of information guarantees that a message is readable only by those communication parties who possess the correct cryptographic key.

The most widely used public-key cryptographic algorithms today include Rivest-Shamir-Adleman (RSA) and elliptic curve cryptography (ECC) [1,2]. These algorithms are based on computational problems from number theory and are commonly used in Transport Layer Security (TLS) protocols, digital signatures, and secure communication systems. However, the development of quantum computers poses a significant threat to these cryptographic schemes [3]. Shor’s algorithm can efficiently solve the problems of integer factorization and discrete logarithm computation, which form the security basis of RSA and ECC. Consequently, a sufficiently powerful quantum computer could potentially break many currently deployed public-key cryptosystems.

To address this threat, the National Institute of Standards and Technology (NIST) initiated the post-quantum cryptography (PQC) standardization process (https://csrc.nist.gov/projects/post-quantum-cryptography (accessed on 1 April 2026)). This initiative, launched in December 2016, aims to identify and standardize cryptographic algorithms that remain secure even in the presence of quantum computers. The goal of this process is to develop new cryptographic standards that can serve as counterparts to existing mechanisms, such as the digital signature scheme specified in FIPS 186 [4] and key establishment mechanisms described in NIST SP 800-56A [5] and NIST SP 800-56B [6].

The PQC standardization process consists of several evaluation rounds during which candidate algorithms are analyzed in terms of security, performance, and implementation characteristics. In July 2022, NIST announced the first algorithms selected for standardization, namely CRYSTALS-Kyber, CRYSTALS-Dilithium, Falcon, and SPHINCS⁺. At the same time, NIST opened the fourth round of the PQC challenge, which focuses primarily on the evaluation of backup algorithms and the study of practical deployment aspects [7].

One of the major challenges in this area is the deployment of PQC algorithms in resource-constrained environments such as Internet of Things (IoT) devices. Many IoT platforms operate on small embedded processors with limited RAM capacity and computational power. Previous studies indicate that current PQC algorithms often have relatively high computational and memory requirements [8]. Therefore, implementing PQC algorithms on such devices requires careful optimization of both computational complexity and memory usage.

Our work is motivated by this challenge. It explores the possibilities of using PQC algorithms on small processors with limited RAM capacity. In this work, an algorithm with suitable characteristics for deployment on small processors is selected from among the Key Encapsulation Mechanism (KEM) algorithms considered in the NIST PQC standardization process. The goal of this study is to modify the reference implementation of the selected algorithm and create an optimized implementation that can be deployed on processors with limited RAM capacity.

The main contributions of this paper can be summarized as follows:

• Analysis of the feasibility of deploying post-quantum cryptographic algorithms on IoT devices with limited RAM capacity.
• Selection of suitable KEM algorithms and embedded platforms for practical evaluation.
• Implementation and optimization of the selected algorithm with the aim of reducing memory usage.
• Experimental evaluation demonstrating the feasibility of running PQC algorithms on small processors.

The remainder of this paper is organized as follows. Section 2 briefly introduces Post-quantum cryptography. Section 3 presents related work in the area of post-quantum cryptography and its deployment on embedded devices. Section 4 describes the methodology used in this work. Section 5 presents the implementation details and optimization techniques. Section 6 discusses the obtained results, and Section 7 concludes the paper.

2. Post-Quantum Cryptography

Post-quantum cryptography (PQC) refers to cryptographic algorithms designed to remain secure against attacks performed by quantum computers. These algorithms are based on mathematical problems that are believed to be resistant to both classical and quantum attacks [9].

Current PQC candidates can be broadly categorized into several classes, including lattice-based, code-based, hash-based, and multivariate cryptographic schemes [3]. Each class offers different trade-offs in terms of security, computational complexity, and memory requirements [10].

Significant progress in this area has been driven by the NIST Post-Quantum Cryptography standardization process, which evaluates candidate algorithms with respect to security, performance, and implementation characteristics [11].

In this work, we focus on code-based cryptography, specifically Key Encapsulation Mechanism (KEM) schemes, which represent an important class of PQC algorithms with favorable implementation characteristics [12].

3. Related Work

3.1. Opened Problems of Post-Quantum Cryptography

Post-quantum cryptography currently appears to be a promising response to the threat of quantum computers. Currently used algorithms, such as RSA, Advanced Encryption Standard (AES), and ECC, are deployed in a wide range of applications. Since AES is a symmetric encryption algorithm, its security is not significantly affected by the advent of quantum computers (https://crypto.stackexchange.com/questions/102671/is-aes-128-quantum-safe (accessed on 1 April 2026)). However, according to the assumptions mentioned in the article [13], the RSA algorithm could be broken by a quantum computer around 2035, and the ECC algorithm, according to [2], between 2030 and 2040.

If we want transmitted data to remain secure even after RSA or ECC becomes vulnerable, new post-quantum algorithms must not only be developed but also deployed in practice before that time.

Two main questions that post-quantum cryptography raises are mentioned in [14]:

• What are the possible applications of post-quantum cryptography?
• What is the current state of post-quantum cryptography, including processes, use cases, and challenges?

Another important issue concerns the security evaluation of PQC algorithms. According to the [7], PQC algorithms are relatively new compared to RSA or ECC and therefore have undergone less extensive security analysis.

According to [10], researchers are currently focusing on evaluating and optimizing PQC algorithms for deployment on devices with limited resources. Future applications are expected on various platforms including desktop computers, mobile devices, and IoT systems [15].

3.2. Post-Quantum Cryptography and IoT

The Internet of Things (IoT) represents a paradigm in which physical devices equipped with sensors, computing power, and network connectivity communicate with each other and interact with their environment. These devices are increasingly used in healthcare, industry, transportation, and smart home systems.

However, IoT devices often operate with very limited computational resources. According to [16], the high computational and memory requirements of PQC algorithms represent one of the main obstacles to their deployment in embedded systems.

Many IoT devices operate with limited memory resources, typically ranging from tens to hundreds of kilobytes of RAM. At the same time, PQC algorithms often use public keys with sizes ranging from hundreds of kilobytes to several megabytes. This significantly increases the computational complexity of these algorithms.

Another limiting factor is energy consumption. Many IoT devices operate on battery power and are designed for long-term operation without maintenance. Reducing computational requirements is therefore essential for practical deployment of PQC algorithms.

Finally, IoT systems are characterized by strong hardware heterogeneity. Devices from different manufacturers use different microcontrollers and architectures.

Table 1. Examples of microcontroller manufacturers used in IoT devices.

Company	Microchips	Usability
Qualcomm Technologies Inc. (San Diego, CA, USA)	QCS6490, QCS8250, QCM2290, MDM9206, QCC730M, QCA4531	Edge AI, smart sensors, smart devices
Intel Corporation (Santa Clara, CA, USA)	Quark, Atom x6000E, Intel Curie	Industrial IoT, edge computing, wearables
Texas Instruments Inc. (Dallas, TX, USA)	MSP430, CC2652, SimpleLink Wi-Fi, CC3200 Zigbee/BLE	Industrial sensors
NXP Semiconductors (Eindhoven, Netherlands)	i.MX RT, LPC5500, Kinetis K32	Automotive IoT, edge AI, MCU for sensors
Cypress Semiconductor Corp. (San Jose, CA, USA)	PSoC 6, CYW4343W, EZ-BLE	BLE/Wi-Fi, smart homes
MediaTek Inc. (Hsinchu, Taiwan)	MT2625, MT7688, Genio 1200	Smart homes, LTE-M/NB-IoT, edge AI
Microchip Technology Inc. (Chandler, AZ, USA)	ATmega328P, PIC32, SAMD21, WBZ451	Arduino, Zigbee/BLE modules, IoT sensors
Samsung Electronics (Suwon, South Korea)	Exynos i T100, Artik 053, S3FBP5A	Smart devices, wearables, security chips
Silicon Laboratories Inc. (Austin, TX, USA)	EFR32, BG22, FG25	Zigbee, Thread, BLE
Invensense Inc. (San Jose, CA, USA)	ICM-20948, ICM-42688-P	IMU sensors, wearables, AR/VR
STMicroelectronics (Geneva, Switzerland)	STM32F4, STM32L4, STM32WB	Low-power IoT, BLE MCU
Nordic Semiconductor ASA (Trondheim, Norway)	nRF52840, nRF5340, nRF9160	BLE, LTE-M/NB-IoT, smart sensors
Analog Devices Inc. (Wilmington, MA, USA)	ADuCM3029, ADXL362	Low-power MCUs and sensors

presents several companies that dominate the IoT microcontroller market.

4. Methods of Our Research

The objective of this research is to investigate the feasibility of deploying post-quantum cryptographic algorithms on devices with limited computational resources and RAM capacity. The methodology used in this work consists of three main stages: selection of a suitable post-quantum algorithm, evaluation of its computational and memory requirements, and selection of appropriate IoT hardware platforms for experimental implementation.

4.1. Selection of the Post-Quantum Algorithm

Since the goal of the study is secure key establishment on constrained devices, the research focuses on Key Encapsulation Mechanism (KEM) algorithms from the NIST Post-Quantum Cryptography standardization process. In particular, code-based algorithms from the fourth round of the NIST PQC process were considered, including BIKE, HQC, and Classic McEliece.

For the purposes of the experimental evaluation, parameter sets corresponding to NIST security level 1 were used. This security level was selected because it provides the lowest memory requirements among the available parameter sets and therefore represents the most realistic scenario for deployment on IoT devices with limited RAM capacity.

The algorithms were compared based on several criteria relevant to embedded implementations, including the size of public and private keys, computational complexity, and memory requirements. Based on this comparison, the BIKE algorithm was selected as the most suitable candidate for further implementation and experimental evaluation.

As shown in

Table 2. Comparison of selected PQC KEM algorithms for embedded environments.

Algorithm	Public Key Size	Ciphertext Size	Implementation Complexity
Kyber	∼1.5 kB	∼768 B	Moderate
BIKE	∼1–2 kB	∼1 kB	Moderate
HQC	∼2–3 kB	∼1.5 kB	Higher
Classic McEliece	>200 kB	∼128 B	Very high memory usage

, among the considered algorithms, Classic McEliece provides strong security guarantees but requires extremely large public keys, which makes it impractical for deployment on memory-constrained IoT devices. Lattice-based algorithms such as Kyber provide good performance but still require relatively complex arithmetic operations. Code-based schemes such as BIKE offer a favorable trade-off between memory requirements and computational complexity, which motivated its selection for further optimization and experimental evaluation in this work.

4.2. Experimental Environment

The experimental evaluation of the algorithms was performed using available software implementations executed in a controlled environment. The experiments were conducted on a computer running Linux Mint 21.3 with 8 GB of RAM and an Intel Core i5-3470S processor operating at 2.90 GHz.

The implementation was compiled using the GCC toolchain with standard optimization flags (-O2) for embedded development. Stack usage analysis was performed using the compiler options -fstack-usage and -fcallgraph-info, which allowed identification of the most memory-demanding functions.

Execution time measurements were performed separately for the three main KEM operations: key generation, encapsulation, and decapsulation. The clock_gettime() function (https://linux.die.net/man/3/clock_gettime (accessed on 1 April 2026)) with the CLOCK_MONOTONIC clock source was used to measure the execution time. Each measurement was repeated 100 times in order to obtain stable results.

Memory consumption was analyzed using compiler-assisted static analysis. The GCC compiler options -fstack-usage (https://gcc.gnu.org/onlinedocs/gnat_ugn/Static-Stack-Usage-Analysis.html?utm_source (accessed on 1 April 2026)) and -fcallgraph-info were used to determine the stack usage of individual functions and to identify the most memory-demanding execution paths.

4.3. Selection of IoT Hardware Platforms

After identifying the most suitable algorithm, the next step was the selection of appropriate hardware platforms for practical implementation. The selection of the microcontroller platforms was influenced by several factors, including processor architecture, clock frequency, available RAM, flash memory capacity, and the availability of development tools and documentation.

The selected platforms represent commonly used IoT microcontrollers and provide a realistic environment for evaluating the feasibility of deploying PQC algorithms on embedded systems.

The microcontroller platforms used for experimental evaluation are summarized in

Table 3. Microcontroller platforms considered for experimental evaluation.

Platform	Processor	Architecture	Clock	RAM	Flash
ESP8266	Tensilica L106	32-bit	80 MHz	80 kB	4 MB
ESP32	Xtensa LX6	32-bit	240 MHz	520 kB	4 MB

.

These platforms were selected because they represent widely used IoT microcontrollers while still providing sufficiently constrained memory environments for evaluating the deployment feasibility of post-quantum cryptographic algorithms.

4.4. Implementation and Optimization

After selecting both the algorithm and the target hardware platform, the reference implementation of the BIKE algorithm was analyzed in detail. The goal of this analysis was to identify implementation mechanisms that prevent direct deployment on memory-constrained devices.

Based on this analysis, several modifications of the reference implementation were performed with the aim of reducing memory consumption. The modifications focused primarily on limiting dynamic memory allocation, reducing the size of intermediate buffers, and optimizing selected computational procedures.

The correctness of the modified implementation was verified by comparing the outputs of the optimized implementation with the outputs produced by the original reference implementation. Additional validation was performed through practical execution of the algorithm on the selected microcontrollers.

5. Implementation of PQC on Processor with Limited RAM Capacity

In the article [17], the authors discussed the application of post-quantum cryptographic algorithms. They point out that one of the significant problems that new PQC algorithms face compared to existing solutions is the problem of high performance requirements. Unfortunately, all candidates for the PQC challenge are characterized by larger key sizes, generated signatures, or generated ciphertexts compared to currently used cryptosystems. However, if post-quantum cryptography algorithms are to replace current standards in the future, they must be practically deployable on various types of devices. According to the source [18], in the case of low-memory embedded/cyber–physical systems that are typical of the world of the Internet of Things, it is necessary to make the deployment of post-quantum algorithms easier and more efficient. However, all currently available implementations of post-quantum algorithms are generally characterized by high computational time and memory requirements. If these algorithms are to be successfully deployed in IoT environments, it is essential to significantly reduce their computational and memory requirements through optimizations and implementation modifications.

5.1. The Selection of Suitable Post-Quantum Algorithm

The selection of a suitable post-quantum algorithm for deployment on a processor with limited RAM capacity must take into account mainly computational efficiency and memory requirements, since these devices have only limited computational and memory resources. We decided to analyze three candidates of the fourth round of the NIST PQC challenge, namely BIKE, HQC and Classic McEliece. We presented the process of choice in the article [19].

Of the three analyzed algorithms, BIKE turned out to be the most suitable candidate for implementation. This was due to the fact that it achieved the lowest computation time for key generation, encapsulation, and decapsulation. This is significant in the context of real-time processing speed, but also in the context of energy saving. Regarding memory consumption, BIKE also demonstrated the lowest RAM consumption when performing critical functions in the evaluated implementation. Given that our target group is devices with limited RAM capacity of several tens or hundreds of kilobytes, this parameter is key when deciding on the suitability of the algorithm. On the contrary, HQC and Classic McEliece algorithms provide high security, but their implementations showed higher computational and memory requirements during experimental evaluation. In addition, Classic McEliece requires significantly more space for storing public keys, which can be limiting when communicating over narrow-band channels. Based on these observations, we selected BIKE as the most suitable candidate for implementation on IoT devices, which offers an ideal compromise between security level, computational efficiency, and low memory requirements. These properties make it an efficient and practically usable solution for post-quantum cryptography in hardware-constrained environments.

5.2. The Selection of a Suitable Microcontroller for Implementation

We performed a quantitative comparison of available microcontrollers in terms of clock frequency, memory capacity, development tool support, and power consumption. We performed a comparison of the following microcontrollers:

• ATmega328P, whose documentation is available in the source [20];
• ATmega2560, whose documentation is available in the source [21];
• STM32F103C8T6, whose documentation is available in the source [22];
• STM32F411CEU6, whose documentation is available in the source [23];
• RTL8710AF, whose documentation available in the source [24];
• ESP8266, whose documentation is available in the reference [25];
• ESP32, whose documentation is available in the source [26].

Based on the quantitative analysis performed in our research, we have identified the ESP32 as the most suitable candidate for implementing the BIKE algorithm on platforms with limited RAM capacity. This microcontroller combines sufficient computing power (dual-core, up to 240 MHz) with a relatively large SRAM capacity (520 kB) and a rich set of peripherals.

Although microcontrollers such as the ESP32 and ESP8266 operate at high clock frequencies (e.g., up to 240 MHz for ESP32), it should be noted that the frequency itself is not a reliable indicator of real computing performance. Computing performance is affected by several factors, such as the number and width of registers, instruction prefetching, wait states when accessing FLASH and RAM and the efficiency of the instruction set. For example, in the AVR architecture (used in the ATmega328 microprocessor), there is no prefetch or cache, and therefore the execution time of an instruction is directly proportional to the clock frequency, which can, in some cases, lead to more efficient processing of simple 8-bit operations. On the contrary, the ARM and Xtensa architectures, although powerful, introduce variability in latencies. In the case of the BIKE algorithm, which works mainly with 8-bit operations, the AVR architecture could theoretically achieve comparable performance even at a lower frequency. Nevertheless, the ESP32 microcontroller can be chosen as the most suitable platform because:

• It provides enough RAM (520 kB) and a large FLASH memory;
• It has sufficient computing power and the possibility of optimization on 32-bit registers;
• It is well supported within the software development kit (SDK) (ESP-IDF) and has rich documentation;
• Its wide availability and large developer community facilitate development and testing.

The second platform for testing was the ESP8266EX microprocessor, which has significantly less memory, but a similar development environment. By implementing the same algorithm on both platforms, its scalability and optimization potential can be tested.

5.3. Analysis of the Reference Implementation and Optimization Goals

The reference implementation of BIKE was originally designed for desktop platforms where memory resources and computational power are not significantly constrained. In such environments, it is possible to rely on external cryptographic libraries and dynamic memory allocation without major limitations.

However, the deployment of post-quantum cryptographic algorithms on IoT devices requires a careful analysis of the computational and memory requirements of the reference implementation. In particular, the ESP32 microcontroller provides approximately 520 kB of RAM, which must be shared between the application, the operating system, and networking components.

Therefore, before implementing the optimized version of the algorithm, it was necessary to analyze the main sources of computational complexity and memory consumption in the reference implementation.

A preliminary analysis of the reference implementation shows that several parts of the algorithm rely on large temporary buffers and external cryptographic libraries. These requirements create a gap between the resource requirements of the reference implementation and the capabilities of the target IoT platform. The following subsections therefore identify the most computationally and memory-intensive components that must be modified for deployment on the ESP32.

The analysis of the reference implementation revealed several components that significantly increase the computational and memory requirements of the algorithm.

First, the implementation relies on external cryptographic libraries such as OpenSSL. These libraries provide highly optimized cryptographic primitives but require a considerable amount of memory and are designed primarily for desktop and server environments.

Second, the implementation uses the Number Theory Library (NTL) for arbitrary precision arithmetic and polynomial operations. This library relies on dynamic memory allocation and complex data structures that are not suitable for embedded systems with limited RAM capacity.

Finally, the reference implementation uses large intermediate buffers and temporary arrays during the execution of the algorithm. These data structures can significantly increase the peak memory consumption during runtime.

When comparing the memory requirements of the reference implementation with the hardware capabilities of the ESP32, a clear gap becomes apparent. While the reference implementation assumes the availability of several megabytes of memory, the ESP32 platform provides only hundreds of kilobytes of RAM.

This gap between the requirements of the reference implementation and the capabilities of the target hardware platform defines the main objective of the optimization process.

The main goal of the optimization was therefore to redesign selected parts of the reference implementation in order to reduce memory consumption and eliminate dependencies on external libraries.

In particular, the optimization focused on the following aspects:

• Replacement of OpenSSL-based cryptographic primitives with lightweight embedded implementations;
• Replacement of NTL-based arithmetic with custom bit-level operations over GF(2);
• Reduction in temporary buffers and intermediate arrays;
• Elimination of dynamic memory allocation wherever possible.

At the beginning of the implementation process, we decided to start from the reference implementation of BIKE (https://bikesuite.org/files/v5.0/Reference_Implementation.2022.10.04.1.zip (accessed on 1 April 2026)). This is part of the official proposal submitted to the NIST standardization process. Our choice was motivated primarily by the credibility and correctness of the code, which directly reflects the formal specification of the algorithm and ensures consistency with the standard.

In addition, the reference implementation provides known test vectors and expected outputs. This significantly facilitates checking the correctness of outputs during implementation. Another advantage of the reference implementation is its modularity and code readability. Since the reference implementation serves directly to understand the given algorithm, thanks to its modularity and readability, it is easier to effectively identify those parts of the code that require modifications for deployment on a device with limited computing power and memory capacity. Using the reference implementation also allowed us to maintain compatibility with other BIKE implementations and avoid the need to develop the entire implementation from scratch.

Although the reference implementation provides a solid and reliable foundation, we must keep in mind that it is not directly intended for deployment on a processor with limited RAM capacity, such as the ESP32. It contains parts that require higher computing power and memory, or use external libraries (e.g., OpenSSL or NTL). These libraries are not suitable for embedded platforms. However, the advantage is that we can identify these parts and gradually replace them with more efficient, directly implemented alternatives with an emphasis on minimizing memory load, eliminating dynamic allocation, or reducing computational complexity. This possibility of targeted optimization was one of the reasons why we decided to start from the reference implementation and gradually modify it so that it meets the requirements of the low-level ESP32 platform, or even more memory-intensive ESP8266 platform.

The most computational and memory-intensive parts of the BIKE reference implementation that limit its deployment on the ESP32 and ESP8266 platforms include:

• OpenSSL library —OpenSSL is a robust and comprehensive toolkit for general-purpose cryptography and secure communications. The official documentation for the library is found in [27]. It is designed primarily for desktops and servers, which are significantly more powerful than the ESP32 microcontroller. Its implementation includes a number of functionalities that exceed the needs of common IoT applications, while also requiring high RAM and flash memory.
• NTL library—It is a high-performance and precise C++ library that provides data structures and algorithms for manipulating signed integers of arbitrary length and vectors, matrices, and polynomials over integers and finite fields. Its documentation is available in the source [28]. This library is designed for systems with sufficient computing power and memory resources, using dynamic memory allocation in the range of several megabytes. On the ESP32 platform, which has only a limited RAM and flash memory capacity, the compilation of the library itself would encounter the limits of the available memory. Another problem is that the NTL library makes extensive use of operations with large numbers, which in an environment with limited memory capacity can lead to significant slowdowns, memory fragmentation, and possible program crashes.
• Large number of variables, arrays, and macros—Minimizing the number of variables, fields, and macros is therefore a key measure to ensure a successful implementation. In order to achieve the most memory-efficient implementation, it is crucial to minimize the number of variables, large arrays, and macros. This has been achieved in the following ways:

  −

  Using shared buffers;

  −

  Using bit fields and masks;

  −

  By inserting (“in-place”) values;

  −

  By performing operations on arrays “in-place”;

  −

  By passing references to the array instead of allocating a new array within the function.

• Data types—The choice of appropriate data types has a significant impact on the speed of program execution and memory consumption. Using larger data types than necessary wastes RAM and flash memory and can unnecessarily increase the number of instructions needed to process the data. Optimizing the choice of data types is therefore essential for the successful deployment of PQC algorithms on devices with limited resources.
• Moving large arrays to the static part of memory or using a dynamic allocation—Storing large arrays in the static part of memory brings advantages in terms of stability and predictability of RAM consumption. Dynamic allocation of these arrays would increase the risk of memory fragmentation and allocation failures, especially if the available RAM is divided among multiple memory areas. In addition, placing large arrays in the static part allows the compiler to optimize access to them and eliminates the risk of not being able to allocate enough memory during specific algorithm calculations. This approach contributes to the stability of the program and its predictable behavior in a resource-constrained environment. In general, global variables, whether marked as static or not, are considered undesirable in well-designed code because they prevent functions reentrance and can unnecessarily block memory resources. In the context of our work, variables were defined as static solely for the purpose of measuring memory requirements. However, in the final solution, these fields were allocated dynamically or designed to minimize their global impact.
• Changing the granularity of function and adding the inline attribute—When implementing PQC on a processor with limited RAM, it is necessary to optimize not only the data structures, but also the way in which functions are organized and called. Changing the granularity of functions and appropriately adding the inline attribute allows you to reduce the overhead of calling functions and shortens the processing time of crucial sections. In an environment with limited computing capacity and RAM, even a small speedup of frequently repeated operations has a significant cumulative impact on the overall performance of the application.
  In addition, we can reduce the overhead by adding the attribute inline (https://en.cppreference.com/w/c/language/inline.html (accessed on 1 April 2026)). If the compiler inlines a function, it replaces the call to this function with its body, thus avoiding the overhead of calling a function. The purpose of the inline keyword is to serve as a tool for the compiler to perform optimization. When using it, however, it is important to remember that a non-static inline function cannot define a non-constant static function local to the function and cannot reference a static function at file scope.
• Function input parameter handling—In a microcontroller environment, incorrect or unexpected processing of function input parameters can lead not only to erroneous outputs, but also to a program crash or memory corruption. Since PQC algorithms work with large data structures and repeated calculations, even a small error in input processing can quickly accumulate. Therefore, consistent handling of input parameters is not only a matter of safe code, but also a key prerequisite for its stability and reliable operation on a device with limited resources.
• Efficient loop execution—Efficient loop execution can significantly affect the performance, memory consumption, and predictability of program behavior, especially for computationally intensive cryptographic operations. In the interest of working with loops as conveniently as possible, we had to follow these steps during implementation:

  −

  Replace all while and do-while loops with the more computationally efficient for loop;

  −

  Transform nested loops into simple loops by using a single loop $i<m\ast n$ instead of two loops $i<m$ and $j<n$;

  −

  Move all computations that are not necessarily in the loop outside the loop;

  −

  In some cases, loop unrolling, defined in article [29], can also improve the efficiency of loop execution.

• Disabling the watchdog timer—When implementing the PQC algorithm on the ESP32, it is necessary to take into account that some operations can be very time-consuming. If their calculation takes a long time, the watchdog timer will cause a system reset. The watchdog timer is defined in [30] as a hardware or software mechanism that serves to detect program blocking or failure. When implementing on ESP32 and ESP8266 microcontrollers using the official SDK, we often encounter the need to disable or change the configuration of the watchdog timer.

5.4. Adaptation of the BIKE Reference Implementation

The reference implementation of BIKE was originally designed for general-purpose computing platforms with sufficient computational power and memory resources. Such environments allow the use of external cryptographic libraries, dynamic memory allocation, and large intermediate data structures.

However, these assumptions are not valid for embedded IoT devices such as ESP32 or ESP8266 microcontrollers. In these environments, the available RAM is limited and the use of external libraries is often not feasible. Therefore, several parts of the reference implementation had to be modified in order to enable deployment on the target platforms.

The optimization process focused primarily on eliminating dependencies on external libraries and reducing the memory requirements of the algorithm.

5.4.1. Replacement of OpenSSL-Based Functions

The reference implementation relies on cryptographic primitives provided by the OpenSSL library. These functions are used mainly for hashing operations and other auxiliary cryptographic procedures. Although OpenSSL provides highly optimized implementations, its size and memory requirements make it unsuitable for deployment on embedded platforms.

For this reason, OpenSSL-based functions were replaced by lightweight implementations directly integrated into the ESP32 firmware. In particular, hash functions required by the BIKE algorithm were implemented using a compact implementation based on the Keccak permutation.

This modification significantly reduces both flash memory requirements and RAM consumption compared to the full OpenSSL library.

5.4.2. Replacement of NTL-Based Arithmetic

Another important dependency in the reference implementation is the NTL. NTL provides support for arbitrary precision integers and polynomial arithmetic over finite fields. However, this library relies heavily on dynamic memory allocation and complex data structures that require several megabytes of memory.

Such requirements exceed the capabilities of typical IoT devices. Therefore, the arithmetic operations originally implemented using NTL were replaced by custom implementations based on bit-level operations.

In the ESP32 implementation, polynomials over GF(2) are represented as fixed-size bit arrays. Arithmetic operations such as addition and multiplication are implemented using logical operations (XOR and AND) directly on these arrays. This approach eliminates the need for arbitrary precision integer arithmetic and significantly reduces memory usage.

5.4.3. Memory Usage Optimization

Another major modification involved the reduction in temporary buffers used during algorithm execution.

Algorithm 1 presents the polynomial multiplication over GF(2) used in the implementation.

The reference implementation allocates several large intermediate arrays during runtime. On memory-constrained devices such allocations can easily exceed available RAM.

Algorithm 1 Polynomial multiplication over GF(2)

for $i=0$ to $n-1$ do    for $j=0$ to $n-1$ do        $c[i+j]\leftarrow c[i+j]\oplus \left(a\right[i]\wedge b[j\left]\right)$    end for end for

To address this problem, several buffers were replaced by shared static memory regions that are reused across different parts of the algorithm. This approach significantly reduces the peak memory consumption of the implementation.

In addition, several operations were modified to perform computations directly on existing arrays using in-place operations. This further reduces the number of temporary variables and intermediate buffers required during the execution of the algorithm.

5.5. Implementation Changes

The reference implementation of BIKE, as provided within the NIST PQC project, is primarily designed for execution on desktop platforms. Such platforms typically offer abundant computational resources, dynamic memory allocation, and support for complex software dependencies. In contrast, an embedded system such as the ESP32 imposes strict constraints on available RAM, stack size, and execution time. Consequently, a direct deployment of the reference implementation of BIKE on the ESP32 platform is infeasible without substantial modifications.

This section describes the implementation changes applied to BIKE in order to enable its reliable execution on the ESP32 microcontroller. The presented modifications focuses on architectural restructuring, memory usage optimization, replacement of unsupported software dependencies, and adaptation of selected cryptographic primitives to the embedded environment. The goal of these changes is not to alter the cryptographic properties of BIKE, but to ensure functional correctness and practical feasibility under severe resource constraints.

5.5.1. Baseline Implementation and Platform Constrains

The reference implementation of BIKE assumes the availability of external cryptographic libraries, dynamic memory allocation, and large stack frames. These assumptions conflict with the ESP32 execution environment, where the available RAM is limited and shared between application code, runtime system, and network stack. Additionally, stack size per task is restricted, and excessive stack usage may result in runtime failures or watchdog timer resets.

Another significant limitation arises from the absence of certain libraries commonly used in desktop environments. In particular, libraries such as OpenSSL and NTL are not directly supported on the ESP32. As a result, cryptographic primitives and polynomial arithmetic routines relying on these libraries must be replaced or reimplemented using lightweight alternatives suitable for embedded platforms.

These constraints motivated a comprehensive redesign of the BIKE implementation, focusing on minimizing memory consumption, simplifying control flow, and ensuring deterministic execution.

5.5.2. Architectural Modifications

The first category of changes concerns the overall architecture of the implementation. The original modular structure of BIKE reference implementation was preserved where possible. However, several components were restructured to reduce overhead and improve compatibility with the ESP32.

External dependencies were eliminated. Hash functions, pseudo-random number generators, and polynomial arithmetic routines were reimplemented using self-contained modules. This approach ensures full control over memory allocation and eliminates hidden overhead introduced by third-party libraries.

Furthermore, the granularity of functions was adjusted. In the reference implementation, deeply nested function calls are frequently used to improve readability and modularity. On the ESP32, such nesting significantly increases stack usage. To mitigate this issue, several functions were inlined or merged, resulting in a flatter call graphs and reduced stack depth.

5.5.3. Memory Layout Optimization

Memory optimization represents the most critical aspects of the ESP32 adaptation. The reference implementation of BIKE makes extensive use of large temporary buffers allocated on the stack. On embedded platforms, this approach leads to stack overflows and unstable behavior.

To address this issue, large arrays and buffers were relocated from the stack to statically allocated memory regions. Static allocation ensures predictable memory usage and allows the maximum RAM footprint to be analyzed at compile time. Temporary buffers whose lifetime spans multiple function calls were converted into global or file-scope static variables.

Additionally, redundant memory allocations were eliminated by reusing buffers across multiple algorithmic phases where possible. This required careful analysis of data dependencies to avoid unintended overwrites while maintaining correctness.

The applied memory layout changes significantly reduced peak stack usage and enabled stable execution of all BIKE phases on the ESP32.

5.5.4. Hash Function and Pseudo-Random Number Generation

Hash functions and pseudo-random number generation are central components of BIKE. The reference implementation relies on cryptographic hash primitives provided by external libraries, which are unsuitable for embedded deployment.

In the ESP32 implementation, hash function wrappers were introduced to provide a uniform interface for hashing. These wrappers internally rely on lightweight implementations compatible with the ESP32 environment. The Secure Hash Algorithm Keccak (SHAKE) extendable-output function was used both for hashing as a pseudo-random number generator, ensuring consistency with the BIKE specification.

Special attention was paid to the deterministic behavior of the pseudo-random number generator. In embedded systems, entropy sources are often limited or unavailable. The implementation, therefore, carefully controls seeding and output generation to maintain reproducibility during testing while preserving cryptographic correctness.

5.5.5. Polynomial Arithmetic and Modular Inversion

Polynomial arithmetic over binary arrays constitutes one of the most computationally intensive components of BIKE. The reference implementation relies on the NTL library for polynomial operations and modular inversion. Since NTL is not available on the ESP32, these operations were reimplemented using custom routines.

The modular inversion procedure was adapted to minimize memory usage and intermediate storage. Iterative algorithms with predictable execution flow were preferred over recursive approaches to reduce stack consumption. All polynomial operations were implemented using fixed-size arrays, avoiding dynamic allocation entirely.

These changes result in a moderate increase in execution time compared to the optimized desktop implementation. However, they significantly reduce memory requirements and ensure reliable execution on the ESP32.

5.5.6. Sampling and Decoding Adjustments

The sampling and decoding stages of BIKE involve frequent manipulation of bit-level representations and repeated iteration over large data structures. In the embedded context, inefficient loop structures may trigger watchdog timers or exceed acceptable execution times.

To mitigate this risk, loop structures were carefully optimized. Unnecessary conditional checks were removed, and loop bounds were explicitly defined to enable compiler optimizations. Where applicable, operations were reordered to improve data locality and reduce memory access overhead.

The decoding procedure was similarly optimized to avoid repeated recomputation of intermediate values. These modifications preserve the functional behavior of the algorithm while improving its suitability for real-time embedded execution.

5.5.7. Integration into the KEM

Following the implementation of the individual components, the modified routines were integrated into the complete BIKE key encapsulation mechanism workflow. This includes key generation, encapsulation, and decapsulation.

Each phase was tested independently to verify correctness before integration. Particular attention was paid to ensuring that intermediate data structures are reused safely across phases without unintended side effects. Execution time of individual phases was monitored to ensure that watchdog timers are not triggered during prolonged computations.

The final integrated implementation successfully performs all KEM operations on the ESP32 without runtime failures, demonstrating the practical feasibility of BIKE under embedded constraints.

5.5.8. Summary of Implementation Impact

The implementation changes described in this section enable the execution of the BIKE key encapsulation mechanism on the ESP32 microcontroller, despite its limited computational and memory resources. The modifications focus on architectural simplification, memory layout optimization, and replacement of unsupported dependencies, while preserving the cryptographic integrity of the reference implementation of this algorithm.

These changes form the foundation for experimental evaluation presented in the subsequent sections and demonstrate that post-quantum cryptographic algorithms can be adapted for deployment in resource-constrained IoT environments.

6. Discussion

This section discusses the practical implications of deploying BIKE on memory-constrained IoT devices, with a particular focus on the ESP32 platform. The results highlight key trade-offs between feasibility, performance, and resource utilization that are critical for embedded post-quantum cryptographic deployments.

6.1. Feasibility of BIKE on ESP32

The presented results confirm that direct deployment of the reference implementation of BIKE on the ESP32 is not feasible due to excessive memory consumption and reliance on unsupported software dependencies. Stable execution of all BIKE phases was achieved only after substantial architectural and memory-related modifications.

This outcome demonstrates that the practical deployment of post-quantum cryptography on IoT devices requires platform-specific adaptations. Feasibility is not determined by algorithmic properties alone but by interaction between the algorithm and the underlying system architecture.

6.2. Memory as the Primary Limiting Factor

Memory consumption was identified as the dominant constraint in the ESP32 environment. While execution time remains relevant, peak RAM usage and stack footprint represent hard limits that directly affect system stability. Stack overflows result in immediate runtime failures, making memory optimization a prerequisite for functional deployment.

The relocation of large data structures to statically allocated memory and the reduction in temporary buffers proved essential. These findings suggest that peak memory usage should be considered a primary evaluation metric for PQC implementations on embedded platforms, alongside traditional performance measurements.

6.3. Performance–Feasibility Trade-Offs

The applied implementation changes introduce moderate performance penalties, particularly in polynomial arithmetic and modular inversion. However, these trade-offs are justified by the resulting deterministic behavior and predictable memory usage.

In the embedded context, a reliable but slower implementation is preferable to an optimized solution that cannot be executed within platform constraints. This highlights a fundamental difference between desktop-oriented and embedded-oriented cryptographic implementations, where predictability and feasibility often outweigh raw performance.

6.4. Implementations for PQC Selection in IoT

The results indicate that although BIKE possesses favorable cryptographic properties, it is not inherently optimized for embedded environments. Significant implementation effort is required to adapt the algorithm for practical IoT deployment.

These findings emphasize that the selection of PQC algorithms for IoT applications must account for implementation complexity and memory requirements, not solely theoretical security or computational efficiency. Practical deployability should therefore be treated as a key criterion in post-quantum cryptography standardization efforts.

6.5. Limitations and Future Work

This study is limited to the ESP32 platform, and the results cannot be directly generalized to all embedded systems. Additionally, aspects such as side-channel resistance and energy consumption were not evaluated and remain an important direction for future research.

Further work should explore deployment on additional microcontroller architectures, investigate energy-efficient optimizations, and consider hybrid cryptographic approaches that combine classical and post-quantum primitives for IoT systems.

6.6. Performance Evaluation of the Optimized Implementation

To evaluate the feasibility of deploying the optimized BIKE implementation on resource-constrained devices, the algorithm was executed on the ESP32 microcontroller and compared with the original reference implementation running on a desktop platform.

The reference implementation was executed on a desktop computer equipped with an Intel Core i5 processor operating at 2.9 GHz and 8 GB of RAM. The optimized implementation was executed on the ESP32 microcontroller running at 240 MHz with approximately 520 kB of available RAM.

The evaluation focused on three main metrics: execution time, stack usage, and total RAM consumption. The execution time was measured separately for the three main KEM operations: key generation, encapsulation, and decapsulation.

Stack usage was analyzed using compiler-assisted static analysis with the GCC compiler option -fstack-usage. The call graph analysis was then used to estimate the worst-case stack consumption along the critical execution paths of the algorithm.

The execution time results for the optimized BIKE implementation are presented in

Table 4. Performance of the optimized BIKE implementation on the ESP32 platform.

Operation	Desktop Runtime	ESP32 Runtime (Mean ± Std)
Key generation	12 ms	3.2 ± 0.1 s
Encapsulation	9 ms	2.4 ± 0.1 s
Decapsulation	14 ms	3.8 ± 0.1 s

.

The memory requirements of the optimized implementation are summarized in

Table 5. Memory requirements of the optimized BIKE implementation on the ESP32 platform.

Operation	Stack Usage	Total RAM Usage
Key generation	28 kB	180 kB
Encapsulation	24 kB	170 kB
Decapsulation	32 kB	190 kB

.

The reported values represent the mean execution times obtained from 100 repeated measurements. The standard deviation is also provided to reflect the variability of the results.

The reported total RAM usage (170–190 kB) corresponds to the ESP32 platform. These values exceed the available RAM capacity of the ESP8266 microcontroller and therefore cannot be achieved on that platform.

The results show that the optimized implementation can be executed on the ESP32 microcontroller within the available memory limits. Although the execution time on the embedded platform is naturally higher compared to the desktop environment, the obtained results demonstrate that the BIKE algorithm can be deployed even on devices with limited computational resources and memory capacity.

The memory optimizations described in the previous sections significantly reduced the peak RAM consumption of the implementation, allowing the algorithm to operate within the memory constraints of the ESP32 platform.

6.7. Security and Energy Considerations

In addition to computational performance and memory consumption, practical deployment of post-quantum cryptographic algorithms on IoT devices must also consider security and energy efficiency aspects. From the security perspective, it is important to note that although post-quantum algorithms such as BIKE provide resistance against quantum attacks, their practical implementations may still be vulnerable to side-channel attacks. Resource-constrained devices such as microcontrollers are particularly sensitive to timing attacks, power analysis, or fault injection. Therefore, careful implementation techniques and constant-time programming practices should be considered when deploying post-quantum cryptography on embedded platforms.

Another important aspect for IoT deployments is energy consumption. Many IoT devices operate on battery power and are expected to function for long periods without maintenance. Although this work primarily focuses on execution time and memory consumption, these parameters are closely related to the overall energy usage of the device. Reducing computational complexity and memory access operations can contribute to lower energy consumption. Future work will therefore include detailed measurements of energy usage and investigation of further optimization techniques for low-power embedded environments.

7. Conclusions

In our previous research, we found that BIKE is the most suitable candidate for deployment on small processors. Our selection resulted from a systematic comparison with other candidates. BIKE offered the best compromise between computational and memory requirements. In an environment where resources are limited to a few tens of kilobytes of RAM, even a small reduction in memory consumption is of fundamental importance. The choice of algorithms was in line with the aim of our work and allowed us to verify the feasibility of deploying PQC on small processors with limited RAM capacity.

From the currently used small processors in the IoT, we chose the ESP32. In practice, it is used in smart homes to control lighting, air conditioning, or security systems, in industrial sensor networks, or in devices monitoring energy consumption. Due to advantages such as low price, integrated Wi-Fi, and low power consumption, it is popular in prototyping and development of commercial IoT products. Successful implementation of the PQC on this processor can lead to the deployment of PQC on many devices that are used daily. When designing the implementation of BIKE on the ESP32, we started from the reference implementation. We step by step modified those parts of the code that prevented it from running on the ESP32. We removed its dependency on the OpenSSL and NTL libraries, minimized the number of variables, fields, and macros, used smaller data types for variables, adjusted the granularity of functions, and added an inline attribute to some, treated the input parameters of functions, and implemented loops to make their execution more efficient. Implementation of some sub-processes, such as hashing or modular inversion, was replaced by more efficient approaches that maintain equivalence with the reference implementation, but are programmed to meet the requirements of the low-level ESP32 platform. These changes allowed not only the algorithm to run, but also the stable operation of all three phases of the KEM mechanism.

The result of our work is an implementation of BIKE, the functionality of which is fully equivalent to the reference implementation, but thanks to the use of different programming approaches, it is also executable on the low-level platform ESP32. With this implementation, we have proven that the PQC algorithm can be used on a small processor with limited RAM capacity. This implementation can be deployed on multiple communication protocols, including SSL/TLS, SSH, IPSec, WireGuard, S/MIME, and OpenPGP. These protocols are used by a wide range of devices and applications, including smart sensors, industrial control units, and mobile and cloud services. The need to protect sensitive data in a wide range of industries—including public administration, healthcare, education, and the financial sector—points to the need to deploy PQC that can withstand attacks from quantum computers and, at the same time, ensure long-term confidentiality and integrity of transmitted data. In our work, we presented a time- and memory-optimized version of BIKE, which can be deployed on a wide range of devices on which PQC is currently not implemented.