BB84 with ML-KEM Decapsulation-Failure-Based Security Parameters

Abstract

With the advent of quantum computers, traditional key exchange mechanisms are under threat, necessitating the development of new methods. Recently, Module-Lattice-Based Key Encapsulation Mechanism (ML-KEM) has been standardized as a quantum-safe key exchange method. Another emerging technique is Quantum Key Distribution (QKD) and its most famous protocol, BB84, which relies on the principles of quantum physics to exchange key information. Both techniques are considered secure against attacks by quantum computers, but their security is based on different principles. However, both key exchange types include a statistical component which, if an attacker were lucky, could allow circumventing these underlying hard problems. In this paper, we suggest that as a key exchange mechanism, BB84 should be run with security parameters comparable to those of ML-KEM, and analyze performance implications if this choice is taken. We illustrate the impact by estimating the number of raw bits required to generate a 256-bit symmetric key using BB84 and assessing the resulting performance implications. We further show how the BB84 finite-size security parameter can be chosen such that the post-processing failure probability is of the same order as the cumulative decapsulation-failure probability of ML-KEM. According to our results, the security parameter in BB84 should be at most $2^{-75.8}$ if statistical failure probability comparable to the ML-KEM decapsulation-failure target is desired. These findings offer general guidelines for BB84 parameter selection, with hybrid protocol design representing one potential application context.

1. Introduction

In today’s world, telecommunications are a strategic component of societal operations. Transmitting confidential information over a communication network requires an encryption algorithm that transforms the data into an unintelligible format for any external observer, thereby ensuring the confidentiality of the information. An encryption algorithm, in turn, requires a key, without which the message cannot be decrypted. Only the intended recipient, who has the corresponding key, can decrypt the encrypted message. In symmetric encryption, both the sender and the recipient use the same key to both encrypt and decrypt the message. However, securely delivering the key to the recipient poses a challenge.

Traditionally, this challenge has been addressed through asymmetric cryptography. Probably the best-known algorithms for agreeing on encryption keys over a public channel are RSA [1], based on the factorization of large numbers, and Diffie-Hellman [2] and elliptic curve cryptography [3], based on the discrete logarithm problem. At the time, both problems were considered practically unsolvable with existing computers, thus the security of these algorithms could be trusted.

However, the rapid development of quantum computers poses a challenge to traditional asymmetric algorithms. Shor’s algorithm, introduced in 1994 [4], significantly accelerates both the factorization of large numbers and finding the solution of the discrete logarithm problem, rendering algorithms based on these problems insecure in the era of quantum computers. Currently, no quantum computer powerful enough to break these algorithms exists, at least according to public sources, but the development is so rapid that traditional key exchange methods are expected to be considered insecure within a few years. The USA’s National Institute of Standards and Technology (NIST) has announced that these methods will be deprecated after 2030 and completely disallowed after 2035 [5].

To address this issue, NIST initiated a competition in 2016 to standardize new quantum-safe asymmetric encryption methods  [6]. These algorithms are known as Post-Quantum Cryptography (PQC). Several candidates were submitted to the competition. In 2024, NIST standardized the first quantum-safe key exchange algorithm: FIPS 203 [7], which introduces Module-Lattice-Based Key Encapsulation Mechanism (ML-KEM), originally submitted to the competition under the name CRYSTALS-Kyber [8]. This key encapsulation algorithm is based on public key cryptography and lattice problems. Currently, no algorithm is known that can significantly accelerate the solution of lattice problems using quantum computers. Therefore, ML-KEM is considered safe to use even in the era of quantum computers.

Quantum key distribution (QKD) represents a different approach to the problem. The story of QKD began with the introduction of the first and most well-known protocol, BB84, in 1984 [9], decades before the threat of quantum computers was fully recognized. QKD can perform the same key exchange as the aforementioned traditional or lattice-based key exchange methods, with the key difference that the security of QKD does not rely on hard mathematical problems. Instead, QKD leverages quantum physics: the parties communicate using quantum particles, influenced by quantum phenomena. The no-cloning theorem ensures that any attempt to eavesdrop on the communication will be detected, as it changes the state of the particles.

There are several different QKD protocols; the main distinction can be made between continuous variable (CV) and discrete variable (DV) protocols, as well as between entanglement-based (EB) and prepare-and-measure (PM) protocols. In this article, we analyze the BB84 protocol, which is a DV PM protocol. This choice was made because, with current technology, BB84 is considered the most efficient and widely implemented QKD protocol for long distances.

QKD requires specialized hardware for generating and measuring individual photons, making it more expensive and cumbersome than algorithms run on traditional computers. Today, the technology has advanced to the point where commercial implementations are available, with some examples of vendors being ID Quantique, Toshiba, and ThinkQuantum [10,11,12]. Furthermore, several national actors and standardization organizations have shown interest in QKD by publishing standards and technical reports [13,14,15]. At the moment, NIST is not anticipated to support the usage of QKD to protect communications in national security systems [16].

QKD’s unique functionality compared to classical key exchange algorithms does not allow direct comparison with lattice-based algorithms. However, both key exchange types have certain statistical properties which can be analyzed with classical probability theory and statistics. This article compares the statistical security of two different key exchange algorithms, BB84 and ML-KEM, to find a way to compare their implementations regardless of the fact that their functioning principles are different. This comparison is motivated by the need to assess the statistical reliability of each protocol and to establish an operational basis for comparing selected statistical failure probabilities, despite fundamentally different security foundations.

In this work, we justify the statistical confidence levels, i.e., security parameters, that should be targeted operating the BB84 protocol. We apply a well-established formula together with ML-KEM decapsulation failure security parameters to achieve the desired level of security in BB84 and analyze the performance implications. Fundamentally, we argue that the statistical security properties of BB84 should be aligned with those of ML-KEM decapsulation failure probabilities. This research contributes a framework for statistically comparing QKD and PQC protocols. In doing so, it offers practical guidelines for configuring BB84 and creates implementation guidance and hybrid-protocol parameter selection by aligning QKD security parameters with those used in PQC.

The article is organized as follows. In Section 1.1 and Section 1.2, we go through the working principles and security promises behind ML-KEM and BB84. Section 2 presents a review of the existing literature on the security evaluation of BB84 and ML-KEM. Following this, we highlight key similarities between the two algorithms—specifically, that both exhibit a small statistical probability of failing to meet their security promises. This observation motivates our decision to juxtapose these failure probabilities as a basis for comparative analysis. In Section 3, we present our results based on numerical analysis and present some example configurations. Section 4 contains a discussion about the benefits and possible drawbacks of our approach, and Section 5 concludes the paper.

1.1. ML-KEM Key Encapsulation

