Cold Boot Attacks on the Supersingular Isogeny Key Encapsulation (SIKE) Mechanism

: This research paper evaluates the feasibility of cold boot attacks on the Supersingular Isogeny Key Encapsulation (SIKE) mechanism. This key encapsulation mechanism has been included in the list of alternate candidates of the third round of the National Institute of Standards and Technology (NIST) Post-Quantum Cryptography Standardization Process. To the best of our knowledge, this is the ﬁrst time this scheme is assessed in the cold boot attacks setting. In particular, our evaluation is focused on the reference implementation of this scheme. Furthermore, we present a dedicated key-recovery algorithm for SIKE in this setting and show that the key recovery algorithm works for all the parameter sets recommended for this scheme. Moreover, we compute the success rates of our key recovery algorithm through simulations and show the key recovery algorithm may reconstruct the SIKE secret key for any SIKE parameters for a ﬁxed and small α = 0.001 (the probability of a 0 to 1 bit-ﬂipping) and varying values for β (the probability of a 1 to 0 bit-ﬂipping) in the set { 0.001,0.01, . . . ,0.1 } . Additionally, we show how to integrate a quantum key enumeration algorithm with our key-recovery algorithm to improve its overall performance. R.V.-P. and E.A.-M.; R.V.-P. and E.A.-M.; supervision, R.V.-P.; project administration, R.V.-P.; funding acquisition, R.V.-P.; All authors have read and agreed version manuscript.


Introduction
This research paper assesses the viability of cold boot attacks on the Supersingular Isogeny Key Encapsulation (SIKE) Mechanism [1], which is built upon a key-exchange construction known as Supersingular Isogeny Diffie-Hellman (SIDH) [2]. This key encapsulation mechanism has been included in the list of alternate candidates of the third round of the National Institute of Standards and Technology (NIST) post-quantum cryptography standardization process. According to the status report on the second round of this standardization process (NISTIR 8309) [3], the alternate candidates are considered as potential candidates for future standardization. This report also states the main drawback to SIKE is that its performance is approximately an order of magnitude worse than many of its competitors. So improvements on its implementations have been carried out so far to ameliorate this disadvantage [4][5][6][7][8]. The report additionally states that more research is needed to add more side-channel protection on SIKE's operation. This paper looks into side channel attacks against SIKE and in particular assesses SIKE in the cold boot attack setting. To the best of our knowledge, this is the first time this scheme is assessed in this setting and our evaluation focus on this scheme's reference implementation, in particular version v3.3 [9].
In the cold boot attack setting, an adversary having physical access to a computer may retrieve any content from the computer's main memory by carrying out a series of steps on the target computer, such as shutting it down improperly, booting a lightweight operating system (OS) on it and finally using this OS to dump remaining memory contents to an external device. However, as a consequence of some physical effects on the targeted main memory, the retrieved content is altered [10]. This means that on the condition that an attacker gets possession of a chunk of memory content, this content might be noisy, which means that some 0 bits may have flipped to 1 bits and vice-versa. The next attacker's task is to try to recover secret information stored in the procured memory content, based on what this attacker may learn from the error distribution that occurs during the data acquisition process.
In order to evaluate a public key scheme in this setting, we assume that the attacker procures memory content from a memory region in which the scheme's secret key was stored, and thus such adversary obtains a noisy version of it. On possession of this noisy memory content, the adversary's main task is to try to recover the original secret key from its bit-flipped version. More specifically, the evaluation of a public key encryption scheme in this setting entails three main tasks: (1) the attacker is required to learn the in-memory representations of the scheme's secret key, i.e., the data structures that are used to store the scheme's secret key, (2) the attacker is required to estimate error probability distributions for the bit-flipping, and (3) finally, the attacker is required to devise and develop a key-recovery algorithm for the scheme's secret key.
To deal with the first task, the attacker may either study natural in-memory representations for the scheme's secret key or review scheme's actual implementations to further learn the scheme's secret key memory formats. We follow the latter approach, since it is more realistic, and hence we make a deep review of the SIKE reference implementation (Version v3.3) [9]. Regarding the second task, we assume the attacker estimate α, the probability for a 0 bit of original content to turn to a 1 bit, and β, the probability for a 1 bit of original content to turn to a 0 bit, as per the cold boot model described in Section 2.2. Lastly, we develop our key-recovery algorithm based on a general key-recovery strategy introduced in [11]. Basically, by exploiting and combining the optimal key enumeration algorithm [12], and a non-optimal key enumeration algorithm, as in [11][12][13][14][15][16][17][18][19][20][21][22][23][24][25][26][27], we are able to get a suitable algorithm for the key-recovery task. In particular, this algorithm takes advantage of the SIKE secret key in-memory representation and the estimations for both α and β to generate suitable key candidates for the secret key.
This paper presents two contributions: our first contribution is the evaluation of SIKE against this class of attack. Considering SIKE is one of the alternate candidates, this evaluation represents an important part of the overall assessment of this scheme within the NIST standardization process. Our second contribution is a dedicated key-recovery algorithm for SIKE in the cold boot attack setting. This contribution is in alignment with the current tendency of devising and constructing novel key-recovery algorithms for various schemes in this setting, as our review of the literature, discussed at length in Section 2.3, reveals.
The organization of this research paper is as follows. In Section 2, we discuss the required background on cold boot attacks, detailing on how this attack may be carried out by an attacker. Additionally, we describe the cold boot attack model we assume throughout this paper and also review the literature relevant to our work, focusing on the evaluation of various cryptographic schemes in this setting. Finally, we detail our approach to keyrecovery, i.e., the general technique we use to design our key-recovery algorithm. In Section 3, we describe the supersingular isogeny key encapsulation mechanism and its reference implementation, mainly focusing on the key generation algorithm. In Section 4, we give a detailed account of our key-recovery algorithm and our choice for key enumeration algorithms. In Section 5, we evaluate our key-recovery algorithm, focusing on the success rate of our algorithm and how to integrate a quantum key search algorithm with it to improve its overall performance. Finally, in Section 6, we conclude our paper and give insight into a research line to continue with our work.

Background
In this section, we give a detailed description of cold boot attacks, the attack model we use through this article and an overview of the previous papers focusing on cold boot attacks on several cryptographic schemes, and finally present a description of the general approach to key recovery we use in this article.

