Author: Peter Pekarčík PhD. · Post-Quantum Cryptographer at Decent Cybersecurity
1. Introduction
The advent of quantum computing represents a fundamental threat to current asymmetric cryptographic systems. Algorithms such as RSA, DSA, and ECDH (respectively ECC) are vulnerable to Shor’s algorithm [1], which enables, on a sufficiently powerful quantum computer, efficient solutions to both the integer factorization problem and the discrete logarithm problem in polynomial time. According to estimates by Mosca [2], there is a probability exceeding 17 % that a quantum computer capable of compromising current cryptosystems will be available by 2033.
The National Institute of Standards and Technology (NIST) completed the standardization of the first post-quantum cryptographic (PQC) algorithms in August 2024 [4]. The standard for key exchange has become FIPS 203 – ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism) [3], based on the CRYSTALS-Kyber algorithm. In parallel, European standardization efforts are ongoing within the ETSI QSC project [5].
This paper analyzes three specific implementations of the ML-KEM algorithm (the standardized version of CRYSTALS-Kyber) from the perspective of performance and suitability for real-world deployment. The analyzed implementations are:
- Bouncy Castle (Java),
- CIRCL (Go),
- liboqs (C, Open Quantum Safe).
For each implementation, the execution times of core operations (KeyGen, Encaps, Decaps) and memory consumption (RSS) were measured. Each measurement is documented using real experimental output. Based on the obtained results, practical deployment scenarios for the individual implementations are subsequently proposed.
2. Tested Implementations
2.1 Bouncy Castle
Bouncy Castle is one of the most widely used cryptographic libraries for the Java platform and the JVM. It provides implementations of more than 200 cryptographic algorithms, including the post-quantum algorithm ML-KEM (CRYSTALS-Kyber). Documentation and source code are available in [6].
The basic technical parameters of the evaluated implementation are as follows:
- Version: bcprov-jdk18on-1.78.jar (Bouncy Castle Provider 1.78)
- Language / Platform: Java 18 (JVM runtime)
- Algorithm: ML-KEM-768 (based on Kyber-768), security level 3
- Benchmarking tool: KyberBenchmark – custom benchmark, 1,000 iterations
- Memory measurement: /usr/bin/time -v with explicit JVM parameters -Xms64m, -Xmx64m
- Resources: https://www.bouncycastle.org/ and https://github.com/bcgit/bc-java
2.2 CIRCL
CIRCL (Cloudflare Interoperable Reusable Cryptographic Library) is a cryptographic library for the Go programming language, focused on modern and post-quantum cryptographic primitives. It implements the ML-KEM algorithm in accordance with the FIPS 203 standard [7]. The basic technical parameters of the evaluated implementation are as follows:
- Version: github.com/cloudflare/circl
- Language / Platform: Go 1.22
- Algorithm: ML-KEM-768 (directly compliant with the FIPS 203 standard)
- Benchmarking tool: mlkem_bench – custom Go benchmark, 10,000 iterations
- Memory measurement: /usr/bin/time -v, native Go binary mlkem_mem
- Resources: https://blog.cloudflare.com/introducing-circl/ and https://github.com/cloudflare/circl
2.3 liboqs (Open Quantum Safe, C)
The liboqs library is an open-source library written in C, developed by the Open Quantum Safe (OQS) project. It implements a broad collection of post-quantum algorithms, including both standardized and experimental NIST schemes, as well as alternative constructions such as BIKE, Classic McEliece, NTRU, FrodoKEM, and others.
The basic technical parameters of the evaluated implementation are as follows:
- Version: 0.15.0 (major: 0, minor: 15, patch: 0, git 8509387)
- Language / Platform: C (gcc 13.3.0), x86_64 Linux (kernel 6.17.0-14-generic)
- Compilation options: OQS_DIST_BUILD, OQS_LIBJADE_BUILD, OQS_OPR_TARGET=generic, CMAKE_BUILD_TYPE=Release
- CPU extensions: ADX, AES, AVX, AVX2, BMI1, BMI2, PCLMULQDQ, POPCNT, SSE, SSE2, SSE3
- OpenSSL: 3.0.13 (30 Jan 2024), SHA-2: OpenSSL, SHA-3: AVX
- Algorithms: speed_kem – a wide range of PQC algorithms, each benchmarked for 3 seconds
- Resources: https://openquantumsafe.org/ and https://github.com/open-quantum-safe/liboqs
These three implementations represent three distinct approaches to post-quantum cryptography: the JVM-based ecosystem (Bouncy Castle), a modern cloud-native approach (CIRCL), and a low-level, highly optimized implementation in the C language (liboqs).
3. Methodology
All experiments were conducted on the same hardware platform (Acer Aspire AG16-71P) running the Linux operating system (kernel 6.17.0-14-generic) with an Intel Core i7 processor. Each test was repeated five times under identical conditions without any concurrent background workloads.
Table 1: Comparison of testing methodology
| Parameter | Bouncy Castle | CIRCL (Go) / liboqs (C) |
| Operating system | Linux (kernel 6.17.0-14-generic, Ubuntu) | Linux (kernel 6.17.0-14-generic, Ubuntu) |
| Language / runtime | Java 18 (JVM; -Xms64m, -Xmx64m) | Go 1.22 (gcc 13.3.0) |
| Benchmarking tool | /usr/bin/time -v + KyberBenchmark | /usr/bin/time -v + mlkem_bench, speed_kem |
| Number of iterations | 1,000 | 10,000 (CIRCL), ≈ 3 s/alg. |
| Number of repetitions | 5 | 5 |
| Measured operations | KeyGen, Encaps, Decaps | KeyGen, Encaps, Decaps |
| Memory metric | Maximum Resident Set Size (RSS) | Maximum Resident Set Size (RSS) |
The Bouncy Castle implementation runs on the JVM with a fixed heap size (64 MB), which directly affects the measured RSS values. In contrast, the CIRCL and liboqs implementations are native binaries with significantly lower runtime overhead. Therefore, direct comparison of RSS values between Java-based and native implementations must be interpreted with consideration of this architectural difference. The proposed methodology ensures reproducibility and comparability of results and enables a fair evaluation of the individual implementations.
4. Results
4.1 Bouncy Castle – Results
4.1.1 Operation Times (Kyber-768, 1,000 iterations)
The evaluated algorithm is ML-KEM-768 (equivalent to Kyber-768) (security level 3, equivalent to AES-192).
Command: java -cp .:bcprov-jdk18on-1.78.jar KyberBenchmark. The output of the bench-mark is shown in Figure 1.
Pic. 1: Benchmark output for Bouncy Castle (run 1)
Table 2: Bouncy Castle – operation times
| Run | KeyGen (μs) | Encaps (μs) | Decaps (μs) | sink |
| 1 | 77.065 | 87.197 | 92.821 | 12 |
| 2 | 75.431 | 75.912 | 89.896 | 199 |
| 3 | 79.251 | 82.192 | 97.541 | 173 |
| 4 | 75.066 | 76.344 | 91.757 | 120 |
| 5 | 86.989 | 90.193 | 108.994 | 130 |
| Average | 78.76 | 82.37 | 96.20 | – |
| Min | 75.07 | 75.91 | 89.90 | – |
| Max | 86.99 | 90.19 | 108.99 | – |
4.1.2 Memory Consumption of Operations (RSS, Kyber-768, 1,000 iterations)
Measurements were performed using the command /usr/bin/time -v java -Xms64m -Xmx64M -cp .:bcprov-jdk18on-1.78.jar KyberBenchmark. The baseline corresponds to an empty JVM startup.
Pic. 2: Bouncy Castle, memory run 1: Baseline – empty JVM startup
Pic. 3: Bouncy Castle, memory run 1: Maximum Resident Set Size with KyberBenchmark
Table 3: Bouncy Castle – memory consumption
| Run | Baseline RSS [kB] | Max RSS [kB] | Delta RSS [kB] | Time [s] |
| 1 | 39 508 | 110 636 | 71 128 | 49 |
| 2 | 39 820 | 107 884 | 68 064 | 46 |
| 3 | 39 588 | 109 944 | 70 356 | 51 |
| 4 | 39 516 | 111 132 | 71 616 | 47 |
| 5 | 39 516 | – | – | – |
| Average | 39 590 | ~109 900 | ~70 300 | ~0:00:48 |
The JVM itself (without the PQC benchmark code) consumes approximately ~39.5 MB of RSS. The actual overhead of PQC operations corresponds to a delta of approximately ~70 MB for 1,000 iterations.
4.2 CIRCL – Results
4.2.1 Operation Times
The evaluated algorithm is ML-KEM-768 (security level 3, equivalent to AES-192).
Command: ./mlkem_bench
Obr. 4: CIRCL, run 1: output of mlkem_bench (10,000 iterations)
Table 4: CIRCL – operation times
| Run | KeyGen [μs] | Encaps [μs] | Decaps [μs] | sink |
| 1 | 30.732 | 13.213 | 19.762 | 159 |
| 2 | 30.815 | 13.129 | 19.808 | 142 |
| 3 | 29.728 | 12.883 | 19.219 | 126 |
| 4 | 29.852 | 12.900 | 19.316 | 1 |
| 5 | 31.164 | 13.232 | 19.976 | 143 |
| Average | 30.46 | 13.07 | 19.62 | |
| Min | 29.73 | 12.88 | 19.22 | |
| Max | 31.16 | 13.23 | 19.98 |
4.2.2 Memory Consumption
Measurements were performed using the command /usr/bin/time -v ./mlkem_mem. The baseline corresponds to an empty Go binary (baseline_go).
Pic. 5: CIRCL, memory run 1: Baseline – empty Go binary
Pic. 6: CIRCL, memory run 1: Maximum Resident Set Size with mlkem_mem
Table 5: CIRCL – memory consumption
| Run | Baseline RSS [kB] | Max RSS [kB] | Delta RSS [kB] | Time [s] |
| 1 | 1,240 | 7,604 | 6,364 | 6.12 |
| 2 | 1,240 | 7,528 | 6,288 | 6.06 |
| 3 | 1,240 | 7,488 | 6,248 | 6.11 |
| 4 | 1,240 | 7,824 | 6,584 | 6.11 |
| 5 | 1,240 | 7,592 | 6,352 | 6.11 |
| Average | 1,240 | 7,607 | 6,367 | 6.10 |
4.3 liboqs – Results
4.3.1 Operation Times
The liboqs library enables benchmarking of the entire family of PQC algorithms using the tool ./tests/speed_kem. Each algorithm is measured over a period of 3 seconds. The following figures present three screenshots from run 1, covering the complete output:
Pic. 7: liboqs, run 1, page 1/3: BIKE and Classic McEliece (speed_kem output)
Pic. 8: liboqs, run 1, page 2/3: BIKE and Classic McEliece (speed_kem output)
Pic. 9: liboqs, run 1, page 3/3: BIKE and Classic McEliece (speed_kem output)
The following table summarizes the average results of five runs for selected key algorithms:
Table 6: liboqs – overview of operation times
| Algorithm | KeyGen (μs) | Encaps (μs) | Decaps (μs) | Category |
| Kyber512 / ML-KEM-512 | 7.57 | 9.79 | 7.07 | 1 (AES-128) |
| Kyber768 / ML-KEM-768 | 17.63 | 16.06 | 10.97 | 3 (AES-192) |
| Kyber1024 / ML-KEM-1024 | 15.88 | 20.13 | 15.23 | 5 (AES-256) |
| ML-KEM-512 | 7.02 | 7.82 | 9.27 | 1 (AES-128) |
| ML-KEM-768 | 11.42 | 12.02 | 14.42 | 3 (AES-192) |
| ML-KEM-1024 | 15.68 | 16.63 | 20.06 | 5 (AES-256) |
| NTRU-HPS-2048-509 | 34.14 | 5.23 | 7.93 | 1 (AES-128) |
| NTRU-HPS-2048-677 | 54.86 | 7.45 | 11.18 | 3 (AES-192) |
| FrodoKEM-640-AES | 467.35 | 644.21 | 615.47 | 1 (AES-128) |
| FrodoKEM-976-AES | 467.35 | 644.21 | 615.47 | 3 (AES-192) |
| BIKE-L1 | 165.14 | 34.73 | 559.19 | 1 (AES-128) |
| Classic-McEliece-348864 | 34 983 | 13.39 | 126.31 | 1 (AES-128) |
| Classic-McEliece-8192128 | 178 655 | 50.01 | 180.74 | 5 (AES-256) |
The reported values represent arithmetic averages over five runs of speed_kem. Classic McEliece exhibits extremely slow key generation, but relatively fast encapsulation and decapsulation. FrodoKEM is consistently slow across all operations. In contrast, ML-KEM (Kyber) provides the best overall performance balance.
4.3.2 Memory Consumption
Memory consumption was measured using the commands /usr/bin/time -v ./mlkem_mem_test and /usr/bin/time -v ./memory_test_baseline.
Pic. 10: liboqs, memory, beh 1 – prázdny binary memory_test_baseline
Pic. 11: liboqs, memory, beh 1: Maximum Resident Set Size s mlkem_mem_test
Table 7: liboqs – memory consumption
| Run | Baseline RSS (kB) | Max RSS (kB) | Delta RSS (kB) | Time [s] |
| 1 | 1 180 | 6 388 | 5 208 | 3.87 |
| 2 | 1 176 | 6 516 | 5 340 | 3.86 |
| 3 | 1 176 | 6 516 | 5 340 | 3.88 |
| 4 | 1 180 | 6 516 | 5 336 | 3.86 |
| 5 | 1 180 | 6 516 | 5 336 | 3.87 |
| Average | 1 178 | 6 490 | 5 312 | 3.87 |
5. Comparative Analysis of Results
5.1 Comparison of ML-KEM-768 Operation Times
All three implementations evaluate ML-KEM-768 (or the equivalent Kyber-768 algorithm), corresponding to the same security level 3. A comparison of the average values is presented in the following table:
Table 8: Comparison of ML-KEM-768 operation times
| Implementation | KeyGen (μs) | Encaps (μs) | Decaps (μs) | Iterations |
| Bouncy Castle (Java) | 78.76 | 87.37 | 96.20 | 1,000 |
| CIRCL (Go) | 30.46 | 13.07 | 19.62 | 10,000 |
| liboqs / Kyber768 (C) | 17.63 | 16.06 | 10.97 | ≈ 3 s |
| liboqs / ML-KEM-768 (C) | 11.42 | 12.02 | 14.42 | ≈ 3 s |
Based on the conducted measurements, the following conclusions can be drawn:
- liboqs (C) achieves the highest performance: ML-KEM-768 reaches a KeyGen time of approximately 11 μs, which is 2.7× faster than CIRCL and 6.9× faster than Bouncy Castle. This advantage stems from the use of highly optimized native C code with AVX2 instructions.
- CIRCL (Go) significantly outperforms Bouncy Castle: Encapsulation requires 13 μs compared to 82 μs (6× faster), while decapsulation requires 20 μs compared to 96 μs (4.9× faster). The Go compiler produces efficient native code without the overhead associated with the JVM.
- Bouncy Castle exhibits the highest variability: The spread of values across runs is larger (75–87 μs for KeyGen), which is typical for JVM-based environments due to JIT compilation and garbage collection.
- liboqs provides two variants: Kyber768 (original implementation) and ML-KEM-768 (fully aligned with the FIPS 203 standard). The ML-KEM-768 KeyGen is approximately 1.5× faster than Kyber768, reflecting optimizations introduced during standardization.
5.2 Comparison of Memory Consumption
Table 9: Comparison of memory consumption
| Implementation | Baseline RSS [kB] | Max RSS [kB] | Delta RSS [kB] |
| Bouncy Castle (Java) | ~39,590 | ~109,900 | ~70,310 |
| CIRCL (Go) | 1,240 | ~7,607 | ~6,367 |
| liboqs (C) | ~1,178 | ~6,490 | ~5,312 |
Bouncy Castle requires significantly more memory, primarily due to JVM overhead. Native implementations (Go, C) exhibit comparable memory usage at approximately ~6–7 MB, which is highly suitable for both embedded and server-side deployment scenarios.
5.3 Summary of Advantages and Disadvantages
Table 10: Summary of advantages and disadvantages of the evaluated implementations
| Criterion | Bouncy Castle | CIRCL | liboqs |
| Language | Java / JVM | Go | C |
| Performance | Low | Moderate | Highest |
| Memory usage | High (~100 MB) | Low (~7.6 MB) | Lowest (~6.5 MB) |
| Portability | Excellent (JVM) | Good (Go cross-compilation) | Good (C99, CMake) |
| Integration (Java / JVM) | Native | Via cgo / bindings | Via JNI / JNA |
| Algorithm coverage | ML-KEM, other PQC | ML-KEM, ML-DSA, etc. | ~30+ PQC algorithms |
| Compliance with FIPS 203 | Kyber (pre-standard) | ML-KEM (FIPS 203) | Kyber + ML-KEM |
| Certification / audit | FIPS 140-3 candidate | Production use (Cloudflare) | OQS, academic review |
| Suitability for embedded | No (JVM) | Conditional | Yes |
6. Proposed Real-World Deployment Scenarios
Based on the experimental results, we propose ten representative real-world deployment scenarios for post-quantum cryptographic implementations. Each scenario is defined with a specific objective, methodology, and relevant standardization references.
6.1 Scenario 1 – VPN with Post-Quantum Key Exchange
Objective: Integrate ML-KEM into an existing VPN protocol (e.g., WireGuard or IPsec IKEv2) and evaluate its impact on performance and latency.
Methodology: Implement a hybrid key exchange mechanism (X25519 + ML-KEM-768) between two network nodes. Measure handshake latency, encrypted tunnel throughput, and CPU overhead under varying traffic conditions (idle, 10 Mbps, 1 Gbps).
Tools: WireGuard-Go with CIRCL integration, strongSwan with liboqs plugin
Metrics: handshake latency [ms], CPU utilization [%], throughput [Mbps], MTU impact
References: NIST SP 800-135r1 [8], IETF draft-ipsecme-ikev2-pqc [9]
6.2 Scenario 2 – VoIP with SRTP Encryption and ML-KEM
Objective: Evaluate the feasibility of PQC in real-time voice communication (SRTP/DTLS-SRTP), where key exchange latency is critical (< 100 ms).
Methodology: Integrate ML-KEM into the DTLS 1.3 handshake for SIP/SRTP. Conduct call scenarios with different codecs (e.g., G.711, Opus) and measure jitter, packet loss, and overall key exchange latency.
Tools: Baresip / Kamailio with liboqs-OpenSSL provider; Wireshark for packet analysis
Metrics: DTLS handshake time [ms], RTP jitter [ms], MOS score, CPU overhead
References: RFC 5764 (DTLS-SRTP) [10], IETF draft-ietf-tls-hybrid-design [15]
6.3 Scenario 3 – AP / Router Network Communication and Wi-Fi Handshake
Objective: Evaluate the deployment of PQC in Wi-Fi network environments (WPA3-Enterprise with EAP-TLS) and routers with constrained computational resources (MIPS/ARM processors).
Methodology: Configure hostapd with the OQS-OpenSSL provider on a Raspberry Pi 4 (ARM Cortex-A72). Measure the EAP-TLS handshake using both classical (ECDH) and post-quantum (ML-KEM) cryptographic suites.
Tools: hostapd 2.10+, wpa_supplicant, OQS-OpenSSL 3.x provider
Metrics: EAP-TLS handshake time [ms], maximum concurrent associations/s, CPU load [%], memory footprint
References: IEEE 802.11-2020 [12], WPA3 Specification v3.0 (Wi-Fi Alliance) [13]
6.4 Scenario 4 – Large File Distribution with PQ Encryption
Objective: Measure the overhead of PQC in encrypting and distributing large data files (> 1 GB) in CDN or object storage environments.
Methodology: Implement PQ-TLS 1.3 (X25519 + ML-KEM-768) on both client and server sides. Transfer files of sizes 100 MB, 1 GB, and 10 GB, and measure overall throughput and CPU overhead. Compare implementations based on Bouncy Castle and liboqs.
Tools: curl with OQS-OpenSSL, nginx with liboqs-nginx, custom Java client using Bouncy Castle
Metrics: throughput [Mbps], TLS handshake time [ms], CPU usage per GB, memory footprint
References: RFC 8879 (TLS Certificate Compression) [14], IETF draft-ietf-tls-hybrid-design [15]
6.5 Scenario 5 – TLS 1.3 Web Server with Hybrid PQC
Objective: Evaluate the performance and compatibility of PQ-TLS 1.3 in a production web environment under realistic load conditions (HTTP/2, HTTP/3).
Methodology: Deploy nginx / Apache with the OQS-OpenSSL provider. Perform load testing using wrk/locust with 100–10,000 concurrent connections. Measure TLS handshake latency, RPS (requests per second), and compare the results with classical ECDH.
Tools: OQS-nginx, oqs-demos Docker images [16], wrk, k6
Metrics: handshake latency p50/p95/p99, RPS, CPU utilization, error rate
References: IETF RFC 8446 (TLS 1.3) [17], Cloudflare PQ TLS blog [18]
6.6 Scenario 6 – Email Communication with PQ Encryption
Objective: Evaluate the integration of ML-KEM into asymmetric email encryption (S/MIME or OpenPGP) and its impact on message size and processing time.
Methodology: Extend Bouncy Castle with PQ S/MIME support (hybrid RSA/ECDH + ML-KEM). Measure header size, encryption and decryption time for messages of varying sizes (1 kB–10 MB attachments), and compatibility with existing email clients.
Tools: Bouncy Castle S/MIME API, Thunderbird + Enigmail, RFC 9629 (KEMRecipientInfo)
Metrics: CMS envelope size (B), encryption/decryption time [ms], MIME compatibility
References: RFC 9629 – Using KEMs in CMS [19], draft-ietf-openpgp-pqc [20]
6.7 Scenario 7 – IoT / Embedded Communication
Objective: Evaluate the feasibility of ML-KEM-512 in IoT environments on devices with constrained computational resources and memory (ESP32, STM32).
Methodology: Evaluate liboqs on ESP32 (Xtensa LX6, 520 kB RAM). Implement PQ-DTLS 1.3 for MQTT-SN. Measure energy consumption (mW), handshake time, and memory footprint.
Tools: liboqs, wolfSSL on ESP32-IDF, Mosquitto broker, MQTT benchmark
Metrics: handshake time [ms], RAM usage [kB], flash size [kB], energy consumption [mJ/handshake]
References: NISTIR 8425 [21], RFC 7252 (CoAP) [22]
6.8 Scenario 8 – PKI / Certification Authority with PQ Certificates
Objective: Evaluate issuance, validation, and revocation of PQ X.509 certificates (ML-KEM + ML-DSA) within a PKI infrastructure.
Methodology: Deploy EJBCA or OpenSSL CA with PQ extensions. Measure certificate issuance time, certificate size [B], and OCSP response latency. Compare RSA-4096 with ML-DSA + ML-KEM.
Tools: EJBCA Community with OQS-OpenSSL, OpenSSL with oqs-provider
Metrics: certificate issuance time [ms], certificate size [B], OCSP latency [ms], CRL size [kB]
References: RFC 5280 (X.509 PKI) [23], draft-ietf-lamps-dilithium-certificates [24]
6.9 Scenario 9 – Database Replication and Backend-to-Backend TLS
Objective: Evaluate the impact of PQ-TLS on database replication performance and microservice communication (gRPC, REST) in internal networks with short-lived connections.
Methodology: Configure PostgreSQL replication over PQ-TLS 1.3. Evaluate gRPC communication using PQ-based handshakes. Measure overhead in short-lived TLS connections, where the handshake constitutes a significant portion of the total operation time.
Tools: PostgreSQL 16 with oqs-openssl, grpc-java with Bouncy Castle, Prometheus/Grafana
Metrics: replication latency [ms], TLS handshake overhead vs. payload, RPS, error rate
References: NIST SP 800-52r2 (TLS implementation) [25]
6.10 Scenario 10 – SSH with Post-Quantum Key Exchange
Objective: Evaluate the integration of ML-KEM into the SSH protocol (OpenSSH) and measure its impact on connection establishment time, SCP/SFTP throughput, and compatibility with existing infrastructure.
Methodology: Compile OpenSSH with the OQS-OpenSSH patch. Evaluate SSH clients/servers using hybrid kex (sntrup761x25519 + ML-KEM-768). Measure handshake time, SFTP throughput across different file sizes, and compatibility with standard clients.
Tools: OQS-OpenSSH [26], oqs-demos, iperf3 for baseline comparison
Metrics: SSH handshake time [ms], SFTP throughput [MB/s], CPU overhead [%]
References: RFC 4253 (SSH Transport Layer) [27], IETF draft-kampanakis-curdle-ssh-pq-ke
6.11 Overview of Proposed Scenarios
Table 11: Overview of proposed scenarios
| No. | Scenario | Implementation | Priority | Estimated Time |
| 1 | VPN (WireGuard / IPsec + ML-KEM) | CIRCL + liboqs | High | 2–3 weeks |
| 2 | VoIP / SRTP + DTLS-SRTP | liboqs + OpenSSL | High | 2–3 weeks |
| 3 | TLS 1.3 web server | liboqs + OpenSSL | High | 1 week |
| 4 | Large file distribution | Bouncy Castle + liboqs | Medium | 1–2 weeks |
| 5 | Email (S/MIME / OpenPGP) | Bouncy Castle | Medium | 2–3 weeks |
| 6 | IoT (MQTT / CoAP) | liboqs (embedded) | Low | 4–6 weeks |
| 7 | PKI / CA | Bouncy Castle + liboqs | Medium | 2–3 weeks |
| 8 | Database replication | liboqs + TLS | Low | 1–2 weeks |
| 9 | SSH (OpenSSH + ML-KEM) | OQS-OpenSSH | High | 1 week |
| 10 | Wi-Fi / WPA3-Enterprise | liboqs (ARM) | Medium | 3–4 weeks |
7. Conclusion
The evaluation of three post-quantum ML-KEM implementations confirms significant differences in performance and memory consumption, which directly influence their suitability for specific application scenarios:
- liboqs (C) achieves the highest performance and is best suited for compute-intensive or high-performance server environments. With ML-KEM-768 KeyGen at approximately 11 μs, Encaps at ~12 μs, and Decaps at ~14 μs, combined with an RSS delta of approximately 5 MB, it represents an optimal solution for network infrastructure applications (VPN, TLS, SSH, VoIP).
- CIRCL (Go) provides an excellent balance between performance and ease of integration within the Go ecosystem. With KeyGen at approximately 30 μs and an RSS delta of ~6.4 MB, this implementation directly follows the FIPS 203 (ML-KEM) standard, making it well-suited for long-term compatibility. It is an ideal choice for cloud-native and Go-based applications.
- Bouncy Castle (Java) is the slowest implementation (KeyGen ~79 μs, RSS delta ~70 MB including JVM overhead), but offers unmatched integration within Java/JVM ecosystems and broad support for PQC algorithms. It remains a natural choice for Java backend systems, Spring Boot, and Android applications.
Across all evaluated implementations, the performance of ML-KEM is sufficient for production deployment in network communication scenarios. Even Bouncy Castle, with approximately 80 μs per KeyGen operation, can sustain thousands of handshakes per second on modern server hardware.
A critical open question remains the certification maturity of the FIPS 140-3 standard, its alignment with FIPS 203, and the long-term support of PQC implementations in production environments.
The proposed deployment scenarios (VPN, VoIP, AP/Router, large-scale data transfer, TLS servers, email, IoT, PKI, databases, SSH) cover a broad spectrum of real-world use cases. They provide a foundation for further research and development efforts toward the transition to post-quantum cryptography.
References
[1] P. W. Shor, Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer, SIAM Journal on Computing, vol. 26, no. 5, pp. 1484–1509, 1997. DOI: 10.1137/S0097539795293172
[2] M. Mosca, Cybersecurity in an Era with Quantum Computers: Will We Be Ready?, IEEE Security & Privacy, vol. 16, no. 5, pp. 38–41, 2018. DOI: 10.1109/MSP.2018.3761723
[3] National Institute of Standards and Technology (NIST), Federal Information Processing Standard (FIPS) 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard, August 2024. Available: https://doi.org/10.6028/NIST.FIPS.203
[4] National Institute of Standards and Technology (NIST), NIST Releases First 3 Finalized Post-Quantum Cryptography Standards, August 2024. Available: https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-cryptography-standards
[5] European Telecommunications Standards Institute (ETSI), Quantum-Safe Cryptography (QSC), ETSI TR 103 616 V1.1.1, June 2022. Available: https://www.etsi.org/technologies/quantum-safe-cryptography
[6] The Legion of the Bouncy Castle, Bouncy Castle Cryptography Library for Java, v1.78, 2024. Available: https://www.bouncycastle.org; GitHub: https://github.com/bcgit/bc-java
[7] Cloudflare, CIRCL: Cloudflare Interoperable Reusable Cryptographic Library, 2024. Available: https://github.com/cloudflare/circl; Blog: https://blog.cloudflare.com/post-quantum-key-agreement/
[8] National Institute of Standards and Technology (NIST), Recommendation for Existing Application-Specific Key Derivation Functions, NIST SP 800-135r1, 2011. Available: https://doi.org/10.6028/NIST.SP.800-135r1
[9] Internet Engineering Task Force (IETF), Post-quantum Preshared Keys for IKEv2, Internet-Draft, draft-ietf-ipsecme-ikev2-pqc, 2024. Available: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-pqc/
[10] E. Rescorla et al., Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP), RFC 5764, IETF, 2010. Available: https://www.rfc-editor.org/rfc/rfc5764
[11] E. Rescorla et al., Hybrid Key Exchange in TLS 1.3, Internet-Draft, draft-ietf-tls-hybrid-design, 2024. Available: https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
[12] IEEE, IEEE Standard for Information Technology – Telecommunications and Information Exchange Between Systems – Local and Metropolitan Area Networks – Part 11: Wireless LAN MAC and PHY Specifications, IEEE Std 802.11-2020, 2021.
[13] Wi-Fi Alliance, Wi-Fi Protected Access 3 (WPA3) Specification, Version 3.0, 2023. Available: https://www.wi-fi.org/discover-wi-fi/security
[14] E. Rescorla et al., TLS Certificate Compression, RFC 8879, IETF, 2020. Available: https://www.rfc-editor.org/rfc/rfc8879
[15] E. Rescorla et al., Hybrid Key Exchange in TLS 1.3, Internet-Draft, draft-ietf-tls-hybrid-design, 2024. Available: https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
[16] Open Quantum Safe Project, OQS-Demos: Demonstrations of Post-Quantum Cryptography in Various Applications, 2024. Available: https://github.com/open-quantum-safe/oqs-demos
[17] E. Rescorla, The Transport Layer Security (TLS) Protocol Version 1.3, RFC 8446, IETF, 2018. Available: https://www.rfc-editor.org/rfc/rfc8446
[18] Cloudflare, The State of Post-Quantum Cryptography in TLS at Cloudflare, 2023. Available: https://blog.cloudflare.com/post-quantum-for-all/
[19] S. Turner et al., Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS), RFC 9629, IETF, 2024. Available: https://www.rfc-editor.org/rfc/rfc9629
[20] Internet Engineering Task Force (IETF), Post-Quantum Cryptography in OpenPGP, Internet-Draft, draft-ietf-openpgp-pqc, 2024. Available: https://datatracker.ietf.org/doc/draft-ietf-openpgp-pqc/
[21] National Institute of Standards and Technology (NIST), Profile of the IoT Core Baseline for Consumer IoT Devices, NISTIR 8425, 2022. Available: https://doi.org/10.6028/NIST.IR.8425
[22] Z. Shelby et al., The Constrained Application Protocol (CoAP), RFC 7252, IETF, 2014. Available: https://www.rfc-editor.org/rfc/rfc7252
[23] R. Housley et al., Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC 5280, IETF, 2008. Available: https://www.rfc-editor.org/rfc/rfc5280
[24] Internet Engineering Task Force (IETF), Internet X.509 Public Key Infrastructure: Algorithm Identifiers for ML-DSA, Internet-Draft, draft-ietf-lamps-dilithium-certificates, 2024. Available: https://datatracker.ietf.org/doc/draft-ietf-lamps-dilithium-certificates/
[25] National Institute of Standards and Technology (NIST), Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations, NIST SP 800-52 Revision 2, 2019. Available: https://doi.org/10.6028/NIST.SP.800-52r2
[26] Open Quantum Safe Project, OQS-OpenSSH: Post-quantum Algorithms in OpenSSH, 2024. Available: https://github.com/open-quantum-safe/openssh
[27] T. Ylonen and C. Lonvick, The Secure Shell (SSH) Transport Layer Protocol, RFC 4253, IETF, 2006. Available: https://www.rfc-editor.org/rfc/rfc4253