A simple overview of a Key Encapsulation Mechanism (KEM) protocol is presented in Figure 1. A KEM is a cryptographic method designed to establish a shared secret key between two parties. The shared secret key can then be used in symmetric-key cryptography or authentication, a typical choice being an authenticated encryption scheme such as Advanced Encryption Standard in Galois Counter Mode (AES-GCM) [17]. A KEM consists of three parts: a key generation algorithm, an encapsulation algorithm, and a decapsulation algorithm. The receiver, Bob, begins by generating a keypair: a public encapsulation key and a private decapsulation key, and shares the encapsulation key with Alice. The sender, Alice, then runs an encapsulation algorithm to encapsulate a shared secret key, which is transmitted to Bob as a ciphertext. Bob uses his private decapsulation key to decrypt the encapsulated key, recovering his copy of the shared secret key. The shared secret key can now be used as a secret key in the chosen encryption or authentication scheme. Rather than generating a new key pair for each exchange, Bob may generate a single key pair, publish the public key, and reuse it for multiple incoming ciphertexts, thereby deriving multiple shared secret keys. While reusing a key pair is considered secure, reusing the same shared secret key may pose security risks depending on the specific application context.

Figure 1. An overview of a KEM protocol.

ML-KEM is a chosen-ciphertext attack (CCA) secure KEM based on the hardness of a mathematical problem called Module-Learning with Errors (MLWE). Next, the chosen-plaintext attack (CPA) secure version of the scheme is introduced at a higher level in order to gain a basic understanding of the mathematical problems behind the procedure. For a more detailed explanation, see [8]. The CPA-secure version of ML-KEM is modified into a CCA-secure version by using the Fujisaki-Okamoto (FO) transformation [18].

First, the key generation algorithm creates a Learning With Errors (LWE) instance by computing $\mathbf{b}=\mathbf{A}\mathbf{s}+\mathbf{e}$, where $\mathbf{A}$ is a matrix and $\mathbf{b}$, $\mathbf{s}$, and $\mathbf{e}$ are vectors. The secret key $\mathbf{s}$ and the error $\mathbf{e}$ are sampled from a narrow centered binomial distribution. The public key is the pair $(\mathbf{A},\mathbf{b})$. In the encryption algorithm, the sender first samples three vectors from a centered binomial distribution that are used together with the public key to create two new LWE instances: a vector $\mathbf{u}$ and a polynomial v. The secret message the two parties want to share is encoded into the polynomial v. The new LWE instances $(\mathbf{u},v)$ are compressed and sent to the receiver. Lastly, the decryption process involves decompressing $\mathbf{u}$ and v. These are then used together with the secret key $\mathbf{s}$ to compute a noisy message polynomial, which is then decoded into the correct message by decoding each coefficient into 0 or 1 depending on whether the noisy polynomial coefficient is closer to 0 or $q/2$, where q is the modulus. The parameters of the scheme are chosen in a way that they are small enough to make decryption errors occur with negligible probability.

The security of ML-KEM is based on the computational difficulty of the MLWE problem. It is based on distinguishing uniform samples $(\mathbf{A},\mathbf{b})$ from samples $(\mathbf{A},\mathbf{b})$ where $\mathbf{A}$ is uniform and $\mathbf{b}={\mathbf{A}}^T\mathbf{s}+\mathbf{e}$, where $\mathbf{s}$ is kept the same for each sample but for each pair, a new $\mathbf{e}$ is sampled randomly from a centered binomial distribution [8]. Different approaches to solve this problem have been presented in, e.g., [19].

Since there are no known strategies to exploit the underlying module-structure of the MLWE problem, the most efficient attacks against MLWE are believed to be equivalent to attacks against LWE. The most efficient attacks against the underlying LWE problem are the primal and dual attacks [8]. These attacks use the Block Korkin Zolotarev (BKZ) algorithm, originally presented in [20], to reduce the lattice basis by using a Shortest Vector Problem (SVP) oracle to find increasingly shorter basis vectors to determine the secret key. The working principle of the BKZ algorithm is explained in more detail in, e.g., [21]. The number of calls to the SVP oracle is known to be polynomial. However, each SVP call has exponential complexity in the block size $\beta$, making the overall attack computationally infeasible in practice [22]. Since there are no known efficient algorithms for solving lattice problems using a quantum computer, the attack cannot be significantly accelerated, and this is why ML-KEM is considered quantum-safe [8].

ML-KEM has three distinct security levels, each characterized by unique parameter sets: ML-KEM-512, ML-KEM-768, and ML-KEM-1024. The process of selecting appropriate parameters for a KEM can be conceptualized as a complex optimization problem. It necessitates a careful balance between robust security measures and the practical considerations of performance and key size. For ML-KEM-512, ML-KEM-768, and ML-KEM-1024, the sizes of public (private) encapsulation (decapsulation) keys are 800 (1632) bytes, 1184 (2400) bytes, and 1568 (3168) bytes, respectively. The corresponding sizes of ciphertexts are 768, 1088, and 1568 bytes [7].

1.2. BB84 Key Distribution

The operation of the BB84 key exchange is described in the original article [9] as follows. The protocol involves two parties: the sender, commonly referred to as Alice, and the receiver, commonly referred to as Bob. Alice sends Bob a number of individual photons. The bit information is encoded in the polarization of the photon, with one polarization direction representing a bit value of zero and the orthogonal direction representing a bit value of one. In practice, bit information can also be encoded in phase or other variables, but the principle remains the same. Alice prepares the photons by randomly alternating between two different polarization bases, which are non-orthogonal with respect to each other; thus, there are a total of four possible polarization directions. Bob receives the photons and measures them, also randomly alternating between the polarization bases when measuring. According to the laws of quantum physics, if Bob measures a photon in a polarization basis different from the one in which Alice prepared it, he will obtain a random measurement result. Measurement in the correct polarization basis will yield the same value as Alice sent. Since both parties choose the polarization bases randomly, on average, about half of the photons are sent and received on the same polarization basis. The transmission and measurement bases are published, and only those instances where the bases matched are selected for the key.

Selecting instances with matching bases is called sifting, and it is part of a process called classical post-processing. Classical post-processing includes several steps. Firstly, the key exchange session must be authenticated. Secondly, practical quantum channels are rarely error-free, so the classical post-processing phase also includes error rate estimation and error correction to ensure that both parties have the same bit string. Error correction can be conducted with any suitable mechanism, the most used alternatives being CASCADE error correction [23] or error-correcting codes [24]. The final phase of post-processing is called privacy amplification. In this step, the error-corrected bit string is shortened to the length of the final key, for example, 256 bits. This is often done by modulo 2 multiplication of the raw bit string with a Toeplitz matrix [25]. The purpose of this step is to nullify any bit information about the key that may have leaked to an eavesdropper during the error correction and key exchange phases [26]. Generally, the bit string entering the post-processing phase is called the raw key or raw bit string, and the resulting bit string is called the final key. A simple overview of the BB84 protocol is depicted in Figure 2.