Cold Boot Attacks
A cold boot attack is a type of data remanence attack in which an attacker could retrieve sensitive data from a computer's main memory after supposedly having been deleted. This attack relies on the data remanence property of Dynamic RAM (DRAM) and allows an attacker to recover memory content that remains readable for a period of time after the computer's power has been turned off. The first time this attack was discussed was about a decade ago in [10], and, since then, it has been studied extensively against multiple cryptographic schemes. In this attack, an adversary, who is assumed to have physical access to a computer, might retrieve portions of memory content from a running operating system via carrying out a cold-rebooting on it. This means the running operating system is forced to shut down improperly, making it to bypass all shut-down-related processes, for example, file system synchronization, that would normally take place during an ordinary shutdown. As a consequence of this improper shutdown, the attacker may use an external disk to start and run a lightweight operating system to copy memory contents of pre-boot DRAM to a file. In an alternative way, such attacker may take the memory modules out of the computer and place them in an adversary-controlled computer, which is then booted, allowing the attacker to have access to the memory content and be able to copy chunks of memory content to an external drive.
As soon as the attacker procures data from the main memory, the adversary may carry out a detailed analysis on that data in order to find sensitive information, such as cryptographic keys, via running several key finding algorithms [10]. Due to some physical effects on the main memory, some bits in the memory experience a process of degradation after the computer's power is turned off. Therefore, the extracted data obtained by the attacker from the target machine's main memory will be recognizably different from the original memory data. In particular, some 0 bits of the original content may have flipped to 1 bits and vice-versa. The authors in [10] remarked that the degradation of bits in memory can be slowed down via spraying some chemical compounds (liquid nitrogen) on the memory modules and thus the original bits may be preserved for a longer period of time. Nevertheless, the attacker has yet to extract the memory content before restoring any important information (or sensible) from the target machine's main memory. To this end, the attacker has to handle several possible issues that may occur. For example, the BIOS of the target computer, on rebooting, may overwrite a fraction of memory with its own code and data, even though the affected fractions are usually small. Moreover, the BIOS during its Power-On Self Test (POST) might execute a destructive memory check, yet this test may be disabled or bypassed in some computers.
To properly handle this problem, some small-scale special-purpose programs, like memory-imaging tools, may be used and are expected to produce correct dumps of memory contents to any external device, as was reported in [10]. These programs generally make use of trivial amounts of RAM, and their memory offsets are usually adjusted so as to guarantee that information of interest remains unchanged. Furthermore, if an attacker cannot force boot memory-imaging tools, the attacker could pull out the memory modules and place them in a compatible machine controlled by the attacker and subsequently dump the content, like that mentioned by the authors of [10]. After extracting memory content, the attacker needs to profile it to learn the memory regions and to estimate the probability for both a 1 flipping to 0 and a 0 flipping to 1. Furthermore, according to the results of the experiment reported in [10], almost all memory bits in a memory region tend to decay to predictable "ground" states, with only a portion flipping in the opposite direction. Additionally, the authors of [10] mention the probability of a bit flipping in the opposite direction stays constant and is very small (circa 0.01) as time elapses, while the probability of decaying to the "ground state" increases over time. These results suggest that the attacker could model the decay in a portion of the memory as a binary asymmetric channel, i.e., we can assume that the probability of a 1 flipping to 0 is a fixed number, and that the probability of a 0 flipping to a 1 is another fixed number in a given time. Note that by reading and counting the number of 0 bits and 1 bits, the attacker can discover the "ground state" of a specific memory region. Additionally, the attacker can estimate the bit-flipping probabilities by comparing the bit count of original content in a memory region with its corresponding noisy version.
Finding encryption keys after procuring memory content is another challenge that the attacker has to address. Such problem has been extensively discussed in [10] for Advanced Encryption Standard (AES) and RSA (Rivest-Shamir-Adleman) keys in memory images. Even though the algorithms presented are scheme-specific, their algorithmic rationale may be easily adapted to devise key-finding algorithms for other schemes. These algorithms simply search for special secret-key-identifying characteristics in the secret key in-memory formats as identifying labels for sequences of bytes. More precisely, these algorithms search for byte sequences with low Hamming distance to these identifying labels and verify that the remaining bytes in a possible sequence satisfy some conditions.
Once the previous problems have been dealt with, the attacker now has access to a version with errors of the original secret key obtained from the memory image. Therefore the attacker's aim is to reconstruct the original secret key from its noisy version, which is a mathematical problem. Moreover, we remark that the attacker may have access to cryptographic data associated with the key to be reconstructed (e.g., ciphertexts for a symmetric key encryption scheme) or the attacker may have access to public parameters of the cryptosystem (e.g., public key for a asymmetric key encryption scheme). The main center of interest of cold boot attacks has been so far to devise, develop and implement key-recovery algorithms to efficiently and effectively reconstruct secret keys from its noisy versions for different cryptographic schemes and testing these algorithms to learn how much noise they can tolerate.

Cold Boot Attack Model
Based on our previous discussion on cold boot attacks, we assume an adversary has knowledge of the defined structures for the storage of the target private key in memory and has possession of the corresponding public parameters without any noise. Moreover, we assume the attacker procures a noisy version of the target private key via a cold boot attack. However, we do not tackle the issue of locating the memory region where the bits of the private key are stored. Such issue would be of great importance to deal with when carrying out this attack in practice and may be tackled via applying several key finding algorithms [10]. As a result of this assumption, the adversary's main objective is to reconstruct the original private key.
We denote α = P(0 → 1) as the probability of a 0 to 1 bit-flipping, i.e., that a 0 bit in the private key changes to a 1 bit in its noisy version. Moreover, we denote β = P(1 → 0) as the probability of a 1 to 0 bit-flipping, i.e., that a 1 bit in the private key changes to a 0 bit in its noisy version. According to our previous discussion on cold boot attacks, one of these values normally may be very small (approximately 0.001) and not liable to variation over time, while the other values do increase over time. Moreover, the adversary may estimate both α and β and they remain unchanged across the memory region where the bits of the private key are stored. As stated by our previous discussion on cold boot attacks, these suppositions are plausible, since an adversary may estimate the error probabilities by comparing original content with its corresponding noisy version (e.g., using the public key), and the memory regions are normally large.

Previous Work
Throughout this section, we present our literature review, describing works on cold boot attacks against multiples cryptographic schemes. These studies can be divided into several categories, namely the RSA setting, the discrete logarithm setting, the symmetric key setting and finally the post-quantum setting.

RSA Setting
The research paper by Heninger and Shacham [28] was the first work dealing with this attack on RSA keys. They presented a key-recovery algorithm, which relies on Hansel lifting, and exploited the redundancy found in the common RSA secret key in-memory format. The research papers by Henecka et al. [29] and Paterson et al. [30] followed the inaugural paper and both research papers further exploited the mathematical structure on which RSA is based. Additionally, the research paper by Paterson et al. [30] further centered on the error channel's asymmetric nature, which is intrinsically connected to the cold boot setting, and also considered the key-recovery problem from an information theoretic perspective.