Figure 2. An overview of a BB84 protocol.

The actual security promise of BB84, exposing any attempts to eavesdrop on the secret key, is fulfilled in the post-processing phase. After error correction, the parties will have knowledge about the total error rate in the raw bit string after bit sifting. It was mentioned above that measuring a photon in the wrong polarization basis yields random results. This also applies to a scenario known as the intercept-and-resend attack, in which an eavesdropper positioned between Alice and Bob measures a photon sent by Alice and subsequently resends it to Bob. Since the polarization basis used to prepare the photon is random, the eavesdropper would choose the wrong measurement basis in about half of these instances. Thus, on average, one of every four measurements would yield a bit error, and Alice and Bob would observe an error rate of 0.25 in the key. Based on the error rate, the raw key would be discarded and not accepted for further processing. Thus, the ability of BB84 to detect eavesdropping is based on the evaluation of the error rate. Breaking the protocol would require breaking the no-cloning theorem, which, at the moment, is considered impossible [9]. Security analyses utilized today do not restrict themselves to this basic attack form but also consider other possible attack paths, which can make use of entanglement and thus reveal more information about the key material than normal intercept-and-resend attack. Fundamentally, these security analysis formulas cover all physically possible attacks [27].

Due to the nature of QKD, unlike traditional key exchange mechanisms, the security of BB84 is not measured by computational cost. In the following section, we delve deeper into the security of ML-KEM and BB84.

2. Comparing the Statistical Properties of BB84 and ML-KEM

Figure 3 illustrates the distinct attack vectors targeting a symmetric key generated using either BB84 or ML-KEM. In this section, we analyze the probabilities of the attacker successfully exploiting the dashed lines.

Figure 3. Illustration of possible attack paths targeted towards BB84 or ML-KEM.

BB84 and ML-KEM are both based on an underlying hard problem that is considered to be unbreakable in practice. In addition to the mathematical or physical problem, they have a certain probability of failure, which limits the likelihood that the algorithm will not work as it should, meaning the intended mathematical or physical problem no longer protects the key exchange. Thus, these algorithms can be divided into two parts: the fundamental problem that underpins security and the probability that the algorithm works as intended. Even though the hard problems underlying these algorithms are different, their statistical aspects can be examined in a comparable manner, as they are based on clearly defined probability distributions.

In the next subsections, we address the security of ML-KEM and BB84, assuming their implementation adheres to the ideal protocol. The side-channel vulnerabilities of these protocols and the attacks targeting incomplete implementations constitute a vast field of literature, and reviewing these results is beyond the scope of this paper. The authors are aware that side-channel attacks and imperfections in implementations significantly impact the security of the systems, but discussing these aspects in this article is not meaningful. Readers interested in this topic are directed to, e.g., [14,28].

2.1. Security Evaluation of BB84

In the original BB84 paper, the security of the protocol was justified by showing that an intercept-and-resend attack applied to all photons would allow the eavesdropper to gain information about half of the bit values, while simultaneously introducing errors in one quarter of the bits measured by the receiver in the correct basis [9]. Subsequently, more rigorous security proofs addressing various types of attacks, including entanglement-based attacks, were presented by [29,30]. Ref. [29] demonstrated that secret information can be extracted from the exchanged bits at a rate asymptotically approaching $1-2·H_2\left(ϵ\right)$, where $H_2$ denotes the binary entropy function [31] and $ϵ$ is the quantum bit error rate (QBER) of the key. Ref. [32] extended this security analysis to account for imperfect devices, thereby making the results more applicable to practical scenarios.

However, these proofs did not meet all the requirements of modern cryptographic protocols, primarily because limiting the adversary’s accessible information alone was insufficient to guarantee the practical security of the key [33]. This issue was addressed in the work of [34], who introduced a new security measure: the security of a key generated by a QKD protocol was evaluated by its trace distance from an ideal key—one that is uniformly distributed and completely independent of the adversary’s information. This metric captures both the secrecy and randomness of the generated key. A key advantage of this approach is its compatibility with the universal composability framework, as emphasized by [34]. In practical implementations, the security parameter can be extended to encompass additional aspects of key generation. While trace distance quantifies secrecy, separate parameters can be defined for correctness—the probability that both parties generate identical keys—and robustness—the probability that the protocol successfully generates a key in the absence of eavesdropping [35,36].

As noted by [37], in practical scenarios trace distance cannot be directly measured. Instead, it must be estimated based on the statistical properties of the generated key material. This challenge is part of the broader finite-size problem in QKD: since real-world keys are of finite length, statistical fluctuations in the quantities used for security estimation—such as bit error rates—are inevitable [38]. Therefore, in practice, even the well-known formula presented by [29] can only approximate the amount of information leaked to an adversary up to a certain confidence level. To address this challenge, various statistical modeling approaches have been proposed. For example, the number of bit errors in BB84 can be modeled using Bernoulli trials, as discussed in [37,39]. Based on these models, the security parameter that limits the statistical certainty of the estimate can be computed using statistical tools such as the Clopper–Pearson interval [37] or the Chernoff bound [39]. The choice of modeling approach directly affects the assumptions made about the QKD system and the adversary. Different attack models assign varying capabilities to the eavesdropper, with coherent attacks representing the most powerful adversarial scenario [40].

In this work, we adopt the framework proposed by [38], which provides a standard method for estimating the extractable secret key length of a QKD protocol while accounting for finite-size effects. The resulting secret key length, denoted by l, is given by

$$l\le n\left(q-H_2\left(Q_{tol}+\mu \right)\right)-{\mathrm{leak}}_{EC}-log{\displaystyle \frac{2}{{\epsilon }_{sec}^2{\epsilon }_{cor}}}$$

(1)

where

$$\mu =\sqrt{\left({\displaystyle \frac{n+k}{nk}}·{\displaystyle \frac{k+1}{k}}·ln{\displaystyle \frac{4}{{\epsilon }_{sec}}}\right)}$$

(2)

where n is the number of signals after sifting, q is the preparation quality, $Q_{tol}$ is the maximum tolerated error rate, ${\epsilon }_{sec}$ is the security parameter and ${\epsilon }_{cor}$ is the correctness parameter, limiting the probability that sender and receiver do not acquire a similar copy of the key (here, we set ${\epsilon }_{cor}={\epsilon }_{sec}$) and ${\mathrm{leak}}_{EC}$ is the number of bits leaked in the error correction phase. The results are computed for a perfect single-photon source with $q=1$. We assume that error correction uses a protocol with a reconciliation efficiency of $1.22$, corresponding to the CASCADE protocol commonly used in BB84 [23], in which case ${\mathrm{leak}}_{EC}$ in error correction phase becomes $1.22·H_2(Q_{tol}+\mu )$.

2.2. Security Evaluation of ML-KEM

In addition to the hard underlying mathematical problem, the security of ML-KEM also relies on resistance to decapsulation failures. In this paper, we focus exclusively on analyzing the security of ML-KEM in the context of decapsulation failures. Readers interested in other security aspects are referred to [8].

In ML-KEM, even if both parties behave honestly, all components are implemented correctly, and no adversary is present, there remains a very small probability that the shared keys do not match [7]. This condition, known as a decapsulation failure, can leak information about the private key and provide an attack vector for recovering it. This vulnerability enables the algorithm to be broken without solving the underlying hard lattice problem. Decapsulation errors occur due to the probabilistic nature of the MLWE problem. The encapsulation and decapsulation processes involve adding small random errors as well as rounding operations. Both random and rounding errors can accumulate and contribute to the overall error distribution in such a way that a decapsulation error occurs, meaning the sender’s and receiver’s copies of the shared key do not match. This mismatch can reveal information about the receiver’s secret key, as an attacker may be able to infer some coefficients of the secret vectors by exploiting the fact that the combined error distributions caused a failure. The probability of a decapsulation error can be modeled using the tail probabilities of the error distributions [41]. In practice, the probability of a decapsulation failure is set to be negligible [42].

If decapsulation failures were not allowed, the noise would need to decrease, resulting in decreased security due to the lattice properties. Increasing the lattice dimension could fix the loss in security, but it would result in decreased performance. Decapsulation failures are a security concern, so next we will introduce attacks that try to exploit them. It should be noted that the failure rates are extremely small, as seen in Table 1. Therefore, these attacks are usually excluded from security estimates. However, if a decapsulation failure occurs once, it is more likely to happen again [43].

Table 1. Decapsulation failure rates for ML-KEM parameter sets [7].

Parameter Set	Decapsulation Failure Rate
ML-KEM-512	$2^{-138.8}$
ML-KEM-768	$2^{-164.8}$
ML-KEM-1024	$2^{-174.8}$

The attacker can try to trigger a decapsulation failure by searching for ciphertext values that cause such failures, thereby gaining information about the receiver’s secret key. If the attacker has access to a quantum computer, they can use Grover’s algorithm [44] to accelerate the search. The information gained from a decapsulation failure is generally limited to partial information about the secret key. Consequently, a single failure does not typically enable key recovery. An attacker must first identify ciphertexts that induce failures and then analyze the resulting failure information to infer properties of the secret key. Therefore, a single decapsulation failure should not be interpreted as immediate key compromise. Instead, it provides information that may contribute to a later key-recovery attack. The precise amount of information leakage associated with a single failure remains an active research topic; some works model the leakage as approximately one bit of information [45], while others indicate that even a single failure can significantly facilitate further attacks [46].

Decapsulation failures depend on the coefficients of the secret key and error vectors, combined with rounding errors from the compression functions used to create a smaller ciphertext. Once an attacker causes enough decapsulation failures, they can use the BKZ algorithm for the rest of the attack. Information about the secret key gathered through decapsulation failures allows for a reduction in the block size used in the BKZ algorithm, thereby reducing its computational complexity [46]. In practice, a decapsulation failure decreases the computational complexity of the lattice problem underlying the security of ML-KEM, thereby undermining the algorithm’s entire security foundation. For finite-resource attackers, the practical risk depends on the cost of finding failing ciphertexts and on the remaining lattice-reduction cost after the leakage is incorporated.

A central concern is the robustness of the FO transform, which underpins ML-KEM’s indistinguishability under chosen ciphertext attack (IND-CCA) security guarantees. The re-encryption check within the FO transform plays a critical role in ensuring the security of ML-KEM. Although this step is not required for the basic functionality of the scheme, it is essential for maintaining security. Consequently, if the algorithm is incorrectly implemented or the re-encryption check is omitted—either accidentally or intentionally—the scheme becomes vulnerable to key recovery attacks, as demonstrated in prior work. Glabush et al. [47] introduced the concept of verifiable decapsulation, showing that faulty implementations of ML-KEM can silently bypass essential verification steps, thereby exposing systems to key recovery attacks.

There are two main types of decapsulation failure attacks: CCAs and valid-ciphertext attacks. While CCAs can be mitigated using the FO transform, valid-ciphertext attacks remain a threat even when the transform is applied. In such attacks, the adversary submits correctly formed ciphertexts in an attempt to identify those that cause decapsulation failures. The attack typically proceeds in two phases. First, the attacker generates ciphertexts that are likely to trigger decryption errors. This can be achieved using a technique known as failure boosting, which involves crafting input vectors that increase the probability of failure. In the second phase, the attacker analyzes the failed decryptions to infer information about the secret key. The extent of information leakage depends on how much can be learned from the observed failures.

Bindel et al. [43] demonstrated that an attacker can exploit information from an initial successful decryption to improve the likelihood of success in subsequent attempts. Building on their 2019 method [48], D’Anvers et al. introduced an enhanced technique called directional failure boosting [49], showing that once a decapsulation failure occurs, it can accelerate the discovery of additional failures. They further showed that in a single-target key model, cryptographic algorithms must be designed to make the first decapsulation failure difficult to achieve.

2.3. Review of Security Comparisons Between BB84 and ML-KEM

The difference in how security is assessed in QKD and PQC is evident in published group specifications and standards. QKD defines security in probabilistic terms, whereas PQC follows the traditional cryptographic approach based on computational hardness. Ref. [50] defines the QKD security parameter as the probability that the protocol does not abort and the resulting key fails to be confidential, shared, or random. This parameter is therefore the sum of three distinct failure probabilities, with the absence of eavesdropping being only one contributing factor. The document does not prescribe a fixed threshold for this parameter; instead, its acceptable value is left to be determined based on the specific use case.

In contrast, the security of ML-KEM is evaluated in terms of bit strength. The security levels defined in the NIST PQC standardization process—levels 1, 3, and 5—correspond to the computational effort required to break symmetric encryption schemes with key sizes of 128, 192, and 256 bits, respectively [6]. In ML-KEM, this effort and the resulting security level can be directly inferred from the key length [7].

Academic literature has examined comparisons between QKD and PQC in terms of efficiency and implementability. For instance, ref. [51] investigates real-world scenarios to determine which technology is more suitable for specific use cases; ref. [52] evaluates the applicability of QKD to IoT networks and provides a general comparison between QKD and PQC; and ref. [53] presents a comprehensive comparison of QKD and PQC techniques in the context of blockchain technologies.