Discrete Logarithm Setting
The first paper that explored this attack in the discrete logarithm setting was that of Lee et al. [31]. Their key-recovery algorithm is limited due to the cold boot attack model they assumed. In particular, their work focused on recovering the secret key x, given the public key g x , with g being a field element and x being an integer. Their model, in addition to assuming the attacker has knowledge of the public key g x and of the noisy version of the private key x, supposes the adversary knows an upper bound on the number of errors found in the noisy version of the secret key. Since knowing such an upper bound may not be practical and small redundancy in the secret key was exploited, their key-recovery algorithm is not expected to recover keys if these are subjected to a high level of noise, or if a bit-flipping model is assumed. A follow-up work by Poettering and Sibborn [32] also studied this attack in the discrete logarithm setting, more concretely in the elliptic curve cryptography setting. Their work was more practical, since they had a deep review of two implementations for elliptic curve cryptography. With such review, they found redundant in-memory formats and focused on two common secret key in-memory formats from two popular ECC implementations from TLS libraries. The first one is the windowed nonadjacent form (wNAF) representation, and the second is the comb-based representation. For each format, they developed dedicated key-recovery algorithms and tested them both in the bit-flipping model.

Symmetric Key Setting
Regarding this attack against symmetric key primitives, there are also a few papers that explored this attack against a few block ciphers. The paper by Albrecht and Cid [33] centered on the recovery of symmetric encryption keys by employing polynomial system solvers. Particularly, they used integer programming techniques to apply them for keyrecovery of the Serpent block cipher's secret key. Furthermore, they also introduced a dedicated key-recovery algorithm to Twofish's secret keys. Moreover, the paper by Kamal and Youssef [34] introduced key-recovery algorithms based on SAT-solving techniques to the same problem. We refer the interested reader to [33][34][35] for more details.

Post-Quantum Setting
Regarding the viability of carrying out this attack against post-quantum cryptographic schemes, there are already several works showing the feasibility of this attack against some post-quantum cryptographic schemes implementations. The first paper that evaluated a post-quantum cryptographic scheme in this setting was that of Paterson et al. [36]. They looked into this attack against NTRU and their work reviewed two existing NTRU implementations, the ntru-crypto implementation and the tbuktu Java implementation based on Bouncy Castle. For each in-memory format found in these implementations, they introduced dedicated key-recovery algorithms and tested them in the bit-flipping model. According to the results reported in [36], their key-recovery algortihm was able to find the private key, when α is fixed and small and β ranges from 1% up to 9%, for one of the private key in-memory representations. This paper was followed upon by that of Villanueva [11], which extended previous results and introduced a general key-recovery strategy via key enumeration. Additionally, they applied their general strategy to BLISS and their results are comparable to the results reported for the NTRU case. Another recent paper by Villanueva [37] adapted and applied this general key-recovery strategy to the signature scheme LUOV, exploiting the fact that LUOV's private key is a 256 bit string, and showed the versatility of this general key-recovery strategy and promising results. Moreover, Albrecht et al. [38] investigated cold boot attacks on post-quantum cryptographic schemes based on the ring-and module-variants of the Learning with Errors (LWE) problem. Their work centered on Kyber key encapsulation mechanism (KEM) and New Hope KEM, where two encodings were considered to store LWE keys (polynomials): coefficient-based in-memory format and number-theoretic-transform (NTT)based in-memory format. Finally, they presented dedicated key recovery algorithms to tackle both cases in the bit-flipping model.

General Strategy to Key Recovery
According to the work by Villanueva [11,27], we can deal with the key-recovery problem in the cold boot attack setting via key enumeration algorithms. Let string with the noisy bits of the secret key encoding. Note that ch may be written as a sequence of N = W/w chunks, with each chunk being a w bit-string, i.e., ch . On the condition that we have access to a suitable key-recovery algorithm, we can generate full key candidates c for the original secret key encoding. Based on Bayes's theorem, the probability of c being the right full key candidate given the noisy version ch is given by P(c|ch) =

P(ch|c)P(c) P(ch)
. Therefore, c should be chosen so as to maximize this probability, according to the maximum likelihood estimation method. Note that both P(ch) and P(c) are constants, with the former independent of c, and that P(ch|c) = (1 − α) n 00 α n 01 β n 10 (1 − β) n 11 , where n 00 counts the positions in which both c and ch contain a 0 bit, n 01 counts the positions in which c contains a 0 bit and ch contains a 1 bit, etc. Hence our optimization problem reduces to find the candidate c to maximize this probability P(ch|c). Note that this problem can be stated equivalently as choosing c that maximizes the log of these probabilities log(P(ch|c)) = n 00 log(1 − α) + n 01 log α + n 10 log β + n 11 log(1 − β). Therefore, each candidate can be assigned a score, namely S(c, ch) := log(P(ch|c)).
If we now assume that the full key candidates c may be written as a sequence of chunks as for ch, i.e., c = c 0 ||c 1 ||. . .||c N −1 , with c i being a sequence of w bits, then we may also assign a score to each of the at most 2 w values for a chunk candidate c i .
where the n i ab values count occurrences of bits across the i th chunks, lists of chunk candidates, containing up to 2 w entries, may be created. More concretely, each list contains at most 2 w 2-tuples of the form (score, value), where the first component score is a real number (candidate score) and the second component value is a w-bit string (candidate value). Now note that the original key-recovery problem reduces to an enumeration problem that consists in traversing the lists of chunk candidates to produce full key candidates c of which total scores are obtained by summation. Fortunately for us, the enumeration problem has been previously studied in the side-channel analysis literature [12][13][14][15][16][17][18][19][20][21][22][23][24][25][26][27], and there are many algorithms that may be useful for our key-recovery setting, in particular those producing full key candidates sorted in descending order based on the score component.
More formally, let L i = c i 0 , c i 2 , . . . , c i m i −1 be a list of chunk candidates for chunk ch i , with 0 < m i ≤ 2 w and c i j = score i j , value i j . Given the chunk candidates c , . . . , c i n j n as a function that out-puts a new chunk candidate c computed by setting c = c i 0 c is known as a full key candidate. The key enumeration problem entails choosing a chunk candidate c i conditioned to a rule on their scores [27]. An algorithm that enumerates full key candidates c is known as a key enumeration algorithm (KEA).
For our key-recovery problem, we use an algorithm that combines two key enumeration algorithms and is based on one introduced in [11,37]. Moreover, we also exploit the in-memory representation of the secret key of SIKE mechanism to improve our results. This key-recovery algorithm will be described in Section 4.2.

Supersingular Isogeny Key Encapsulation Mechanism
This section gives a brief account of the Supersingular Isogeny Key Encapsulation mechanism. This mechanism relies on Supersingular Isogeny Diffie-Hellman (SIDH), a key-exchange protocol introduced by Jao and De Feo in 2011 [2]. In particular, we follow the description provided by SIKE's specification submitted to the NIST post-quantum cryptography standardization process.

Mathematical Foundations
Let F p be a finite field, with p being a prime number. The elements of this field are represented by the integers in the set {0, 1, 2, . . . , p − 1}. These elements are operated with the two common operations, addition and multiplication modulo p.
The quadratic field extension F p 2 can be constructed easily from F p . In particular, the elements of F p 2 are represented by e = e 0 + e 1 ·i, where e 0 , e 1 ∈ F p , i ∈ F p 2 , with i 2 = −1. Note that e can also be represented as a 2-tuple (e 0 , e 1 ) ∈ F 2 p . The addition and multiplication operations are defined as follows: where the element operations take place in F p . Equivalently, Since F p 2 is a field, we can compute the additive inverse of a, denoted by −a, and also the multiplicative inverse of a, denoted by a −1 . To see more details on how all field operations are calculated, we refer the reader to [1].

Montgomery Curves
A Montgomery curve is a special form of an elliptic curve. Let F q be a finite field, where q = p n , p a prime number with p ≥ 3, and let A, B ∈ F q be field elements satisfying B A 2 − 4 = 0 in F q . A Montgomery curve E A,B defined over F q , denoted by E A,B /F q , is defined to be the set of points P = (x P , y P ) of solutions in F q to the equation The set of points of E A,B /F q together with the point at infinity, denoted by O, form a finite abelian group under a point addition operation, denoted by E A,B F q . That is, given Consequently, we also can compute [2]P = P + P, [3]P = P + P + P or in general [k]P = P + P + P + · · · + P (k times, with k ≥ 0). These operations are called point doubling, point tripling or point multiplication, respectively. To see more details on how to do these computations, we refer the reader to [1].
The order of an elliptic curve E over a finite field F q , denoted by #E F q , is the number of points in E including O. Additionally, the order ord(P) of a point P is the smallest positive integer n such that [n]P = O.
Given an abelian group G, we say a set of elements {P 1 , P 2 , · · · , P t } ⊆ H forms a basis of the subgroup H ≤ G if every element P of H can be represented by a unique expression of the form P = [ Consider an elliptic curve E F q and a positive integer m, we define the group of . The j-invariant of an elliptic curve over a field F q is unique up to the isomorphism of the elliptic curve. The SIKE protocol defines a shared secret as a j-invariant of an elliptic curve.

Isogenies
Let E 1 and E 2 be elliptic curves over a finite field F q . An isogeny Φ : and q(x) over F q , where p(x) and q(x) do not have a common factor, and similarly for g(x). We define the degree deg(Φ) of the isogeny to be max{deg(p(x)), deg(q(x))}, where p(x) and q(x) are as above. Given an isogeny Φ : where the curve E 2 ∼ = E 1 /H. We can compute the isogeny Φ and the curve E 1 /H for a given a subgroup H ≤ E 1 F q , using Vélu's formula [39]. However, it is computationally impractical for arbitrary subgroups. SIKE uses isogenies over subgroups that are powers of 2, 3 and 4 [1].

Key Encapsulation Mechanism
This section describes the components of the supersingular isogeny key encapsulation mechanism as in [1].

Public Parameters
We start off by describing the public parameters that SIKE makes use of: • A prime number of the form p = 2 e 2 3 e 3 − 1, where e 2 and e 3 are two positive integers. • A starting supersingular elliptic curve defined as E 0 /F p 2 : • Two points P 2 and Q 2 in E 0 [2 e 2 ], such that both points have exact order 2 e 2 and • Two points P 3 and Q 3 in E 0 [3 e 3 ], such that both points have exact order 3 e 3 and These points are normally encoded for efficiency. Particularly, the points P 2 and Q 2 are encoded as a byte array from the three x-coordinates x P 2 , x Q 2 and x R 2 , where R 2 = P 2 − Q 2 . Similarly, the points P 3 and Q 3 are encoded as a byte array from the three x-coordinates

Secret Keys
Two secret keys, sk 2 and sk 3 , are used to compute 2 e 2 -isogenies and 3 e 3 -isogenies, respectively. On the one hand, the secret key sk 2 is an integer in the set {0, 1, . . . , 2 e 2 − 1} and is stored as a byte array of length N sk 2 = e 2 8 . The corresponding keyspace is denoted K 2 . On the other hand, the secret key sk 3 is an integer in the set 0, 1, . . . , 2 log 2 3 e 3 − 1 and is stored as a byte array of length N sk 3 = log 2 3 e 3 8 . The corresponding keyspace is denoted K 3 .

Isogeny Algorithms
Let l, m ∈ {2, 3} with l = m. The two core isogeny algorithms used in SIKE are isogen l and isoex l . On the one hand, the algorithm isogen l takes in the public parameters and a private key sk l as inputs and returns the corresponding public key pk l . Specifically, it computes S = (x S , y S ) = P l + [sk l ]Q l and then computes the l e l -degree isogeny Φ : E 0 → E a ,b via the composition of e l individual l-degree isogenies, where E a ,b ∼ = E 0 / S , and returns the points Φ(P m ) and Φ(Q m ) encoded as a byte array from three x-coordinates as the public key, i.e., pk l = On the other hand, the algorithm isoex l receives a secret key sk l and a public key pk m as inputs, and then outputs the corresponding shared key. Specifically, on receiving a private key sk l and an encoded public key pk m = x P l , x Q l , x R l , it then decodes pk m to get the corresponding curve E a ,b and the points P l and Q l , then computes S = (x S , y S ) = P l + [sk l ]Q l and the l e l -degree isogeny Φ : E a ,b → E a,b via the composition of e l individual l-degree isogenies, where E a,b ∼ = E a ,b / S , and finally returns j(E a,b ).

The Reference Implementation
In this section, we review the SIKE's main algorithms as in the reference implementation (see the file sike.c). Reviewing this implementation is of great importance to learn the in-memory representation used to store private keys.
Let n denote the length in bits of the messages to be encapsulated, i.e., n ∈ {128, 192, 256}, and let k denote the number of bits of the output shared key, i.e., k ∈ {128, 192, 256}. Also, SHAKE 256 (m, d) denotes hashing the message m and obtaining only d bits from the output, i.e., the output may be regarded as an infinite bit string, of which computation is stopped after the desired number of output bits is produced [40].
The first algorithm to describe is the key generation algorithm. It is the most relevant algorithm for our work, so we describe it in more detail. Algorithm 1 shows a pseudo-code of the key generation algorithm's implementation. It takes in Params, that contains n, N sk 3 , and MASK, and first generates a random n/8 byte array, then generates a secret key sk 3 chosen uniformly at random in the keyspace K 3 and finally calls isogen 3 to get the corresponding encoded public key. The in-memory representation of the private key is a byte array of length n/8 + N sk 3 + l pk , where l pk is the length in bytes of the encoded public key. The first n/8 bytes correspond to s, the next N sk 3 bytes correspond to the secret key sk 3 and finally the last bytes correspond to the encoded public key pk 3 . Note that pk 3 is the only publicly known part stored in the private array. s ← randombytes( Params.n/8 ) ; // generate a random N sk 3 byte array.
sk 3 ← randombytes(Params.N sk 3 ) ; // masking last byte of sk 3 to guarantee sk 3 is in K 3 . MASK depends on the chosen parameters.
MASK ; // generate the corresponding public key pk 3 . pk 3 ← isogen 3 (sk3, Params) ; return (s, sk 3 , pk 3 ); end function Regarding the encapsulation mechanism for SIKE, as described by Algorithm 2, it basically generates a message in the message space and hashes it along with the given public key to get r, which is passed as key in K 2 to isogen 2 to compute the corresponding public key c 0 and the shared string j. The value j is hashed to get h, which is xored with m to get c 1 , and then the shared key K is computed and returned, along with the ciphertext (c 0 , c 1 ).

Algorithm 2 Encapsulation algorithm for SIKE.
function Encaps(pk 3 , Params) m ← randombytes( Params.n/8 ) ; r ← SHAKE 256 (m || pk 3 , Params.e 2 ) ; c 0 ← isogen 2 (r, Params) ; j ← isoex 2 (pk 3 , r, Params.e 2 ) ; h ← SHAKE 256 (j, Params.n) ; Regarding the decapsulation mechanism for SIKE, as described by Algorithm 3, it basically computes the shared string j from c 0 and the secret key sk 3 . It then recomputes h, then m and then r , which is used to compute c 0 . At this point, it compares c 0 with the given c 0 . If they are equal, then the real shared key K is computed and returned, otherwise a fake shared key is computed and returned.

Algorithm 3 Decapsulation algorithm for SIKE.
function Decaps((s, sk 3 , pk 3 ), (c 0 , c 1 ), Params ) Table 1 shows relevant entries from each SIKE parameter for our key-recovery attack. For a comprehensive list of all entries defined for each SIKE parameter, such as P 2 , Q 2 ,R 2 , P 3 , Q 3 and R 3 , we refer the reader to [1,9].

Key Recovery
Throughout this section, we give a detailed account of our key-recovery algorithm, which relies on the general key-recovery strategy described in [11,27].

Assumptions
Based on the model we described in Section 2.2, we suppose that an adversary procures a noisy version of a SIKE's private key encoding as it is stored by the reference implementation. In particular, the adversary procures an array containing (s, sk 3 , pk 3 ). Additionally, such adversary accesses the corresponding original public parameters (i.e., without noise), so such adversary may use them to properly locate the offset from which the secret key bits (sk 3 ) are stored via running key-finding algorithms exploiting identifying features found in the memory formats for storing the SIKE's private key. These algorithms would be similar to those developed for the RSA setting [10].
Additionally, by α = P(0 → 1) we denote the probability for a 0 bit of the original secret key to change for a 1 bit, and by β = P(1 → 0) we denote the probability for a 1 bit of the original private key to change for a 0 bit. According to our model, the attacker knows both α and β, since these values are fixed across the memory region in which the secret key is located and can be easily estimated by comparing any noisy content with its corresponding original one (e.g., the public key). Moreover, memory regions are normally large and the size in bytes of sk 3 is at most 48 bytes according to Table 1.

Our Key-Recovery Algorithm
Throughout this section we give a detailed account of our key-recovery strategy, taking into consideration the notation introduced in Section 2.3.5 and the review of SIKE's reference implementation.
Let ch = b 0 b 1 b 2 . . . b W be W bit string that represents the noisy version of the secret key encoding sk 3 . Note that the value for W depends on the SIKE parameters on which SIKE is configured. In particular, W = 8·N sk 3 (see the fourth column of Table 1). We denote w as the size in bits of a chunk (it is set to 8), and so ch can be written as a sequence of N = W/w chunks ch = ch 0 ||ch 1 ||. . .||ch N −1 with ch i = b i·w b i·w+1 . . . b i·w+(w−1) . We define a block B k m = ch k ||ch k+1 ||· · ·||ch k+m−1 as a sequence of consecutive chunks, where 0 ≤ k ≤ k + m − 1 < N and m is the number of chunks in the block. We can now rewrite ch as a concatenation of n b blocks, namely

4.
For each block B m 0 +m 1 +...+m j−1 m j , with 0 ≤ j < n b and m −1 = 0, then the lists stored in L at indexes m 0 + m 1 + . . . + m j−1 + k for 0 ≤ k < m j are given as parameters to an optimal key enumeration algorithm, which we denote as OKEA, to produce the list L B j that contains the M j candidates with the highest scores for the block B m 0 +m 1 +...+m j−1 m j .

5.
All lists L B j are given as parameters to an instance of a key enumeration algorithm (KEA). This instance regards each L B j as a list of suitable candidates for the corresponding block B m 0 +m 1 +...+m j−1 m j and outputs high-scoring full key candidates for the target secret key encoding. Upon generating a full key candidate c, our algorithm passes it as input to a testing function (Test in our case) to verify whether the full key candidate c is a valid secret key or not.
Algorithm 4 shows a pseudo-code of our key-recovery algorithm. Note that OKEA points to the optimal key enumeration algorithm that our key-recovery algorithm runs at step 4, and KEA points to the key enumeration algorithm that our key-recovery algorithm runs at step 5. Additionally, args refers to the arguments that the algorithm pointed by KEA may take in and Test is a pointer to the testing function Test, i.e., Algorithm 5. We next expand on our choice of key enumeration algorithms for our key-recovery algorithm.

On Our Choice of an Optimal Key Enumeration Algorithm
Our key-recovery algorithm requires an optimal key enumeration algorithm run at step 4 to enumerate full key candidate c sorted by their scores in descending order. There are several algorithms suitable for this task [12,27,41], and we use the algorithm (OKEA) from [12], since it is flexible and easy to implement. Additionally, note that OKEA is an inherently sequential algorithm, and so its optimality property is fulfilled only if it is not run in parallel. In addition, its memory consumption may be high if used to enumerate many candidates [27]. In our setting, we select M j to be a value in the set {256, 512, 1024} for all 0 ≤ j < n b .

On Our Choice of Non-Optimal Key Enumeration Algorithms
Regarding the key enumeration algorithm (KEA) that our key-recovery algorithm runs at step 5, this algorithm is required to be parallelizable and memory-efficient, since this step of our approach requires a considerably high amount of computational resources. Here we explore the use of two different key enumeration algorithms. On the one hand, we use an algorithm called NOKEA, which combines several good characteristics from multiples algorithms (KEAs) [11,37]. This particular algorithm may be configured to search over a well-defined range [a, b], where a ≤ b ≤ max and max is the maximum total score that a full key candidate may be given to. In this configuration, this algorithm enumerates each possible full key candidate of which total score lies in the chosen interval [a, b] [11]. We expand on the use of this algorithm in Section 5.1, in which we also present the success rates of our key-recovery algorithm. On the other hand, we also explore how to combine our key-recovery algorithm with a quantum key enumeration algorithm [42], which we denote by QKEA, that combines a non-optimal key enumeration algorithm and the Grover algorithm [43]. We expand on this in Section 5.2.
L ch i .add((score, c));// adds the tuple (score, c) to the list. end for L ch i .sort()// this sorts the list L ch i by score in descending order. L.add(L ch i )// this appends the list L ch i to the index i of L. n B ← len(P); // The next instruction inits OKEA passing it the lists L ch s , . . . , L ch s+P[j]−1 obtained from L.

OKEA.init(L, s, P[j]);
// The next instruction returns the best block candidate for block j and appends it to L B j . L B j .add(OKEA.getNextCandidate()); end for L B .add(L B j ); // L B is an accessory list to store lists L B j . s ← s + P[j]; // this updates s, the starting index for the next block. end for // The next instruction inits KEA passing it the lists in L B and args.
KEA.init(L B , args); // The next instruction runs KEA passing it Params and a pointer to the function Test, i.e., Algorithm 5.

Evaluation of Our Key-Recovery Algorithm
Throughout this section we assess our key-recovery algorithm. We first give a detailed account of how we compute the success rates for our key-recovery algorithm considering several scenarios, each with a different set of SIKE parameters, and finally show how to integrate a quantum key search algorithm (QKEA) to our key-recovery algorithm to improve its overall performance.

Performance and Success Rates of Our Key-Recovery Algorithm
This section reports success rates of our key-recovery algorithm. We first note that in this setting the attacker procures a noisy version ch of sk 3 via a cold boot attack, as stated in Section 4.1, and so our key-recovery algorithm tries to find a full key candidate for sk 3 from the noisy version. In order to compute estimates for success rates of our key-recovery algorithm, we analyze the following scenarios. For a given set of instance parameters, we calculate the success rate for our key-recovery algorithm with NOKEA if it is set to (1) enumerate all the possible full key candidates; (2) enumerate an interval with roughly 2 30 full key candidates; (3) enumerate an interval with roughly 2 40 full key candidates; (4) enumerate an interval with roughly 2 50 full key candidates. In this context, by instance parameters we mean setting the array P, the array M, w (normally 8), α, β, together with the selected SIKE parameters.
Note that given the noisy version ch and the instance parameters, our key-recovery algorithm creates the lists L B j at the end of step 4, then these are passed to NOKEA at the beginning of the step 5. Here is where we exploit several features of this algorithm in order to compute estimates for the success rates without actually running an enumeration with NOKEA. In particular, we exploit the fact that NOKEA can enumerate full key candidates of which total scores belong to a given interval in order from the highest to the lowest total score and that many scores of block candidates for a given block are repeated [11,36,44]. In particular, once the lists L B j are created, our tweaked NOKEA creates factorized lists, one per list L B j , that contain entries of the form (score, count) where score represents a score and count is the number of block candidates having score as score in the corresponding list L B j . These factorized lists are passed to an alternative version of OKEA, where count is seen as a candidate value, and it generates another factorized list L with entries of the same form (score, count), which is sorted by score in descending order, i.e., from the highest to the lowest score. An entry (score, count) may be interpreted as there are count full key candidates of which total score is equal to score. To calculate estimates for success rates, we run our tweaked key-recovery algorithm with all required parameters a fixed number of times (100 times) and then compute the corresponding success rate. Specifically, at each trial the SIKE key generation algorithm is run to obtain (s, sk 3 , pk 3 ) according to the selected set of SIKE parameters, and then sk 3 is perturbed as per α and β and then our tweaked key-recovery algorithm is called by passing the noisy version ch, the instance parameters and the original key as parameters. It then runs until generating the lists L B j and, at such point, checks that each block of the original key is found in the corresponding list L B j . If so, it means that a complete enumeration, carried out by NOKEA, would not fail in finding the secret key (it would fail otherwise). On the condition that the complete enumeration will not fail, the tweaked NOKEA is run to create the factorized list L, which is used to determine if the original key may be found by the instance of NOKEA if it enumerates a range having roughly 2 30 or 2 40 or 2 50 full key candidates. In particular, say, we want to determine if the original key can be found via enumerating a range with approximately 2 a full key candidates, a ∈ {30, 40, 50}, then the algorithm finds an entry at index e in L such that e is the smallest integer satisfying 2 a < ∑ e k=0 L[k].count. If the score calculated for the original key (from the noisy version) lies in the interval [L[e].score, L[0].score], then it signifies that an enumeration in such interval (which contains at least 2 a candidates) will find the original key. We next describe the instance parameters we used to run our trials.

SIKEp434
For this set of SIKE parameters, sk 3 has a length of 28 bytes, Params.MASK = 0x01, which means that only the first bit of the last byte of sk 3 is used. Also, we set w to 8, P to [4,4,4,4,4,4,4] and M j to r, for 0 ≤ j < 7, where r ∈ {256, 512, 1024}. Note that the number of chunks is 28 and the number of blocks is 7. Figures 1 and 2 show the obtained results for this set of parameters.

SIKEp503
For this set of SIKE parameters, sk 3 has a length of 32 bytes, Params.MASK = 0x0F, which means that only the four first bits of the last byte of sk 3 are used. Also, we set w to 8, P to [4,4,4,4,4,4,4,4] and M j to r, for 0 ≤ j < 8, where r ∈ {256, 512, 1024}. Note that the number of chunks is 32 and the number of blocks is 8. Figures 3 and 4 show the obtained results for this set of parameters.
Additionally, the function Test for this set of parameters takes about 7,069,164 cycles to run in a virtual machine type e2-highcpu-16 with 16 vCPUs and 16 GB of memory deployed in the Google Cloud Platform. We remark that the success rates for this set of parameters and those obtained for LUOV [37] are essentially similar. This is expected since both LUOV's secret key and SIKE's secret key for this case are of length 32 bytes.

SIKEp503
For this set of SIKE parameters, sk 3 has a length of 32 bytes, Params.MASK = 0x0F, which means that only the four first bits of the last byte of sk 3 are used. Also, we set w to 8, P to [4,4,4,4,4,4,4,4] and M j to r, for 0 ≤ j < 8, where r ∈ {256, 512, 1024}. Note that the number of chunks is 32 and the number of blocks is 8. Figures 3 and 4 show the obtained results for this set of parameters.
Additionally, the function Test for this set of parameters takes about 7,069,164 cycles to run in a virtual machine type e2-highcpu-16 with 16 vCPUs and 16 GB of memory deployed in the Google Cloud Platform. We remark that the success rates for this set of parameters and those obtained for LUOV [37] are essentially similar. This is expected since both LUOV's secret key and SIKE's secret key for this case are of length 32 bytes. Additionally, the function Test for this set of parameters takes about 5,141,167 cycles to run in a virtual machine type e2-highcpu-16 with 16 vCPUs and 16 GB of memory deployed in the Google Cloud Platform.

SIKEp503
For this set of SIKE parameters, sk 3 has a length of 32 bytes, Params.MASK = 0x0F, which means that only the four first bits of the last byte of sk 3 are used. Also, we set w to 8, P to [4,4,4,4,4,4,4,4] and M j to r, for 0 ≤ j < 8, where r ∈ {256, 512, 1024}. Note that the number of chunks is 32 and the number of blocks is 8. Figures 3 and 4 show the obtained results for this set of parameters.

SIKEp610
For this set of SIKE parameters, sk 3 has a length of 38 bytes, Params.MASK = 0xFF, which means that all the bits of the last byte of sk 3 are used. We also set w to 8, P to [5,5,5,5,5,5,5,3] and M j to r, for 0 ≤ j < 8, where r ∈ {256, 512, 1024}. Note that the number of chunks is 38 and the number of blocks is 8. Figures 5 and 6 show the obtained results for this set of parameters.
Additionally, the function Test for this set of parameters takes about 12, 724, 569 cycles to run in a virtual machine type e2-highcpu-16 with 16 vCPUs and 16 GB of memory deployed in the Google Cloud Platform.

SIKEp610
For this set of SIKE parameters, sk 3 has a length of 38 bytes, Params.MASK = 0xFF, which means that all the bits of the last byte of sk 3 are used. We also set w to 8, P to [5,5,5,5,5,5,5,3] and M j to r, for 0 ≤ j < 8, where r ∈ {256, 512, 1024}. Note that the number of chunks is 38 and the number of blocks is 8. Figures 5 and 6 show the obtained results for this set of parameters.
Additionally, the function Test for this set of parameters takes about 12, 724, 569 cycles to run in a virtual machine type e2-highcpu-16 with 16 vCPUs and 16 GB of memory deployed in the Google Cloud Platform. Additionally, the function Test for this set of parameters takes about 7,069,164 cycles to run in a virtual machine type e2-highcpu-16 with 16 vCPUs and 16 GB of memory deployed in the Google Cloud Platform. We remark that the success rates for this set of parameters and those obtained for LUOV [37] are essentially similar. This is expected since both LUOV's secret key and SIKE's secret key for this case are of length 32 bytes.

SIKEp610
For this set of SIKE parameters, sk 3 has a length of 38 bytes, Params.MASK = 0xFF, which means that all the bits of the last byte of sk 3 are used. We also set w to 8, P to [5,5,5,5,5,5,5,3] and M j to r, for 0 ≤ j < 8, where r ∈ {256, 512, 1024}. Note that the number of chunks is 38 and the number of blocks is 8. Figures 5 and 6 show the obtained results for this set of parameters.

SIKEp751
For this set of SIKE parameters, sk 3 has a length of 48 bytes, Params.MASK = 0x03, which means that only the two first bits of the last byte of sk 3 are used. Also, we set w to 8, P to [6,6,6,6,6,6,6,6] and M j to r, for 0 ≤ j < 8, where r ∈ {256, 512, 1024}. Note that the number of chunks is 48 and the number of blocks is 8. Figures 7 and 8 show the obtained results for this set of parameters.
Additionally, the function Test for this set of parameters takes about 21,266,903 cycles to run in a virtual machine type e2-highcpu-16 with 16 vCPUs and 16 GB of memory deployed in the Google Cloud Platform.

SIKEp751
For this set of SIKE parameters, sk 3 has a length of 48 bytes, Params.MASK = 0x03, which means that only the two first bits of the last byte of sk 3 are used. Also, we set w to 8, P to [6,6,6,6,6,6,6,6] and M j to r, for 0 ≤ j < 8, where r ∈ {256, 512, 1024}. Note that the number of chunks is 48 and the number of blocks is 8. Figures 7 and 8 show the obtained results for this set of parameters.
Additionally, the function Test for this set of parameters takes about 21,266,903 cycles to run in a virtual machine type e2-highcpu-16 with 16 vCPUs and 16 GB of memory deployed in the Google Cloud Platform. Additionally, the function Test for this set of parameters takes about 12, 724, 569 cycles to run in a virtual machine type e2-highcpu-16 with 16 vCPUs and 16 GB of memory deployed in the Google Cloud Platform.

SIKEp751
For this set of SIKE parameters, sk 3 has a length of 48 bytes, Params.MASK = 0x03, which means that only the two first bits of the last byte of sk 3 are used. Also, we set w to 8, P to [6,6,6,6,6,6,6,6] and M j to r, for 0 ≤ j < 8, where r ∈ {256, 512, 1024}. Note that the number of chunks is 48 and the number of blocks is 8. Figures 7 and 8 show the obtained results for this set of parameters.

Results Discussion
Note that all plots depicted by Figures 1a-c, 3a-c, 5a-c and 7a-c, show a similar trend, namely, for all set of instance parameters and M j ∈ {256, 512, 1024}, the success rate for a complete enumeration dominates the success rate for a 2 50 enumeration, which in turn dominates the success rate for a 2 40 enumeration, and which in turn dominates the success rate for a 2 30 enumeration. This is in alignment with what we expected. Moreover, we remark that the success rate decreases as long as β increases, although there are a few cases where, given β 1 and β 2 with β 1 > β 2 , the success rate for β 1 is a bit larger than the success rate for β 2 . This is due to the manner in which an interval is constructed by the NOKEA algorithm (and hence its tweaked version). However, the general trend is that the success rate decreases while β increases, which is also in line with what is expected. Additionally, Figures 2a,  4a, 6a and 8a show similar trends when comparing success rates for M j ∈ {256, 512, 1024} in a full enumeration. Analogously, Figures 2b, 4b, 6b and 8b also show similar trends when comparing success rates for M j ∈ {256, 512, 1024} in a 2 40 enumeration.

Results Discussion
Note that all plots depicted by Figures 1a-c, 3a-c, 5a-c and 7a-c, show a similar trend, namely, for all set of instance parameters and M j ∈ {256, 512, 1024}, the success rate for a complete enumeration dominates the success rate for a 2 50 enumeration, which in turn dominates the success rate for a 2 40 enumeration, and which in turn dominates the success rate for a 2 30 enumeration. This is in alignment with what we expected. Moreover, we remark that the success rate decreases as long as β increases, although there are a few cases where, given β 1 and β 2 with β 1 > β 2 , the success rate for β 1 is a bit larger than the success rate for β 2 . This is due to the manner in which an interval is constructed by the NOKEA algorithm (and hence its tweaked version). However, the general trend is that the success rate decreases while β increases, which is also in line with what is expected. Additionally, Figures 2a,  4a, 6a and 8a show similar trends when comparing success rates for M j ∈ {256, 512, 1024} in a full enumeration. Analogously, Figures 2b, 4b, 6b and 8b also show similar trends when comparing success rates for M j ∈ {256, 512, 1024} in a 2 40 enumeration. Additionally, the function Test for this set of parameters takes about 21,266,903 cycles to run in a virtual machine type e2-highcpu-16 with 16 vCPUs and 16 GB of memory deployed in the Google Cloud Platform.

Results Discussion
Note that all plots depicted by Figure 1a-c, Figure 3a-c, Figures 5a-c and 7a-c, show a similar trend, namely, for all set of instance parameters and M j ∈ {256, 512, 1024}, the success rate for a complete enumeration dominates the success rate for a 2 50 enumeration, which in turn dominates the success rate for a 2 40 enumeration, and which in turn dominates the success rate for a 2 30 enumeration. This is in alignment with what we expected. Moreover, we remark that the success rate decreases as long as β increases, although there are a few cases where, given β 1 and β 2 with β 1 > β 2 , the success rate for β 1 is a bit larger than the success rate for β 2 . This is due to the manner in which an interval is constructed by the NOKEA algorithm (and hence its tweaked version). However, the general trend is that the success rate decreases while β increases, which is also in line with what is expected. Additionally, Figures 2a, 4a, 6a and 8a show similar trends when comparing success rates for M j ∈ {256, 512, 1024} in a full enumeration. Analogously, Figures 2b, 4b, 6b and 8b also show similar trends when comparing success rates for M j ∈ {256, 512, 1024} in a 2 40 enumeration.

Integrating a Quantum Key Search Algorithm with Our Key-Recovery Approach
Throughout this subsection we give a detailed account of a quantum key enumeration algorithm, denoted as QKEA [42], and show how to combine it with our key-recovery algorithm to improve its overall performance. We additionally derive the running time of step 5 of our key recovery algorithm (worst case) if QKEA is run. Recall that at step 5, the lists L B j , for 0 ≤ j < n b , will be given as parameters to an instance of the quantum key enumeration algorithm (QKEA).
QKEA relies on a non-optimal key enumeration algorithm developed from a rank algorithm (also known as a counting algorithm) by Martin et al. [17]. The core idea is to leverage the rank algorithm to return a single candidate key with a particular rank within a specific range. Additionally, we remark that this algorithm uses a map that associates each score with a weight (a positive integer), where the smallest weight is regarded as the likeliest one [17].
We assume the scores from each block candidate in the list L B j , for 0 ≤ j < n b , are mapped to weights, as shown in [27,42]. Given the range [B 1 , B 2 ), the rank algorithm constructs a two dimensional array B with n b × B 2 entries, and then uses it to compute the number of full key candidates in the range. Algorithm 6 constructs the two dimensional array B and its running time is given by Note that, by construction, B 0,0 is the number of full key candidates of which total scores are in the interval [B 1 , B 2 ). So the rank algorithm simply returns B 0,0 and is described by Algorithm 7. Concerning its running time, it is given by T 2 (n b , M, B 2 ) = c 4 + T 1 (n b , M, B 2 ), where c 4 is a constant, i.e., an upper bound on the running time of primitive operations.
By calling the getKey function, Algorithm 9 tries to enumerate and test all full key candidates in the given interval [42]. Note that Test is pointer to the testing function (Algorithm 5). Concerning Algorithm 9's running time, it is given by T 4 (n b , M, B 2 , e) = c 8 + T 1 (n b , M, B 2 ) + e·(T 3 (n b , M) + c 9 + T(Params)), where e is the number of full key candidates in the range [B 1 , B 2 ), c 8 and c 9 are constants and upper bounds on the running time consumed by primitive operations, and T(Params) is the running time of the testing function (Algorithm 5).
Algorithm 9 enumerates and tests all full key candidates with weight in the interval [B 1 , B 2 ).

1:
function keySearch(B 1 , B 2 , Test) 2: B ← create(B 1 , B 2 ) ; 3: r ← 1 ; 4: while True do 5: k ← getKey(B, B 1 , B 2 , r) ; 6: if k = ⊥ then 7: break; 8: end if 9: if Test(k) = 1 then 10: break; 11: end if 12: r ← r + 1 ; 13: end while 14: return k; 15: end function Algorithm 10 calls the function keySearch to search over partitions selected independently with approximately a s full key candidates for s = 0, 1, . . . [42]. Regarding Algorithm 10's running time, this is given by  (6) where p = log a (e·(a − 1) + 1) and e ∈ 2 30 , 2 40 , 2 50 , c 10 , c 11 are upper bounds on the running time consumed by primitive operations, such as return operations, addition operations, comparison operations. The terms log 2 (e)·T 2 (n b , M, B e ) and log 2 (a s )·T 2 (n b , M, B 2 ) are the running times of steps 5 and 13 of Algorithm 10. Note that this algorithm is similar to NOKEA in the sense that it also enumerates full key candidates of which total scores belongs to the given range. Furthermore, the technique of partitioning the entire interval helps in improving the overall performance of Algorithm 10 when it is searching over an initial range with a large number of full key candidates.
Given the computational burden of Algorithm 10 lies on the execution of the function keySearch (at step 7), then any improvement on this search algorithm implies a speed-up on Algorithm 10's overall performance. The authors of [42] show how this part may be modified by replacing it for a Grover's oracle [43], and so improving Algorithm 10's overall performance. Algorithm 11 results from adjusting Algorithm 10 and relies on a Grover's oracle, giving a quadratic speed-up on searches over partitions. The function f(r) = Test(getKey (B, B 1 , B 2 , r)) returns 1, on the condition that r is the rank of the real secret key; otherwise, it returns 0. Grover's algorithm [43] shows that r can be found on a quantum computer in only O a s/2 ·T f steps, where T f is the time to evaluate f(r), i.e., T(Params) + T 3 (n b , M). Therefore Algorithm 11's overall running time is given by replacing T 4 (n b , M, B 2 , a s ) in Equation (6) for T 1 (n b , M, B 2 ) (step 7 of Algorithm 11) plus the running time for Grover's algorithm with f(r) (steps from 8 to 9 of Algorithm 11). Algorithm 10 performs a non-optimal enumeration over an interval with roughly e full key candidates.

Conclusions
This research paper addressed the question of the viability of cold boot attacks on SIKE. To this end, we reviewed SIKE's reference implementation as it was submitted to the NIST Post-Quantum Cryptography Standardization Process. Furthermore, we presented a dedicated key-recovery algorithm for SIKE in this setting and showed, through simulations, that our algorithm can reconstruct the secret key for SIKE, configured with any SIKE parameters, for varying values β ∈ {0.001, 0.01, . . . , 0.1} and α = 0.001, by only performing a 2 30 enumeration. We stress these success rates from our algorithm can be improved as long as there are more available resources to run it. Additionally, we showed that our algorithm could be sped-up by integrating a quantum key search algorithm with it, which brings the computation power of quantum computing into the post-processing phase of a side channel attack. Moreover, as a future work, we may extend our work to include a resource estimation of quantum gates resulting from running our quantum key-recovery algorithm against SIKE or other cryptographic primitives in the post-processing phase.

Conflicts of Interest:
The authors declare no conflict of interest.