One emerging area of research is the development of hybrid protocols that combine QKD and PQC. Ref. [54] compares the efficiency of BB84 and Kyber (the basis of ML-KEM), proposing a hybrid protocol and aligning Kyber-1024 and BB84 with a security parameter of ${10}^{-10}$. Similarly, ref. [55] suggests a hybrid approach that combines keys produced by Kyber and BB84. In [55], the QBER limit for BB84 is fixed at 10%, although the security implications of this choice are not further discussed. Ref. [56] proposes a framework for integrating QKD and PQC key material; however, no explicit security parameter requirements for QKD are defined.

Detailed statistical security comparisons between BB84 and ML-KEM under specific parameter settings appear to be lacking in the current literature. This is likely due to the recent standardization of ML-KEM. However, even for CRYSTALS-Kyber, the underlying algorithm of ML-KEM, comprehensive statistical security analyses remain scarce. This paper addresses the gap by presenting numerical example calculations of the statistical security of both protocols. These results provide tools for parameter optimization in applications such as hybrid protocol design or scenarios where QKD is considered for use cases that require a defined security level comparable to those specified for PQC algorithms.

2.4. Effects of Key Leakage

As discussed in prior work [57], the concepts of forward secrecy and post-compromise security describe the resilience of cryptographic mechanisms in the event of key leakage. Forward secrecy ensures that the compromise of a key does not affect the confidentiality of previously established session keys. Post-compromise security, on the other hand, guarantees that the leakage of a session key does not prevent the secure generation of keys in subsequent communication rounds. When evaluating the forward secrecy and post-compromise security properties of BB84 and ML-KEM, two key factors must be considered: for ML-KEM, the specific type of key that is compromised; and for BB84, the authentication mechanism employed.

ML-KEM employs an asymmetric key pair to generate symmetric session keys, whereas BB84 relies on quantum mechanical principles for the generation of symmetric session keys. Thus, while both protocols are ultimately used to share symmetric session keys, ML-KEM additionally involves a public–private key pair, which is absent in BB84. The disclosure of ML-KEM’s secret decryption key compromises the security of all session keys shared using it, both retrospectively and prospectively. However, in either protocol, the exposure of a single session key does not affect the confidentiality of past or future session keys, excluding certain BB84 configurations, which will be discussed in more detail shortly.

Authenticating ML-KEM with digital signatures is a natural choice, as a standardized digital signature algorithm based on the same mathematical foundation is available [58]. Therefore, this paper assumes the use of digital signatures for authenticating ML-KEM. For BB84, authentication using digital signatures is also possible and is commonly suggested in the literature (e.g., [59,60]).

Another method for authenticating BB84 is a technique known as key recycling, which has been proposed in several sources (e.g., [61]). In this approach, the first QKD session is authenticated using a pre-shared key, and thereafter, a portion of the key material from each BB84 session is used to authenticate the subsequent round. The advantage of this method is that it reduces the need for pre-shared authentication key material, thereby enhancing the key expansion properties of QKD. Furthermore, authentication can be performed without relying on public key cryptography. However, adopting this technique compromises the post-compromise security of BB84, as forging a single authentication tag enables an attacker to conduct man-in-the-middle attacks in future sessions until the authentication key is refreshed.

The bullet list below highlights the effects of the chosen authentication mechanism and the type of compromised key.

• Compromising the private decapsulation key of ML-KEM compromises all past and future session keys generated with that key pair.
• Compromising a single session key created with ML-KEM does not compromise past or future session keys.
• Compromising a single session key in BB84 may or may not compromise future session keys, depending on the authentication method:

  –

  If BB84 is authenticated using digital signatures, both past and future session keys remain secure.

  –

  If BB84 is authenticated using key recycling, past session keys remain secure, but future session keys are compromised until the authentication key is refreshed.

In this paper, we focus on the following scenarios: (i) the compromise of the private decapsulation key in ML-KEM, and (ii) the compromise of a session key generated by BB84, under the assumption that both BB84 and ML-KEM employ digital signatures for authentication. While compromising the private key used for digital signatures would undermine the security of both key exchange protocols, the security of the digital signature schemes themselves lies beyond the scope of this paper. By assuming that both ML-KEM and BB84 utilize digital signatures for authentication, we treat their authentication mechanisms as offering comparable security guarantees.

2.5. Defining the Parameters ${\epsilon }_{\mathit{sec}}$ and ${\epsilon }_{\mathit{decaps}}$

In QKD, the total security parameter is generally calculated as the sum of the security parameters of different sub-protocols, according to the universal composability theorem [62]. In this work, we use a security parameter definition ${\epsilon }_{\sec }$ as in [38]. This denotes the statistical uncertainty related to a security of a single BB84 session. For ML-KEM, we define a parameter limiting the probability of decapsulation failure, ${\epsilon }_{\mathrm{decaps}}$. Here, both parameters—${\epsilon }_{\sec }$ and ${\epsilon }_{\mathrm{decaps}}$—refer to the probability that the encryption key produced by the protocol, such as a 256-bit AES key, does not meet its promised computational strength. In practice, the security parameter of QKD limits even the leakage of a single bit from the key. This might seem like BB84 has stricter security requirements than ML-KEM. However, an ML-KEM decapsulation failure does not automatically mean that the entire secret key, and thus all session keys encapsulated with the corresponding public key, are revealed. The attacker still needs to do more work to gain complete knowledge of the keys. Thus, both ${\epsilon }_{\mathrm{decaps}}$ and ${\epsilon }_{\sec }$ can be seen as limiting the possibility of the computational complexity of the generated block cipher key from weakening below the promised level.

Thus, the statistical failure probability of two keys, one created using BB84 and the other using ML-KEM, is calibrated to the same operational failure-probability target when ${\epsilon }_{\mathrm{decaps}}\approx {\epsilon }_{\sec }$. If multiple session keys are shared with the same private–public ML-KEM key pair, this means that all session keys are encapsulated using the same public key and decapsulated using the same private key. Each decapsulation with the private key carries a small probability of decapsulation failure. This failure could affect all previously shared session keys if an eavesdropper has recorded earlier key exchange communications. Counterintuitively, reusing the same ML-KEM key pair for many key exchanges can increase the cumulative risk to previously established session keys if a future secret-key recovery attack becomes possible through decapsulation failures. This is because the probability of observing at least one decapsulation failure increases with the number of decapsulation operations. If decapsulation failures can be exploited to recover secret key information, the cumulative risk of key compromise also increases. Therefore, if the same private–public key pair is used to create several symmetric keys, the total probability of obtaining a decapsulation failure at any of these rounds would be $1-{(1-{\epsilon }_{\mathrm{decaps}})}^x$, where x denotes the number of decapsulations made with the same private key and ${\epsilon }_{\mathrm{decaps}}$ denotes the probability of decapsulation failure in ML-KEM. For ML-KEM-512, ${\epsilon }_{\mathrm{decaps}}$ = $2^{-138.8}$; for ML-KEM-768, ${\epsilon }_{\mathrm{decaps}}$ = $2^{-164.8}$; and for ML-KEM-1024, ${\epsilon }_{\mathrm{decaps}}$ = $2^{-174.8}$. We assume that the maximum number of decapsulations with the same private key is $2^{64}$, as stated in the NIST call for proposals [63].

Figure 4 shows how the probability of decapsulation failure occurring at any round of ML-KEM increases when the same key pair is used multiple times, but not for more than $2^{64}$ (≈${10}^{19.3}$) rounds. Higher security levels of ML-KEM have smaller decapsulation failure probabilities, both in individual rounds and when the algorithm is run multiple times.

Figure 4. The probability of encountering a decapsulation failure in any round of ML-KEM when the same private–public key pair is used multiple times for session key generation, i.e., $1-{(1-{\epsilon }_{\mathrm{decaps}})}^x$.

In QKD, if authentication key recycling is not employed, the corruption of one key exchange session does not impact previous or subsequent sessions. Consequently, it does not experience the same increase in the security parameter when more symmetric keys are generated. From the perspective of a single symmetric encryption key, the security of keys created using ML-KEM and BB84 is calibrated to a comparable operational failure probability when

$$1-{(1-{\epsilon }_{\mathrm{decaps}})}^x\approx {\epsilon }_{\sec }$$

(3)

where x denotes the number of decapsulations made with the same private key, ${\epsilon }_{\mathrm{decaps}}$ is the decapsulation failure probability for a given ML-KEM version and ${\epsilon }_{\sec }$ is the security parameter of the QKD protocol. While ${\epsilon }_{\mathrm{decaps}}$ and ${\epsilon }_{\sec }$ arise from fundamentally different security notions, both parameters quantify the probability that the effective security level of the derived symmetric key falls below its intended target. In this sense, they are not equivalent primitives, but they are comparable as operational failure probabilities affecting the cryptographic use of the key.

The actual value of ${\epsilon }_{\sec }$ depends on the desired security level of BB84, with smaller values corresponding to higher levels of security. While, in principle, any probability value could be chosen, this paper argues that the parameter should be defined based on the probability of a decapsulation failure, which constitutes a potential avenue for compromising the private decapsulation key, observed across multiple consecutive ML-KEM decapsulations. Assuming that authentication for both protocols is performed using digital signatures, we can omit the security parameters related to authentication and delve deeper into the statistical analysis of the relationship between ${\epsilon }_{\mathrm{decaps}}$ and ${\epsilon }_{\sec }$. In Section 3, the actual probability values for ${\epsilon }_{\sec }$, depending on the ML-KEM variant and the number of session keys generated with the same key pair, are provided.

2.6. Adjusting the Security Level

If QKD is to be considered a serious alternative to PQC key exchange algorithms, its statistical security should be of the same order as that of PQC alternatives. The security parameter ${\epsilon }_{\sec }$ of the generated key can be adjusted in two ways. First, a larger number of bits used for error rate estimation makes it possible to estimate a potential attacker’s actions more accurately, thus diminishing the statistical uncertainty related to this process. A larger amount of exchanged raw bits naturally allow the parties to estimate the attacker’s activity based on a larger and thus more reliable statistical sample. Second, as explained in Section 2.1, compressing the final key from a larger amount of raw bits increases its expected entropy and thus, in a cryptographic sense, its bit strength. If the bit leak from the quantum phase is estimated at a confidence level of $1-{\epsilon }_{\mathrm{decaps}}$, and we want to distill a 256-bit key and take into account post-processing steps, the number of raw bits needed must fulfill Equation (1) such that ${\epsilon }_{sec}\le {\epsilon }_{\mathrm{decaps}}$.

To assess the performance of BB84 in the presence of ML-KEM decapsulation failures, we provide illustrative examples by calculating the number of raw key bits required to achieve a specified security level. Here, raw key bits refer to the bits retained after basis sifting, that is, bits for which Alice and Bob used the same basis, but before any subsequent post-processing steps such as error correction or privacy amplification. We calculate ${\epsilon }_{\sec }$ for 256-bit symmetric keys such that, given the maximum allowable QBER and the number of raw bits used to generate the key, an eavesdropper has no knowledge of any bit of the key with a probability of $1-{\epsilon }_{\sec }$. We determine the required raw key length under the assumption that one hundred 256-bit keys are generated simultaneously. This assumption is well aligned with the operating principles of QKD systems, which are generally designed to distribute large amounts of secret key material that can subsequently be partitioned into multiple shorter cryptographic keys. Generating only a single key at a time would amplify finite-key effects, resulting in overly conservative estimates of the protocol’s performance.

The results presented in the next section were calculated programmatically. The program was written in Python version 3.13.14, and the mpmath library was utilized to compute the needed raw bits. The user provided the initial probability of decapsulation failure to the program, which then calculated how many raw bits are needed in a QKD session, with a certain QBER, to produce a key that satisfied Equations (1) and (3).

3. Results

Increasing the number of ML-KEM key-exchange rounds increases the probability that at least one decapsulation failure occurs. To achieve statistical security equivalent to ML-KEM, the number of raw bits required for a single BB84-produced symmetric key decreases as the number of rounds increases. The actual number of raw bits required varies depending on the desired security level of ML-KEM and the maximum allowable QBER.

3.1. Security Analysis for QBER = 2% and QBER = 5%

In the following figures, we report the number of sifted raw bits required per 256-bit key. The raw-bit count includes both the bits used for key generation and those allocated to parameter estimation, with the latter fixed at 10% of the former. For example, if 500 bits were allocated to key generation, an additional 50 bits were reserved for parameter estimation, resulting in 550 sifted bits. The reported values correspond to the generation of 100 independent 256-bit keys from a single raw-key block, yielding a total of 25,600 secret bits that are subsequently partitioned into 256-bit keys. This approach is adopted because finite-key effects become particularly significant when only a small number of keys are generated in a single protocol execution, resulting in overly conservative performance estimates. In practical QKD deployments, a larger pool of secret key material is typically generated and subsequently divided into cryptographic keys of the desired length.

Figure 5 shows the relation between the number of raw bits used to produce a single 256-bit encryption key in BB84 and the key encapsulation rounds using the same ML-KEM key, so that Equation (1) is fulfilled with ${\epsilon }_{\sec }=1-{(1-{\epsilon }_{\mathrm{decaps}})}^x$. The curves are calculated for all ML-KEM security levels and for BB84, with example QBERs of 2% and 5%. For example, as shown in Figure 5, to meet the statistical security of one round of ML-KEM-512, 2377 bits would be needed for a 5% QBER, whereas 1027 bits are sufficient for a 2% QBER. In the QKD literature, it is common to report the secret key fraction, defined as the ratio of secret bits that can be distilled from a single sifted bit. This quantity takes values between 0 and 1. In our case, requiring 2377 and 1027 sifted bits to generate a 256-bit secret key corresponds to secret key fractions of approximately 0.11 and 0.25, respectively. This difference arises from the fact that a higher QBER indicates more attacker activity, and thus more secret bits are needed to compensate for the leaks. Furthermore, as bit leaks in the error correction phase are proportional to the QBER, we need to account for more extra bits to achieve a sufficient number of secret bits after the error correction step.

Figure 5. The lines illustrate how many raw bits are required to generate a single 256-bit encryption key in BB84 with QBERs of 2% and 5%, assuming the statistical security is adjusted to match that of ML-KEM over multiple rounds, i.e., when ${\epsilon }_{\sec }=1-{(1-{\epsilon }_{\mathrm{decaps}})}^x$, and 100 keys are generated at a time. Note that the x-axis is logarithmic. Black lines correspond to a QBER of 2%, and red (grey in black-and-white print) lines correspond to a QBER of 5%. The number of parameter-estimation bits is fixed at 0.1× the number of key-generation bits. The y-axis represents the total number of sifted bits, including both the bits allocated to key generation and those reserved for parameter estimation. The blue horizontal lines indicate the required number of raw bits for a security parameter of ${10}^{-10}$.

When QKD is used for the same operational purpose as a PQC KEM, namely establishing symmetric keys, it could be considered that the maximum allowable ${\epsilon }_{\sec }$ for BB84 post-processing is the one obtained when the lowest security level of ML-KEM is run the algorithm’s permitted $2^{64}$ times, leading to a probability value of $2^{-75.8}$. Conversely, if the maximum usage of ML-KEM is known, for example, according to the policy related to the renewal of certificates in the existing Public Key Infrastructure (PKI), the required security parameter and thus the number of raw bits can be adjusted accordingly.

The blue horizontal lines in Figure 5 indicate the raw-bit requirements corresponding to the specified QBER thresholds when the commonly adopted security parameter of ${10}^{-10}$ is used. For example, security parameters of this order of magnitude are employed in several studies, including [35,38,54,64,65]. In addition, ref. [38] adopts a security parameter of this scale for illustrative purposes. For example, at a QBER of 2%, 694 raw bits would be sufficient under a security parameter of ${10}^{-10}$, whereas targeting security parameters corresponding to a single execution of ML-KEM-512 requires 1027 raw bits, corresponding to an increase of 48% in raw key length. At a QBER of 5%, the corresponding figures are 1437 and 2377 bits, respectively, representing an increase of 65%.

3.2. Security Analysis for QBER = 0.01%

The leftmost edge of Figure 6 shows the raw bits needed to achieve the statistical security of ML-KEM, assuming that the key pair is used only once and QBER = $0.01$%. For ML-KEM-512, ML-KEM-768, and ML-KEM-1024, these values are 662, 698, and 711, respectively. These values are not far from the sizes of ciphertexts (768, 1088, and 1568) for the corresponding ML-KEM security levels. However, in BB84, a smaller increase in the raw-key length is enough to achieve the desired security level.

Figure 6. The lines illustrate how many raw bits are required to generate a single 256-bit encryption key in BB84 with QBER of 0.01%, assuming the statistical security is adjusted to match that of ML-KEM over multiple rounds, i.e., when ${\epsilon }_{\sec }=1-{(1-{\epsilon }_{\mathrm{decaps}})}^x$, and 100 keys are generated at a time. Note that the x-axis is logarithmic. The number of parameter-estimation bits is fixed at 0.1× the number of key-generation bits. The y-axis represents the total number of sifted bits, including both the bits allocated to key generation and those reserved for parameter estimation. The red horizontal line indicates the required number of raw bits for a security parameter of ${10}^{-10}$.

The rightmost edge of Figure 6 shows the raw bits needed to achieve the statistical security of ML-KEM, assuming that the key pair is used $2^{64}$ times, the highest value allowed in our setting. In this case, the total probabilities of decapsulation failure at any round are $2^{-75.8}$, $2^{-101.8}$, and $2^{-111.8}$ for ML-KEM-512, ML-KEM-768, and ML-KEM-1024, respectively. When QBER = $0.01$%, the respective numbers of raw bits in BB84 are 562 bits for ML-KEM-512, 606 bits for ML-KEM-768, and 622 bits for ML-KEM-1024. These values correspond to secret key fractions of 0.46, 0.42, and 0.41, respectively. At this point, the probability of decapsulation failure at any round in ML-KEM achieves its highest value, and as QBER is close to zero in BB84, a minimum number of raw bits can be used to produce a secure encryption key. This means that this setting gives the absolute minimum number of raw bits produced in BB84 per one 256-bit key if the statistical security of ML-KEM is desired. However, to meet the usage of ML-KEM in practice, even smaller probabilities would be recommended. Naturally, if larger blocks of secret key material were generated in a single protocol execution (e.g., corresponding to 1000 or 10,000 independent 256-bit keys), the raw-bit requirement per individual 256-bit key would decrease. This reduction arises because the impact of statistical fluctuations, and hence finite-key effects, diminishes as the block size increases.

As shown in the previous subsection, adopting a security parameter corresponding to a single ML-KEM-512 decapsulation failure results in an increase of 65% and 48% in the required number of raw bits at QBER values of 5% and 2%, respectively, compared with a security parameter of ${10}^{-10}$. However, when the QBER decreases to 0.01%, the difference is reduced to only 662 versus 472 sifted bits per 256-bit key, corresponding to an increase of 40%. These results indicate that the lower the quantum bit error rate of the channel, the smaller the increase in raw-key length required when transitioning from the commonly used security regime of ${10}^{-10}$ to security levels comparable to ML-KEM decapsulation-failure probabilities.

The above analysis examines the number of secret bits obtained relative to the number of sifted bits and demonstrates that tightening the security parameter reduces this quantity. This performance degradation translates directly into the commonly used key-rate metric, namely the amount of secret key generated per emitted pulse, independent of the physical performance of the quantum channel. For example, if the security measures proposed in this work were to reduce the secret key fraction (i.e., the number of secret bits distilled per sifted bit) by 10%, the secret key rate per emitted pulse would decrease by the same proportion. This follows from the fact that the secret key rate is given by the product of the secret key fraction and the sifted-bit generation rate.

4. Discussion

ML-KEM’s two algorithms, key generation and key encapsulation, require the generation of proper randomness. For each creation of randomness, a fresh string of random bytes must be produced, meaning that the same randomness cannot be reused with different recipients. Since the randomness on both sides of the key encapsulation method impacts the shared key, it is of the utmost importance that the randomness is produced correctly. If the random bits in key generation leak, the entire shared key is at risk of being exposed. The situation is parallel to BB84; to take advantage of the no-cloning theorem, basis choices in the quantum protocol phase must be random, otherwise an eavesdropper could just pick the proper basis and evade being exposed. ML-KEM key generation is executed only when the private–public key pair is replaced with a new one, but for the encapsulation algorithm, fresh randomness is required each time. For higher security levels, more randomness per key generation is required. In this sense, both algorithms consume randomness and turn it into a random secret key, even though the secret key is encoded in different ways.

If BB84 is used to transmit a computationally secure symmetric key, such as an AES key, ${\epsilon }_{\mathrm{decaps}}$ and ${\epsilon }_{\sec }$ both describe the likelihood that the computational security of the generated key is weakened. Therefore, we calibrate the BB84 finite-size security parameter against the ML-KEM decapsulation-failure probability. One open question for further consideration is how a single decapsulation failure in ML-KEM should be equated to bit leakage in the BB84 protocol. For example, ref. [45] reports that a single decapsulation failure reveals approximately one bit of information to an adversary, whereas the results of [46] suggest that even a single decapsulation failure may have substantially more severe consequences for key security.

The choice of a QKD security parameter should not be treated as a purely conventional implementation detail. When BB84 is used for the same operational purpose as a PQC KEM, namely the establishment of symmetric encryption keys, the selected finite-size security parameter should be justified in relation to the statistical failure probabilities tolerated in alternative key-establishment mechanisms. This work provides one way to make this choice explicit: rather than adopting commonly used $\epsilon$ values independently of the surrounding cryptographic system, the BB84 parameter can be selected so that its post-processing failure probability is comparable to a chosen ML-KEM decapsulation-failure benchmark. To give some examples of security parameter choices in the academic literature concerning QKD, ref. [36] strives for a security parameter of $2^{-50}$, while refs. [35,38,54,64,65] use security parameter values ranging from $4\times {10}^{-9}$ (≈$2^{-28}$) to ${10}^{-10}$ (≈$2^{-33}$). The parameters suggested in this work are notably smaller. This is justified by the requirement that, as a cryptographic application, QKD implementations should offer at least the same level of statistical security as other alternative key exchange mechanisms. Since the measurement of QKD security is probability-based and ML-KEM has clearly defined probabilities for maintaining its computational security, it is a natural choice to require similar security parameters for QKD in this regard. As demonstrated in Section 3, achieving security parameters comparable to ML-KEM decapsulation-failure probabilities requires a larger number of raw bits than with parameters typically considered in QKD. Nevertheless, the increase is moderate and does not significantly impair the overall performance or practicality of the BB84 protocol. In matching BB84 security parameters with parameters related to computational PQC, we complete the work of, for example [66], which proposes operating QKD protocols with a security parameter of $2^{-128}$ and demonstrates how this choice affects authentication key recycling and the overall security parameter, thereby enabling a larger number of key recycling rounds without the overall security parameter increasing to unacceptable levels.

A key limitation of this study is the assumption of an idealized BB84 implementation, with implementation-specific and side-channel vulnerabilities deliberately excluded from consideration. This restricts the applicability of our analysis to idealized scenarios and precludes its extension to imperfect hardware implementations or more advanced attack models. An analogous analysis employing, for example, the decoy-state protocol could potentially broaden the scope by accommodating more flexible assumptions, such as non-perfect single photon sources.

In this work, we adopt a framework in which one hundred 256-bit keys are generated from the same raw-bit string, and we report the required raw-bit overhead per 256-bit key. This choice makes the comparison with repeated ML-KEM decapsulations concrete but it should not be interpreted as an optimal operating mode for all QKD systems. In practical deployments, larger QKD key blocks would generally reduce finite-size penalties and improve the per-key overhead (see, e.g., [67]), whereas constrained links, such as intermittent free-space or satellite-based channels, may limit the ability to accumulate large key blocks before the key material is needed. Therefore, the values reported here should be read as illustrative calibration results for the selected security parameter, not as complete throughput estimates for deployed BB84 systems.

Extending the analysis to other QKD protocols is feasible, as the security of QKD schemes fundamentally relies on statistical principles. Applying the framework to other PQC schemes beyond ML-KEM is possible, provided the schemes exhibit a statistically analyzable component that could compromise key security. However, certain PQC key encapsulation mechanisms, such as Classic McEliece [68], are not susceptible to decapsulation failures that could be exploited to infer private key information. In such cases, identifying an appropriate reference point for comparing statistical security can be challenging.

5. Conclusions

We have estimated two different key exchange mechanisms, BB84 based on quantum physics and ML-KEM based on lattice problems, based on their statistical properties, and suggested that BB84 should be run with security parameters comparable to decapsulation failure rates of ML-KEM. Both of these key exchange mechanisms face serious challenges in securing the transmitted key material, though the probability of an attacker circumventing these challenges is small. In ML-KEM, this probability is related to decapsulation failures, whereas in BB84 it quantifies the uncertainty in the estimation of information potentially leaked to an adversary. In ML-KEM, decapsulation failure threatens all symmetric keys produced with the same private–public key pair, whereas in BB84, subsequent or future symmetric keys are not threatened by failure in estimating the information leak. Thus, we have calculated the cumulative probability of decapsulation failure in ML-KEM when the protocol is run several rounds, and juxtaposed it with the security parameter of BB84, using 256-bit symmetric keys as a representative example. We calculated the number of raw bits required by BB84 at various QBER levels to achieve security parameters comparable to the decapsulation-failure probabilities associated with different ML-KEM security levels, and analyzed the resulting performance implications. The results indicate that attaining security levels corresponding to the selected ML-KEM decapsulation-failure benchmarks requires the generation of additional raw bits beyond those needed under the security parameters traditionally adopted in QKD. However, although several extra bits must be produced per 256-bit symmetric key to achieve the more stringent security target, the resulting increase in the raw-bit requirement remains moderate. Higher security levels of ML-KEM require more raw bits in BB84, but using the same ML-KEM key pair multiple times decreases the statistical security of ML-KEM and thus decreases the number of raw bits required in the corresponding BB84 run. We propose that, in order to achieve finite-size failure probability comparable to the cumulative ML-KEM decapsulation-failure probability, the security parameter in BB84 should not exceed the probability of decapsulation failure observed when ML-KEM is executed at its lowest security level with the maximum number of rounds allowed by the protocol, which corresponds to a failure probability of $2^{-75.8}$. This provides a principled parameter-selection rule for settings in which BB84 is deployed alongside, or compared with, PQC KEMs. In particular, it avoids adopting conventional QKD security-parameter values without relating them to the statistical failure probabilities already present in standardized PQC deployments. One of the principal limitations of this work lies in the restricted scope of the chosen methodology, which does not address side-channel or implementation vulnerabilities in QKD. Expanding the analysis to encompass a broader range of adversarial scenarios would significantly enhance the generalizability and practical relevance of the results.