Applied Kleptography in TLS

Masaryk University Faculty of Informatics

Master’s Thesis

Bc. Adam Janovský

Brno, Spring 2018

Declaration

I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source.

Bc. Adam Janovský

Advisor: Mgr. et Mgr. Jan Krhovják, Ph.D.

i Abstract

The goal of this thesis is to examine the possibilities of kleptography in TLS protocol. Kleptography is a study of stealing information securely and subliminally from black-box cryptographic devices. Information is exfiltrated from the system via backdoored algorithm inside asymmetri- caly encrypted subliminal channel. The thesis first introduces the field of kleptography and illustrates the problems on RSA and ELGamal cryptosystems, and on Diffie-Hellman protocol for key exchange. Next, the thesis revisits the TLS protocol and reviews existing proposals of kleptographic backdoors in TLS protocol. Further, several improvements in construction of such backdoor are proposed. The thesis argues that the novel proposal is a kleptographic backdoor relying on computational security. In addition, the proposal is implemented into the OpenSSL library as a proof-of-concept. Finally, the thesis studies possible ways of detection of the backdoor in the TLS protocol.

ii Keywords

Backdoor, cryptovirology, information security, kleptography, TLS

iii

Contents

1 Introduction 1

2 Preliminaries 3 2.1 Black-box cryptography ...... 3 2.2 Covert and subliminal channels ...... 5

3 Kleptography Overview 9 3.1 History of kleptography ...... 10 3.2 SETUP concept ...... 11 3.3 SETUP examples ...... 13 3.3.1 SETUP in RSA ...... 13 3.3.2 SETUP in ElGamal ...... 16 3.3.3 SETUP in Diﬃe-Hellman protocol ...... 17 3.4 Kleptography in the wild ...... 18 3.5 Defences ...... 19

4 Kleptography in TLS 23 4.1 Transport Layer Security ...... 23 4.1.1 TLS Handshake ...... 23 4.1.2 Master secret derivation ...... 25 4.2 Proposed asymmetric backdoors for TLS ...... 27 4.2.1 SETUP by Gołębiewski et al...... 28 4.2.2 SETUP by Yung and Young ...... 30 4.2.3 Comparison of proposed solutions ...... 34

5 Proposal of SETUP for TLS 35 5.1 SETUP design ...... 35 5.1.1 Desired improvements ...... 35 5.1.2 Backdoor description ...... 37 5.1.3 Properties of SETUP proposal ...... 38 5.1.4 Additional key exchange methods ...... 40 5.2 Implementation ...... 42

6 Heuristic Backdoor Detection 43 6.1 Tests of randomness ...... 43 6.2 Timing experiments ...... 44

v 6.2.1 Experiment setup ...... 45 6.2.2 Average execution times ...... 46

7 Conclusions 49

Appendices 55

A Statistical Tests of Randomness Results 57

B Distribution of Execution Times 65

C Data Attachment 67

vi 1 Introduction

Security of communication over a computer network is being ensured by various cryptographic protocols and primitives. Together with advances in information hiding, new threats emerge, as careful design and implementation of cryptographic protocols is a complex task. Tamper-proof devices were proposed as a remedy for many security-related problems. Their advantage is undeniable since they are protected from physical attacks and to change the executed code is very diﬃcult. However, they inherently introduce a trust into the manufacturer. It was shown that such devices are theoretically vulnerable to the presence of so-called subliminal channels. Such channels can be used to exﬁltrate private information from the underlying system covertly, inside cryptographic primitives. Consequently, viruses can utilise subliminal channels to break the security of black-box devices. Since the topic of information security is ubiquitous in the era of computer networks, it is crucial to explore the potential of such cryptographic viruses in order to propose systematic defence.

This thesis studies kleptography – the art of stealing information securely and subliminally. The ﬁeld of kleptography was discovered in the 1990s by Yung and Young [1]. Kleptographic backdoors for many protocols and primitives were proposed ever since. As examples, the thesis mentions subverted RSA and ElGamal encryption schemes, and the Diﬃe-Hellman (DH) protocol for shared key exchange. Also, two concepts of kleptographic backdoors for Transport Layer Secure (TLS) protocol were proposed [2, 3]. However, the proposed concepts for TLS are rather theoretical, and it remained unknown whether such backdoor can pose a practical threat. The thesis aims to answer this question. In particular, this thesis presents and implements a kleptographic backdoor for TLS protocol.

In Chapter 2, the black-box environment is outlined and subliminal channels are introduced. Chapter 3 presents kleptography thoroughly. First, a history of kleptography is covered. Then, the thesis presents an asymmetric backdoor as a supreme tool of kleptography. Further, examples of kleptographic backdoors for RSA, ElGamal and Diﬃe-

1 1. Introduction

Hellman are presented. Lastly, the chapter comments on real-world exploitations of kleptography and introduces possible defences. Chapter 4 revisits the TLS protocol and critically reviews two proposals of an asymmetric backdoor for the TLS protocol. Chapter 5 builds on the proposed backdoors for TLS, improves them, and describes the process of implementing the backdoor as a proof-of-concept into the OpenSSL library. Finally, Chapter 6 discusses potential detection mechanisms of the implemented backdoor.

2 2 Preliminaries

2.1 Black-box cryptography

This chapter aims to introduce the context of black-box cryptography and to outline information channels that can be exploited for malicious purposes. Only a minimum amount of theory on cryptography is given throughout the thesis. The reader is therefore assumed to have knowledge of cryptography and related mathematical disciplines, e.g., number- theory or algebra. To address the aspects of malware in black-box cryptographic devices, the thesis first revisits the definition of a black- box cryptosystem from [4]. Definition. A black-box cryptosystem is an efficient probabilistic algorithm that has readable and writeable non-volatile memory. In other words, it has access to a fair coin and can store variables across multiple invocations. Furthermore, the algorithm and memory are not externally accessible. Only the input and output of the cryptosystem is accessible.

The definition puts strong assumption on black-box cryptographic devices, namely that the internals of those cannot be scrutinized. Such assumption does not hold for most devices in real settings. Even tamper- resistant devices cannot be considered perfectly secure against internals analysis. The thesis adopts rather subtle definition of a black-box cryptographic device. We say that a cryptographic device is considered a black-box device if its internals cannot be easily scrutinized. Often, such device is special purpose hardware – a smart card or SSL accelerator for instance. Yet, there exists proprietary software that has not been fully reverse engineered for several years despite widespread use. An example of such software can be Skype. Why is it that some software gets reverse engineered quickly after the release and some not? The difficulty of reverse engineering is regularly increased by obfuscation of binaries. This practice is known as ‘security by obscurity’ and aims at slowing down potential reverse engineering. Consider that there are also legal aspects of reverse engineering. Accordingly, when examining the

3 2. Preliminaries impact of malware in black-box devices, one should not be limited to tamper-proof hardware. Due to the reasons above, the thesis considers proprietary software solutions as black-box devices as well. One could also say that every cryptographic device is a black-box until it is properly scrutinized. When the device gets scrutinized depends on whether the binaries of the device can be easily accessed and to what extent they are obfuscated. Nevertheless, stealthy malware can go undetected for several years in proprietary software. Notice that to detect malware in a certain type of devices, it is not suﬃcient to inspect a single piece of device. The malware may not be present in all devices of the same type.

Black-box cryptography certainly has some advantages; for instance, it is difficult to change the executed code and to attack from outside in black-box settings. Yet, black-box devices necessarily introduce trust into the manufacturer. Indeed, it does not suffice to verify the code authenticity by computing the checksum, but it is necessary to examine the code on assembly level. Observe that there is a conflict between securing the device and verifying its functionality. It is simple to confirm that the device fulfils the specifications. But as the saying goes — the secure program does what it is supposed to do, and nothing else. As stated in the definition of a black-box device, it is difficult or even impossible to prove that such device performs no additional computations.

Cryptographic devices that utilise public-key cryptography often commu- nicate public cryptographic keys, random nonces, challenges etc. Those can serve as a malicious information channel. Such channel can be exploited by a malware to exﬁltrate information from a device covertly. To remain undetected, the malware must utilise already existing information channels to leak the data. The thesis concentrates on malware that compromises the security of a cryptographic device by leaking some private information inside an implicit — already existing — information channel.

4 2. Preliminaries 2.2 Covert and subliminal channels

Several definitions of a covert channel exist that vary depending on the context. This thesis adopts the original definition published in [5]. Definition. A covert channel is a communication channel not designed for any kind of information transfer.

The original idea (from 1973) considered the use of covert channels inside a single computing system. In the 21st century, it is natural to expand the use of covert channels for transmission of information across multiple systems over a network. To give the reader an idea of how covert channel may look like, the thesis names several examples of covert channels: • Timing channel – if process completes an operation within a specified time window, 1 is decoded, 0 otherwise. • Power channel – power consumption of process is measured and used to derive bit string. • Termination channel – if process terminates (in certain time window), 1 is decoded, 0 otherwise. • Exhaustion channel – availability of resources signalizes bits. If some resource is available, 1 is decoded, 0 otherwise. It can be seen that various channels have various capacities. For instance, a termination channel can transfer only one bit at a time. On the contrary, the power channel can have much broader bandwidth. Also, notice the similarity between covert channels and side channels. Indeed, a side channel is a covert channel according to the definition. Yet, the covert channel is constructed and does not exist implicitly, whereas the existence of a side channel is related to the physical phenomena that accompany functioning of cryptographic devices and is therefore inevitable. The thesis continues with a definition of a subliminal channel from [4]. Definition. A subliminal channel is a channel that exists within a cryptographic protocol, authentication system, digital signature algorithm,

5 2. Preliminaries and so on, that transmits additional messages to a (special) receiver that is hidden, such that the messages cannot be read by other receivers (or a warden).

The receiver in this deﬁnition can be any passive eavesdropper. As a corollary, every subliminal channel is also a covert channel. Indeed, the cryptographic protocols were not designed to transmit any additional information. To illustrate the properties of subliminal channels, the thesis shows an example of a subliminal channel in ElGamal signature scheme1, as presented in [7]. Suppose that Alice and Bob share Alice’s private key x. Denote p the ElGamal group prime. Further let m0, where gcd(m0, p − 1) = 1, be the message that Alice wants to send subliminally to Bob. Alice can transfer the message inside a digital signature of an arbitrary message m in the following fashion. First, Alice computes

0 r = gm (mod p) and s = (m0)−1 · (H(m) − xr)(mod p − 1), where H represents cryptographically secure hash function. Then, Alice publishes the pair (r, s) as a digital signature of publicly available message m. Bob can then recover m0 by computing

m0 = s−1 · (H(m) − xr)(mod p − 1).

Notice that to protect the subliminal secret, value x must be kept secret. Consequently, this channel exhibits a common property among subliminal channels – vulnerability to known-plaintext attacks. Indeed, suppose that a warden guesses the plaintext m0. Then they can break the security of the channel by recovering the private key

x = −sr−1(m0 + s−1H(m)) (mod p − 1).

This undesirable property can be ﬁxed by encrypting the transmitted message m0. Asymmetric encryption introduces new randomness into

1. Consult [6] for the overview of the ElGamal scheme.

6 2. Preliminaries

the transmitted message m0, so that it could not further be guessed by the warden. If the value x was hard-coded on a black-box device, the subliminal channel would not resist reverse engineering of the device. If a warden gains access to the device and reverse engineers it, they obtain the hard- coded value x. Using the obtained key x, the warden can recover all past and future messages. Hence, this subliminal channel does not provide forward secrecy. That is because x serves as a symmetric key in this scheme. Subliminal channels can be further enhanced to utilise public- key cryptography for securing transmitted messages. A public key can be hard-coded to the target device. After reverse engineering, the adversary would only learn the value of a public key. Naturally, public keys are of no use when it comes to decryption. As a result, an asymmetrically encrypted subliminal channel provides the information exclusively to the designer. Another important aspect is that the subverted system still matches the I/O speciﬁcations. In such case, the created subliminal channel is called an implicit subliminal channel. The chapter concludes with introducing a dangerous application of subliminal channels in black-box cryptography devices. It is possible to modify the underlying protocol of the device to create an asymmetrically encrypted channel that communicates private information from the device securely and subliminally. Next chapter presents this scenario thoroughly.

3 Kleptography Overview

Kleptography is a study of stealing information securely and subliminally. Kleptography concerns black-box environment exclusively, as in white-box settings, it is not possible to invent undetectable subliminal channels. The work in kleptography utilises cryptology and virology and naturally extends the study of subliminal channels. Those are further encrypted and embedded into the devices, creating so-called asymmetric backdoors. As of 2018, secretly embedded backdoor with universal protection (SETUP) is a supreme (and only) tool in the field of kleptography. One could therefore say that kleptography studies development of asymmetric backdoors and possible defences against them at the same time. The objective of this chapter is to give a high-level overview of kleptography and to present selected backdoors for RSA, ElGamal, and Diffie-Hellman. The thesis follows with a definition of a SETUP adopted from [4]. Definition. Assume that C is a black-box cryptosystem with a publicly known specification. A SETUP mechanism is an algorithmic modification made to C to get C0 such that: 1. The input of C0 agrees with the public specifications of the input of C. 2. C0 computes efficiently using the attacker’s public encryption function E (and possibly other functions) contained within C0. 3. The attacker’s private decryption function D is not contained within C0 and is known only by the attacker. 4. The output of C0 agrees with the public specifications of the output of C. At the same time, it contains published bits (of the user’s secret key) which are easily derivable by the attacker (the output can be generated during key-generation or during system operation like message sending). 5. Furthermore, the output of C and C0 are polynomially indistinguishable to everyone except the attacker. 6. After the discovery of the specifics of the SETUP algorithm and after discovering its presence in the implementation (e.g. reverse engineering of hardware tamper-proof device), user (except the attacker) cannot determine past (or future) keys.

9 3. Kleptography Overview

The term SETUP was later simpliﬁed to an asymmetric backdoor by its authors. The thesis respects that and refers to a SETUP as to the asymmetric backdoor. Consider that the SETUP itself can be a subject of cryptanalysis as well. To keep the notation unambiguous, we call the person who attacks the SETUP an inquirer.

3.1 History of kleptography

In 1993 Yung and Young published paper [1] addressing the vulnerability of black-box devices to backdoors. They introduced the notion of SETUP and argued that black-box cryptographic devices are susceptible to such attacks. In the paper the authors presented the first ever SETUPs for RSA, ElGamal, and Kerberos protocol. The device studied in the article is called Capstone and was endorsed by the US government as a key escrow device [8]. Further advances in the field of kleptography were made mostly by Yung and Young. Thus, the reader can revisit their publications to get oriented in this topic. The thesis presents several offensive advances and puts them into historical context. Of course, the ultimate goal of kleptography is to eliminate presented threats. Defensive strategies are therefore presented in section 3.5. In [9] Yung and Young studied the twist of using cryptography as an offensive technology to deny confidentiality, integrity or availability. They concluded that strong cryptography yields strong cryptographic viruses. The paper [10] coined the term kleptography as an art of stealing information securely and subliminally. Further, a SETUP was established as a cornerstone of kleptography, and new asymmetric backdoors were proposed. For the first time, they utilised implicit channels – fully embedded into functioning of the underlying algorithms. Moreover, backdoors in the paper achieve forward secrecy. Recall that the example of the subliminal channel from the previous chapter lacked this property. A backdoor with optimal bandwidth was presented in [11]. Since the subliminal channels are of different capacities, the bandwidth-optimal backdoors are those that leak the whole private key inside one public message. That was achieved for DSA in the paper.

10 3. Kleptography Overview

Gathered knowledge was put together into a monograph [4]. In the book, cryptoviruses are studied exhaustively, and general guidelines for SETUP construction are given. As of 2018, new book that builds on the recent progress is being written by Yung and Young. Valuable drafts of chapters can be found at their website cryptovirology.com.

The problematic concept of asymmetric backdoors is that they often perform slower than the non-infected software. That is because new number-theoretic computations are introduced, exponentiations, and so forth. The ﬁrst practical backdoor that achieved better computation times than the original algorithm was presented in [12]. Yet, the performance was not achieved by design of the backdoor, but by remarkable advances in the implementation of OpenSSL RSA key generation. The authors made the process much more eﬃcient, which allowed for the infected library to run faster than the clean one.

Most of the previously mentioned work was done in a random oracle model. The reason is that messages in the subliminal channel were typically whitened by hashing. The First asymmetric backdoors not relying on random oracles were introduced in [3]. The authors employed a twisted pair of elliptic curves to generate shared secret which is polynomially indistinguishable from uniformly distributed bit string. The theory of cryptographic models is beyond the scope of this thesis. Still, for more material on this subject we refer the reader to [13, 14].

3.2 SETUP concept

Deﬁnition. A (m, n)-leakage scheme is a SETUP mechanism that leaks m keys/secret messages over n keys/messages that are output of the cryptographic device (m ≤ n).

The best leakage bandwidth that asymmetric backdoor can achieve is (m, m), meaning that the whole private information is leaked within one execution of the protocol. Another useful scheme is (m, m + 1) bandwidth, where the ﬁrst execution leaks no data, and subsequently, private information from the previous execution is leaked.

11 3. Kleptography Overview

Deﬁnition. A kleptogram is a publicly displayed value such as a ciphertext, signature, public-key, random nonce, and so forth, that also serves as an asymmetric backdoor.

Next, the thesis examines two variants of a regular SETUP. Deﬁnition. A weak SETUP is a regular SETUP, except that the output of C and C0 are polynomially indistinguishable to everyone except the attacker and the owner of the device who is in control (knowledge) of his or her own private key (i.e. the requirement 5 above is changed).

The purpose of the weak SETUP is to allow the collaborating user to infect their device to obtain securely encrypted subliminal channel. According to the definition, a non-collaborating user can discover the backdoor efficiently. Still, they must be suspicious about the backdoor being present. When the backdoor does no visible harm, it might go unnoticed despite the ability of detection. The polynomial indistinguishability of the SETUP is based on the assumption that the inquirer has only access to I/O of the device. An interesting variant of a SETUP can be derived when we allow the inquirer to access the internals. Definition. A strong SETUP is a regular SETUP but in addition we assume that the users are able to hold and fully reverse engineer the device after its past usage and before its future usage. They are able to analyse the actual implementation of C0 and deploy the device. However, the users still cannot steal previously generated or future generated keys, and if the SETUP is not always applied to future keys, then SETUP-free keys remain polynomially indistinguishable.

The strong SETUP implies that a kleptogram and an uninfected public value must share the same probability distribution of the values. It is stressed that all concepts in kleptography were developed with respect to theoretical security. In practical settings, it is also reasonable to consider computational security. The only practical advantage of a strong SETUP appears when the user must continue using the infected device despite the detected backdoor. In that case the user cannot be sure which outputs are backdoored and which not. On the contrary, the user is able to eﬃciently distinguish backdoored and clean invocations of

12 3. Kleptography Overview

the protocol infected with a regular SETUP. When the backdoor is not applied to all keys, this enables safe use of the device (after the presence of a SETUP is discovered). It suﬃces to run the protocol multiple times until the clean key is detected.

3.3 SETUP examples

3.3.1 SETUP in RSA

The thesis continues with the analysis of RSA key generation SETUP [1] to illustrate the concept of asymmetric backdoors. The backdoor allows for eﬃcient factorization of RSA modulus by an attacker. Recall how Alice generates a textbook RSA key pair: 1. Alice ﬁrst picks two distinct primes p, q, computes the product pq = n and the Euler’s function ϕ(n) = (p − 1)(q − 1). 2. Next, she picks public exponent e, such that gcd(e, ϕ(n)) = 1, i.e. e has inversion modulo ϕ(n). 3. Finally, she computes private exponent d = e−1 (mod ϕ(n)). 4. Alice can then publish (n, e) as her public key and keep (n, d) as the private key. When Alice is said to perform some cryptographic computation, it is actually her black-box device that computes. Naturally, an attacker does not subvert Alice but her device. Accordingly, the thesis next presents the subverted key generation algorithm that is embedded on the Alice’s device. It utilises RSA key pair of evil Eve. Denote her public key (N,E) and store it on the infected device. The infected key generation works as follows. 1. The device selects two distinct primes p, q, computes the product pq = n and Euler’s function ϕ(n) = (p − 1)(q − 1). 2. The public exponent is derived as e = pE (mod N). If e is not invertible modulo ϕ(n), new p is generated. 3. Private exponent is computed as d = e−1 (mod ϕ(n)).

13 3. Kleptography Overview

4. Public key is (n, e), private key is (n, d). After obtaining the kleptogram e contained in public key (n, e), Eve can use her private key (N,D) to compute

eD = pED = p (mod N).

In total, Eve can factorize the modulus n, and compute the private exponent d just by eavesdropping the public key. Consequently, Eve can break the system. Notice that we have not specified how e is selected in the non-infected version of the protocol. In practice, e is fixed to some constant (of relatively low value) and repeatedly used in different invocations. As the subverted e changes and is uniformly distributed in the group, this property leaves the backdoor unsuitable for real use. In exact, the condition of polynomial indistinguishability of the SETUP is violated. For the consequent analysis of the backdoor, assume that e is selected randomly in the RSA protocol. First, notice how the backdoor exploits randomness in the protocol. It subverts the random choice of e to hide the value of prime p inside it. Accordingly, as the exfiltrated information is encrypted, the resulting kleptogram appears random to the user. There are two main approaches of utilising a kleptogram. The designer can either generate the private key and hide some information allowing for recovery of the key into the kleptogram (typically, the kleptogram is a ciphertext of the private key); or, the designer could hide a seed into the kleptogram. Based on the seed, the private key can be computed in the infected device so that the attacker can replicate the process remotely. The RSA example uses the former approach. Let us discuss the SETUP conditions of the RSA backdoor. It can be easily spotted that the conditions 1-4 hold. Moreover, since p and q are chosen randomly and are changing between invocations, one cannot differentiate, if e was selected randomly or is a product of exponentiation pE. Therefore, on the assumption that e is generated randomly in the uninfected system, the RSA backdoor is a SETUP. Further, as the user cannot say which p should be used, the backdoor is a strong SETUP. Moreover, the backdoor exhibits ideal leakage bandwidth

14 3. Kleptography Overview

(m, m). In exact, knowledge of the public key suffices for recovery of the corresponding private key by the attacker. To our best knowledge, no efficient cryptanalysis of the backdoor is known. One can therefore presume that the backdoor is as secure as the weaker of involved key pairs, namely the attacker’s key pair and the generated key pair. It must be emphasized that the attacker’s modulus must be of roughly same value as the generated key. If the modulus N is smaller, the public exponent e would not be uniformly distributed among the modulus n. If the generated key is larger, e could overflow the value of n, leaving the attacker uncertain of its value. This is another serious drawback in the context of practical deployment as we would like the device to be able to generate keys of various lengths. For better understanding, the thesis provides a worked-out toy example of the backdoor. Suppose that Eve’s key pair is

N = 436789,E = 5,D = 348365.

The key generation on infected system is as follows: 1. Primes p = 677, q = 599 are randomly chosen and product n = 405523 is computed. The Euler’s function is ϕ(n) = 404248. 2. The public exponent is computed as

e = pE = 262841 (mod 436789).

The reader can verify that gcd(262841, 404248) = 1. 3. The private exponent d = e−1 = 114233 (mod 404248) is computed. 4. Finally, the public key is (405523, 262841) and the private key is (405523, 114233). If Eve captures the public key, she can compute the prime p as

p = eD = 262841348365 = 677 (mod 436789).

n 405523 She can then obtain q = p = 677 = 599 and recover the private key.

15 3. Kleptography Overview 3.3.2 SETUP in ElGamal

The ElGamal key generation process for the encryption scheme works as follows.

1. The device selects the group Zp with generator g. 2. The device chooses x randomly and uniformly from {1, . . . , p−1}.

x 3. The device computes h = g . The public key is a triplet (Zp, g, h), the corresponding private key is the public key expanded with x.

The thesis does not concern the process of encryption. Instead, it is showed how the key generation process can be backdoored, so that evil Eve can derive the private key from the generator g. The modiﬁed device requires RSA public key (n, e), such that n and p are of roughly same size. Further, the backdoor needs keyed randomization function H with key K + i, where K is hard-coded value and i is incremented counter. The process of subverted key generation works in the following fashion.

1. Prime p is selected and random x ∈ {1, . . . , p − 1} is picked.

2. The device encrypts x into x0 = E(x) under the attacker’s RSA key.

3. The devices randomizes the value x0 with function H.

0 0 4. If HK+i(x ) is generator on Zp and HK+i(x ) < p − 1 holds, 0 then generator is put g = HK+i(x ). Otherwise, the counter i is incremented and point 4 repeats.

5. The corresponding value h = gx is computed.

6. The public key (Zp, g, h) is returned and the private key x is retained.

The subverted algorithm computes eﬃciently in randomized manner. Also, evil Eve can recover the private exponent x by computing

−1 D(HK+i(g)),

16 3. Kleptography Overview where D() denotes RSA decryption and i is the guessed oﬀset of the randomization function. It can be easily seen that other conditions of SETUP hold as well. For rigorous proofs, see [1].

3.3.3 SETUP in Diﬃe-Hellman protocol

Assume that Alice and Bob would like to agree on a shared secret and they choose Diﬃe-Hellman protocol to do so. The protocol works in the following fashion:

1. Alice and Bob agree on group Zp such that discrete logarithm problem is hard on the group. 2. Alice generates private exponent a and computes a public key a A = g , where g is a generator on the group Zp. Alice then sends the value A to Bob. 3. Bob generates his private exponent b and computes B = ga. He sends the public key B to Alice. 4. Both parties then compute the shared secret Ba = Ab = gab. The paper [10] shows how the underlying cryptographic device can be backdoored to leak values of private exponent, such that evil Eve can recover them by eavesdropping on the public keys. The thesis adopts drastically simpliﬁed version of the backdoor that works with one additional assumption. For that reason, the thesis formally proves the security of the backdoor w.r.t SETUP conditions. Assume that Eve supplies Y = gX to the cryptographic device of Alice, and that the device uses one-way hash function H that produces the output only in the set {0, 1, . . . , p − 1}. The additional assumption in contrast to the original backdoor is that the function H is not invertible. Upon ﬁrst execution, clean version of DH protocol is invoked; however, the private exponent c1 = a is stored in non-volatile memory. The procedure of i-th invocation of the protocol is the following: 1. Value z = Y ci−1 is computed.

2. New private key is put ci = H(z).

17 3. Kleptography Overview

3. The corresponding public key is gci . The following claims are required to prove the SETUP conditions. Claim 3.1. Value z is uniformly distributed in Zp.

x Proof. Assume that x is chosen such that g is generator g1 in Zp. Then x c1 c1 (g ) = g1 , which proves the claim. Claim 3.2. The value of z can be recovered only by Eve iﬀ the DH problem is secure.

Proof. Assume that the value of z = gxc1 can be recovered without knowledge of x, i.e., only with knowledge of gc1 and gx. It can be easily spotted that this is equal to solving DH problem. Claim 3.3. The outputs of clean DH key exchange algorithm and subverted DH key exchange algorithm are polynomially indistinguishable.

Proof. On the assumption that H is pseudorandom function, value c2 is uniformly distributed in its domain {0, 1, . . . , p − 1}. Thus, the value gc2 is uniformly distributed in Zp, which matches the case of clean DH.

Given these claims, the conditions of a weak SETUP are fulﬁlled if the values ci cannot be obtained by reverse engineering the device (since future keys can be generated from ci and Y ). Moreover, if the device does not print the values of the private exponent to the user, the resulting SETUP is strong. The leakage bandwidth of the backdoor is (m, m + 1).

3.4 Kleptography in the wild

Recall that an asymmetric backdoor is a modification of already established algorithm. Detection of such modification therefore proves its malicious nature. In contrast, when an algorithm is designed to be kleptographic initially, its malevolence cannot be decided so easily. To illustrate this aspect, the thesis briefly revisits the DUAL_EC_DRBG pseudorandom number generator invented by the NSA1. The generator

1. National Security Agency.

18 3. Kleptography Overview was standardized in NIST SP 8000-90A [15]. Later, a bit predictor with advantage 0.0011 was presented in [16]. Despite this serious flaw, the thesis concentrates on a different problem. In particular, the paper [15] shows potential kleptographic tampering. To be exact, the generator requires two constants on an elliptic curve, i.e., P,Q ∈ E(Fp), and the security of the internal state relies on the intractability of discrete logarithm problem for these constants. Consequently, if one is able to find scalar k such that P = kQ, they are able to compute the inner state of the generator efficiently based on the output. This naturally breaks the security of the generator. Despite the fact that arbitrary P,Q can be used for the generator, NIST standard forces the use of fixed constants with unknown origin. Naturally, NSA is alleged to provided the backdoored constants. The practical exploitability of backdoored constants was shown in [17]. However, one cannot prove nor disprove that the constants for the standard are backdoored except for the NSA. This aspect suggests that not many SETUPs are likely to appear in the wild, but rather delicate modifications of otherwise secure algorithms are expected, such that their sensitivity to efficient cryptanalysis can be viewed as a coincidence.

3.5 Defences

The reasoning behind the study of kleptography is not only to show potential risks, but to suggest adequate mitigations as well. Until 2015, all proposed defences were of little success. They either relied on unrealistic assumptions or had limited eﬀect. It remained unknown how to eliminate the need of trusted party in subverted settings. It was Post-Snowden cryptography and its revelations that boosted the research in this area rapidly. This resulted into new cryptographic primitives that can work securely even in a completely subverted environment. Such techniques require a lot of theory and are beyond the scope of this thesis. Yet, a list of known defences is presented to give the reader the whole picture and to suggest relevant literature. The list starts with the paper [18] that builds on the work of [19]. The article presents both a symmetric and an asymmetric encryption scheme that are proved to be semantically secure, even if all components of

19 3. Kleptography Overview the system are subject of potential tampering. The results of the paper are strong and reliably mitigate the threat of asymmetric backdoors. Sadly, their deployment is complicated as they require new encryption schemes. The work [18] further classifies earlier proposed defences into the following categories: • Black-box testing of components of the system by a trusted party, also called a watchdog, • abandoning the randomness in favour of deterministic computation, • use of trusted module that can re-randomize subverted primitives, • hashing the subverted randomness. The watchdog was formally defined in [19] and various models arise depending on how watchdog is used. A typical scenario is to split a program into multiple components where each of those must match specifications (otherwise the backdoor is inherently detected). The watchdog can then perform black-box testing on the components to detect differences between implementation and specifications. Abandoning of randomness requires changes of the underlying primitives and inevitably results into stochastic computation. Very careful analysis of modified protocols would need to be conducted in order to prove their security. The use of trusted module that can re-randomize subverted randomness trivially involves a trusted party, which is a strong assumption. On the contrary, as every known asymmetric backdoor is hidden in randomized components, such module reliably eliminates the risk. Hashing of subverted randomness takes away the need of trusted party. Sadly, this allows for backdoors to bypass this technique by various adjustments [18]. Kucner and Kutyłowski [20] proposed a simple detection mechanism that exploits common facet of asymmetric backdoors – newly introduced exponentiations. The authors examine variation coefficient of execution times of both infected and non-infected algorithms. They argue that newly introduced exponentiations inevitably change the variation

20 3. Kleptography Overview

coefficient which gives a simple detection mechanism of asymmetric backdoors. This approach is further studied in the practical part of the thesis. Often, it would be sufficient to detect the backdoor by side channel analysis. A promising method was proposed in [20], where changes in variation coefficient of execution times of the backdoored protocol are predicted, based on the execution times of the clean version. As we show later in the text, this method is not applicable to TLS backdoors. On the other hand, time channel analysis itself could reveal the backdoor, as backdoors usually introduce some computational overhead. Except for the detection by side channel analysis, no mitigations are easy to deploy. Indeed, they all require either drastic changes of the implementations or change of the underlying cryptographic primitives.

4 Kleptography in TLS

4.1 Transport Layer Security

Transport Layer Security is a cryptographic protocol that allows secure communication over a network. It provides confidentiality and integrity of data. Additionally, it can authenticate the communicating peers. The protocol is based on its predecessor SSL and is implemented in many libraries, for instance, OpenSSL or BoringSSL, and widely used on the internet. TLS protocol, in fact, forms a basis for the Hypertext Transfer Protocol Secure (HTTPS). The TLS is designed to be generic so that it can encapsulate any traffic on the application layer. The purpose of this chapter is to provide insight into the parts of TLS protocol relevant for kleptography. In addition, two proposals of an asymmetric backdoor for the TLS protocol are presented and critically compared. The thesis does not give a thorough description of the TLS protocol. In this matter, we refer the reader to [21] which studies the TLS extensively in the context of information security. For the sake of replicability of our results, the thesis works with TLS of version 1.2, defined in [22]. As of 2018, the TLS 1.3 is available as a draft. To our best knowledge, all kleptographic results can be easily modified or even directly employed to different versions of the protocol. Further, the TLS protocol can be enhanced with various extensions. Those are implemented voluntarily by the TLS libraries. Such extensions can introduce new key exchange protocols, ciphers, and so forth. The thesis concentrates on the vanilla implementation of TLS, but comments on widely used extensions when appropriate.

4.1.1 TLS Handshake

The TLS protocol involves two communicating parties, a server and a client. These parties perform so-called handshake at the beginning of their session. The handshake can be considered as a separate protocol above TLS. It consists of several structured messages exchanged in exact order between the server and the client. The initial goal of

23 4. Kleptography in TLS the handshake is to agree on a cipher suite which further defines the behaviour of the parties during the handshake. The cipher suite specifies the authenticated parties, means of authentication, encryption method for the session, cryptographic function that ensures integrity of the data, and key exchange method. Using the key exchange method, both parties compute so-called master secret. Out of the master secret, all cryptographic material for the session is derived. A cipher suite is represented by library specific code name, for example, consider ECDHE-RSA-AES256-SHA384.

This code name originates from the OpenSSL library and formulates that: • ephemeral DH key exchange over elliptic curves (ECDHE) is used as key exchange method, • the authentication is achieved with RSA certificates, • AES-256 is used for data encryption, • SHA-384 is used for MAC construction that protects message integrity. Further goal of the handshake is to authenticate involved peers. Usu- ally, only the server is authenticated, typically with RSA certificate. Nonetheless, the handshake can also achieve mutual authentication or authentication of neither of peers. The latter is called anonymous session and is inherently insecure, as such session is vulnerable to man-in-the- middle attack. The thesis continues with presenting the handshake protocol in a simplified form. The messages exchanged during the handshake are: 1. Client sends ClientHello message to server, containing the highest supported version of TLS, 28-byte random nonce and list of supported cipher suites. 2. Server responds with ServerHello message, containing chosen protocol version, 28-byte random nonce and selected cipher suite. 3. Server may further send its certificate (if selected cipher suite prescribes server authentication) to prove its identity.

24 4. Kleptography in TLS

4. Depending on the cipher suite, server may send ServerKeyEx- change that contains material for pre-master secret derivation. 5. Server then sends ServerHelloDone message to indicate that all necessary messages were already sent. 6. Client responds with ClientKeyExchange that contains material for the pre-master secret derivation. 7. Both sides exchange ChangeCipherSpec messages, meaning that subsequent messages are encrypted, authenticated (based on cipher suite), and their integrity is protected. They also exchange finished message that contains HMAC of all previous handshake messages. The other side replicates the computation of HMAC and verifies the match. If there is a mismatch, handshake is considered as failed. The basic form of the handshake is depicted in figure 4.1.1.

4.1.2 Master secret derivation

The aim of the key exchange algorithm is to derive a pre-master secret available only to the communicating parties. Out of the pre-master secret, each side independently computes the master secret according to the formula master secret = PRF(PMS, label, clientHello || serverHello), where PRF stands for key derivation function1, PMS denotes pre-master secret, label is constant string "master secret" and || denotes concate- nation. Based on the master secret, symmetric session keys are derived. The TLS speciﬁes two main methods of key exchange algorithm – RSA and DH. The RSA method prescribes that the server must be authenticated. That is because only the client contributes to the pre-master secret computation. Hence, client’s input must be sent encrypted to the server. This is possible only by means of asymmetric cryptography (since

1. The TLS 1.2 uses cipher suite speciﬁc key derivation function. Yet, all common cipher suites use HMAC based P_SHA256 function deﬁned in [22], section 5.

25 4. Kleptography in TLS

Client Server

ClientHello (containing random nonce)

ServerHello (nonce, cipher suite)

ServerCertiﬁcate

ServerKeyExchange (optional)

ServerHelloDone

ClientKeyExchange

ChangeCipherSpec, ClientFinished

ChangeCipherSpec, ServerFinished

Figure 4.1: TLS handshake

26 4. Kleptography in TLS

peers have no pre-shared keys), and therefore public-key certiﬁcate is required. When the RSA method is used, the client generates 46 random bytes, encrypts them with server’s public key and sends them inside the ClientKeyExchange message. Those bytes then form the pre-master secret.

In the DH method, the pre-master secret is a result of the Diffie-Hellman key exchange between the server and the client. This method can be used when anonymous session is being established. In practice, anonymous key exchange is rarely used. TLS offers another exotic variant of DH method. In particular, static DH parameters can be used to negotiate the secret. Static parameters can be used only when both the server and the client possess DH certificates with compatible parameters. To our best knowledge, this concept is rather theoretical and is not used in practice. Instead, the ephemeral key exchange is used, often over elliptic curves.

Both RSA and DH key exchange methods assure that the pre-master secret is available only to the communicating peers. Recall that the computation of the master secret is deterministic on three inputs: pre- master secret, ClientHello nonce, and ServerHello nonce. However, both nonces are sent in plaintext during the handshake. Given the above, for the passive eavesdropper, compromising the conﬁdentiality of the whole session reduces to the pre-master secret computation. As a result, asymmetric backdoors aim to allow for computation of pre-master secret to the designer. Recall that TLS is asymmetrical protocol, since it involves a server and a client. The work in kleptography for TLS concerns only the client devices. Still, when DH key exchange method is used — and its usage can be forced by the server — it is trivial to modify existing backdoors such that they apply to servers.

4.2 Proposed asymmetric backdoors for TLS

This section is devoted to two asymmetric backdoors for the TLS protocol.

27 4. Kleptography in TLS 4.2.1 SETUP by Gołębiewski et al.

The paper [2] by Gołębiewski et al. introduces kleptographic attacks on TLS and SSH protocols, as well as it offers changes in the protocols that makes them immune to those specific attacks. From the perspective of an attacker, the proposed backdoor has several drawbacks. First, it is not described in sufficient detail and some design choices are left open. Further, it does not fulfil the properties of the SETUP, as noticed by Yung and Young in [23]. Proofs of security are also omitted. Still, the backdoor is a solid step and as shown later in the text, the shortcomings can be fixed. The thesis implements an improved version of this backdoor and proves its security in Chapter 5. Recall that any kleptogram is likely to be either a random bit string or a random element on some group. As a result, ClientHello nonce is the only suitable channel for kleptograms in the TLS protocol. The resulting subliminal channel is therefore narrowband, allowing to transmit only 28- bytes per handshake. To achieve (m, m+1) or (m, m) leakage bandwidth, the backdoor must utilise these 28 bytes to derive the pre-master secret. We emphasize that the size of the kleptogram also puts upper bound on the security of the backdoor. Indeed, the master secret can be derived only from those 28 bytes. The backdoor employs group G for which discrete logarithm problem is hard. While any such group could be used, elliptic curves are suggested due to their compact representation of elements. On group G, the designer generates a private key X and a public key Y = gX , where g is a generator on the group. The public key Y is then hard-coded into the infected device. Two parts of the TLS handshake algorithm are modified, namely the ClientHello nonce value and pre-master secret derivation. To limit the exposure of backdoor, the ClientHello nonce is infected only in the first execution of the handshake. In subsequent executions, non-infected derivation of the nonce is used. Recall that TLS chooses 28 random bytes to fill the ClientHello random nonce. In contrast, the backdoored execution generates a random scalar k, and publishes C = gk as the ClientHello nonce. If the representation of C on group G is larger than 28 bytes, parts of C are leaked in the nonce over multiple handshakes.

28 4. Kleptography in TLS

Further, consider that Y k = gkX = CX . The authors therefore manage to utilise C for derivation of shared secret between the infected device and the designer. The reader may notice that this computation is in fact equivalent to the Diffie-Hellman key exchange. Consequently, the infected device can employ Y k as value available exclusively to the holder of the private key X. It remains to explain how to utilise Y k to derive the pre-master secret. One must assure two things. First, the pre-master secrets must differ over different sessions, otherwise, the backdoor could be easily detected. Second, entropy must be appropriately extracted from Y k. Since the article works in random oracle model, both is achieved by putting

S = H(Y k, i), where H is cryptographically strong hash function and i is a small sequential counter that is incremented on each invocation. Value S can be then used to derive the pre-master secret on the infected device. When the RSA key exchange method is used, one can simply choose S instead of 46 random bytes. When Diﬃe-Hellman is used, the backdoor generates the private key for the device from the seed S. Thus, the attacker can replicate the computation in both cases. Let us discuss the formal properties of the backdoor w.r.t. SETUP. It can be easily seen that the properties 1-4 of SETUP hold for this case. The property 6 does not hold, since either Y k or k must be stored in non-volatile memory on the device, therefore exposed to the reverse engineer. Finally, Yung and Young noticed in [3] that the value C is easily distinguishable from non-infected ClientHello nonce. Recall that this nonce should be uniformly distributed random bit string, but C is actually an element from G. Assume that G is deﬁned over elliptic curves, then paper [24] mentions three ways how to distinguish point on a curve from random bit string. One could argue that employing injective mappings from elliptic curves to bit strings that are indistinguishable from uniformly distributed bit strings will solve the issue. Example of such encodings are Elligator, Elli- gator2 presented in [24] or Elligator squared presented in [25]. However,

29 4. Kleptography in TLS these mappings are not keyed and are invertible. Therefore, the inquirer could perform inversion of the mapping and use the aforementioned distinguishers anyway. What we suggest for future work is to somehow embed secret key into these functions. Assuming that the key would be hard-coded on the device, the indistinguishability could be achieved by algebraic techniques. Since a pre-master secret is always generated from the same nonce, the infected device must only transmit single nonce C to the eavesdropper, allowing him to deny the conﬁdentiality of all subsequent sessions. Nevertheless, this favourable property introduces major drawbacks. First, the attacker must be able to eavesdrop the handshake where C was being transmitted. Second, if the attacker fails to eavesdrop some subsequent sessions, they must brute force the value of counter i to ﬁnd the right place in a sequence H(Y k, 0),H(Y k, 1),....

Third, when the third party recovers the value of S, that party can decrypt all previous and future sessions (assuming they can brute force the value of counter i). Thus, the system does not provide forward secrecy w.r.t. S. Gołębiewski et al. also proposed defence against this backdoor, and most probably against any SETUP for the TLS. However, changes in the handshake protocol must be made to employ the defence. The authors suggest to limit the key exchange algorithm to the RSA case and set the ClientHello nonce to be the hash of the pre-master secret. Note that this falls into the ‘Abandon randomness in favour of deterministic computation’ defence category.

4.2.2 SETUP by Yung and Young

The previous subsection revealed that there is not much freedom when designing an asymmetric backdoor for TLS. That is because the only available channel for the kleptogram is the ClientHello nonce. Thus, the nonce must be tampered to give the attacker possibility to compute a seed, out of which the pre-master secret is computed. Ultimately, the designer can only choose how to utilise the available 28 bytes such that

30 4. Kleptography in TLS

they result in the secret accessible only to the designer. This can be done either by a shared key exchange (between the device and the designer) or by a message that gets asymmetrically encrypted on the device. Recall that the resulting kleptogram must be indistinguishable from random bit string. The latter case is the subject of study in a ﬁeld of public-key steganography. Tools with such properties are studied in [26] and are closely related to kleptography. Sadly, encryption schemes presented in the mentioned paper require at least 64-byte channel (if implemented over elliptic curves), therefore enabling only (m/2, m) leakage bandwidth over TLS.

In [23], Yung and Young briefly analysed backdoor from [2] and proposed a novel scheme for space-efficient pseudorandom key exchange. In their scheme, the length of the kleptogram is a security parameter. Serious drawback of the scheme is that the key exchange succeeds only with probability very close to 1/2. The backdoor can be chained in the TLS settings, such that after first successful exchange, all subsequent sessions will be compromised. The trade-off is that the key material must be kept in non-volatile memory on the infected device and therefore exposed to potential reverse engineering. The authors have further improved the concept in the paper [3] and removed these drawbacks. The new version succeeds with overwhelming probability, but remains probabilistic in nature. Their fix improved theoretical properties, but introduced major problem for practical implementations. The goal of the algorithm is to derive uniformly distributed shared secret of length M. They manage to achieve the goal, but one DH key pair is needed to derive single bit. Recall that the RSA key exchange method uses 46 bytes as pre- master secret. Thus, 368 key pairs over elliptic curves are needed to derive the shared secret. Since the computations on those keys must be done on the device, such backdoor would be trivially distinguishable with timing analysis. Further, the DH key exchange method requires even longer secret. Without entropy extraction via hashing, it remains unclear how to solve this issue. To conclude, this concept is unsuitable for real deployment. Still, the thesis aims to give an overview necessary to understand how one can use their results to design the backdoor. The explanation is simplified to achieve a high-level view. For full explanation, the reader can see [3, 23, 27]. We would like to emphasize that the results are the state of the art in the field of kleptography. Theoretically, they

31 4. Kleptography in TLS are very strong because they are proven from standard assumptions, not relying on idealized hash functions and so forth. Further, the tool can be used to backdoor other cryptosystems, including RSA.

Denote k + 1 the available bandwidth of the subliminal channel in bits and denote an arbitrary prime of bit length k by p. From p, construct 2 3 an elliptic curve y = x + ax + b over finite field Fp. Denote the elliptic curve Ea,b(Fp) and consider the following Lemma 4.1. Let β 6= 0 be a quadratic non-residue in the field Fp and√ let Ea,b(Fp) be an elliptic curve. Then for every value of x, letting y = x3 + ax + b:

1. If y is a quadratic residue, then the points (x, ±y) are on the curve Ea,b(Fp).

2. If y is a quadratic non-residue, then the points (βx, ±pβ3y) are on the curve Eaβ2,bβ3 (Fp).

3. If y = 0, then the point (x, 0) is on the curve Ea,b(Fp) and the point (βx, 0) is on the curve Eaβ2,bβ3 (Fp).

This lemma implies that both curves together contain 2p+2 points (since identity element is on both curves). The curves Ea,b(Fp) and Eaβ2,bβ3 (Fp) are called a twisted pair and denoted Ta,b,β(Fp). The key observation of Yung and Young is that one can create probabilistic eﬃcient invertible mapping between the set of points on Ta,b,β(Fp) and all (k+1)-bit strings corresponding to the integers in the set {0,..., 2p + 1} padded with leading zeros as necessary.

Therefore, a point on the elliptic curve can be encoded to a random bit string of ﬁxed length. Moreover, performing inverse mapping on the random bit string always yields point on the twisted pair (except for bit strings representing integers larger than 2p + 1) and hence one cannot say, whether the kleptogram carries point on a curve or not. This guarantees that such kleptogram is polynomially indistinguishable from a random bit string. It remains to solve, how to utilise the twisted pair of curves for shared key exchange. The description that follows is put directly into the TLS context. However, it could be generalized to general key exchange between Alice and Bob.

32 4. Kleptography in TLS

Denote r = #Ea,b(Fp) the number of points on curve Ea,b(Fp) and 0 denote r = #Eaβ2,bβ3 (Fp) the number of points on the twist. To sample elliptic curves secure w.r.t. ECDDH problem,√ the authors suggest that p is of form p = 2k − δ, where 1 ≤ δ < 2k. Further, both curves should be of prime order and recall that r + r0 = 2p + 2. The designer of the backdoor generates M key pairs on the curve Ea,b(Fp) with generator g1 and M public keys on Eaβ2,bβ3 (Fp) with generator g2. Then, the designer stores them on the infected device. Denote the generated key pairs

X1 X2 XM XM+1 X2M Y1 = g1 ,Y2 = g1 ,...,YM = g1 ,YM+1 = g2 ,...,Y2M = g2 .

Once the device shall compute ClientHello nonce, it ﬁrst randomly selects one of the curves on the twist. The selection is not uniform, but proportional to the number of points on the curve, so the lager curve is selected more often. For further illustration, suppose that curve Ea,b(Fp) is selected. The device then generates its private scalar k and computes k the public key mA = g1 . The public key mA is then encoded to random the bit string and published inside the ClientHello nonce. Next, the device computes M shared secrets using the scalar k and hard-coded public keys of the designer, i.e.

k k k S1 = Y1 ,S2 = Y2 ,...,SM = YM .

These secrets are again encoded into bit strings and least signiﬁcant bits of each secret are concatenated. Those bits then form the shared secret

mk = lsb(encode(S1)) || lsb(encode(S2)) || ... || lsb(encode(SM )).

Natural question arises, why to use least signiﬁcant bits of the shared secrets Si, when each one of the secrets Si is uniformly distributed and could be used as it is? That is because the secret Si is on the same curve as the value mA. This would give the potential attacker huge advantage, as to obtain the secret mk, they do need to brute force only the encodings of points on the corresponding curve. This advantage is eliminated by the aforementioned technique of least signiﬁcant bits.

33 4. Kleptography in TLS 4.2.3 Comparison of proposed solutions

The construction from Gołębiewski et al. is simple to implement, applicable to both key exchange methods and performs fast. Further, it can utilise arbitrary elliptic curve, including known curves with eﬃcient implementations. On the other hand, the backdoor is distinguishable, not secure against reverse engineering and lacks forward secrecy. It also requires that the eavesdropper successfully captures initial handshakes. Further, the backdoor relies on the security of current hash functions. The backdoor by Yung and Young is proved to be a strong SETUP, but is probabilistic in nature. Further, the construction is rather complicated and introduces big computational overhead compared to backdoor by Gołębiewski et al.

34 5 Proposal of SETUP for TLS

This chapter aims to present both design and implementation of a novel asymmetric backdoor for TLS. The backdoor is based on [2]. However, several drawbacks are eliminated by our construction, and properties of the backdoor are treated more rigorously. The chapter begins with presenting a design of the backdoor. Next, the process of implementation into the OpenSSL library is presented. The reasoning behind choosing OpenSSL is twofold. First, a subset of OpenSSL API is FIPS 140-2 validated to level 1, which leaves it open for use in the black-box settings. Second, the thesis reveals whether the backdoor can pose as a regular malware, without the requirements on the black-box environment. When one designs malware in black-box settings, they are allowed to change both implementation and header ﬁles of the infected library. On the contrary, only the compiled binaries are infected in case of regular malware. The OpenSSL does not expose many low-level functions from a cryptographic library to high-level functions that are used in the TLS handshake. The thesis shows that our proposal can be embedded only into the compiled binary, leaving the header ﬁles untouched.

5.1 SETUP design

5.1.1 Desired improvements

The needed improvements w.r.t. the proposal by Gołębiewski et al. were:

• To achieve indistinguishability of kleptogram from a random bit string,

• to ensure forward secrecy of the secret shared between designer and device,

• to allow recovery of the master key to the attacker even if they miss to eavesdrop any of sessions.

35 5. Proposal of SETUP for TLS

An additional goal was to minimize the computational overhead introduced by the backdoor, to avoid possible detection by timing analysis. The indistinguishability of the kleptogram from a random bit string is achieved in a computational sense. Recall that the property must hold only until the backdoor is reverse engineered (for a regular SETUP). Hence, the designer can hard-code symmetric key into the device and use the key to encrypt the published value. The underlying cipher is not used to achieve confidentiality, but to make the message indistinguishable from a random bit string. The paper [28] proves that the counter mode (CTR) is polynomially indistinguishable from a random bit string on the assumption that the underlying cipher is a pseudorandom function (PRF). This holds when the value of counter never repeats, i.e., the counter is nonce. We have selected the AES in CTR mode with a key of length 128 bits to achieve indistinguishability. Some properties of this selection must be further discussed. First, NIST recommends [29] to limit the number of calls of pseudorandom number generator (PRNG) keyed with hard-coded value to 248 blocks. Since AES-CTR is essen- tially PRNG, this recommendation should be respected. Consider that birthday collisions are likely to appear only after 264 bits of output, so they are trivially treated by the NIST recommendation. Since the backdoor uses two blocks of AES-CTR for one handshake, this limits the functioning of the backdoor to 247 handshakes. It is emphasized that once the backdoor is reverse engineered and the symmetric key is obtained, the indistinguishability is broken. To ensure (m, m) leakage bandwidth, compact kleptograms must be exploited. Since the content of the kleptogram is DH public key (encrypted with AES), an elliptic curve can be used as the underlying group. In this research, X25519 curve [30] is employed for several reasons: the compressed points are represented by 32 bytes, the curve provides 128 bits of security, and the curve performs very fast. Our key observation is that OpenSSL often uses 32 byte ClientHello nonces, instead of 28 bytes. The OpenSSL code contains branching between those two options. Yet, in practice, we were not able to force the OpenSSL to use only 28 bytes. As a result, the whole key on the curve (encrypted with AES) fits into single nonce. If 28-byte nonce is to be used, our implementation leaks only first 28 bytes. The 4 bytes can be simply brute-forced by the

36 5. Proposal of SETUP for TLS

attacker. As the kleptogram is of length 32 bytes, no padding is needed when encrypting it with AES. Further, it is stressed that TLS 1.3 [31] uses 32-byte nonce, making it easier for the attacker. To allow recovery of the master key when certain handshakes are over- heard, our proposal does not derive static seed that is used across sessions, but instead it generates ephemeral seeds on each invocation. This approach also guarantees perfect forward secrecy w.r.t. seed S. On the other hand, our backdoor needs to maintain the state of the counter for AES across sessions. We argue that even if the attacker misses some sessions, they can brute-force the value of the counter rather easily.

5.1.2 Backdoor description

In the following paragraph, assume that the nonce has 32 bytes which matches our practical experience. The design of the backdoor is as follows. Prior to deployment, the designer generates DH key pair on the X25519 curve, denoted Y = gX . The public key Y is then hard-coded into the device, together with the 128-bit key for AES, denoted K and the counter. The initial value of the counter is 1 and is incremented by 2 after each execution. Suppose that the infected device connects to the server and the handshake is initiated. When construction of the ClientHello message is triggered, the infected device generates 32 random bytes denoted k and computes the public key gk. The curve X25519 prescribes that 5 specific bits of k are set to a constant value. Thus, the effective length of k is only 251 bits. The value gk is then encrypted with k AES-CTR into C = EK (g ) and published as a kleptogram. Meanwhile, value S = Y k is derived on the device as a shared secret between the attacker and the device. When the pre-master secret is to be derived, we differentiate two cases: 1. If the RSA method is used, the value S is stretched to 46 bytes by TLS 1.2. PRF function and sent as pre-master secret. 2. If the DH method is used, the server first sends the DH parameters to the client, including the prime p. The value S is then stretched by TLS 1.2. PRF to the string of same bit length as prime p. This bit string is checked to fulfil the requirements for DH private key

37 5. Proposal of SETUP for TLS

Algorithm 1: Generate kleptogram and seed Input: A public key Y , AES-CTR key K with counter Output: The kleptogram C and seed S k ← 32 random bytes k C ← EK (g ) S ← Y k delete value k securely return (C,S)

(not being 0, 1 or ≥ p) and is used as the client’s private key. If the requirements are not met, the output of PRF is repeatedly used as an input to PRF until proper key is generated.

Once the pre-master secret is generated, the handshake continues ordi- narily.

The description above holds for an ephemeral key exchange over elliptic curves or modular integers. Recall that static DH key exchange may be used in TLS as well. In such case, the shared secret is determined solely by the contents of the corresponding certiﬁcates and cannot be tampered in any way. However, the private key could be encrypted by ElGamal cipher and exﬁltrated inside the ClientHello nonce over several sessions. The eavesdropper would detect this state since they would obtain corrupted pre-master secrets. Our proof of concept does not implement this feature.

The backdoor is be described by Algorithm 1 and Algorithm 2. The Algorithm 1 generates the ClientHello random nonce and the seed S. The latter is further processed by the Algorithm 2 to derive the pre-master secret.

5.1.3 Properties of SETUP proposal

Clearly, properties 1-3 of a regular SETUP hold for our backdoor. To prove property 4, we show how the attacker can obtain the seed S by eavesdropping on the handshake traﬃc. The reader can easily verify

38 5. Proposal of SETUP for TLS

Algorithm 2: Generate pre-master secret Input: Key exchange method, DH parameters and public key of server if needed, seed S Output: Pre-master secret PMS if key exchange method is RSA then PMS ← PRF(S, 46 bytes) else l ← length of DH prime in bits Z ← DH public key of server x ← S do x ← PRF(x, l bits) while x = 0 or x = 1 or x ≥ p PMS ← Zx end return PMS

that once the seed S is known, anyone can replicate the computation of the device that leads to the pre-master secret.

When the attacker obtains the ClientHello nonce, they can decrypt it with the AES key K, obtaining the public key of the device gk. The attacker can further utilise their private key X to compute the shared x value S = gk = Y k. Consider that when the DH key exchange method is used, the attacker must also eavesdrop the public key of the server and the parameters of the exchange. Those are sent in plaintext. To conclude, property 4 holds as well.

The property 5 holds on the assumption that AES is a pseudorandom function. Indeed, in such case, AES-CTR produces ciphertext indistinguishable from uniformly distributed bit string. Naturally, AES is not pseudorandom function. Still, the sense of computational security seems suﬃcient. Strictly speaking, our proposal can never be considered as a SETUP, since property 5 is not provable. One can argue that the backdoored Diﬃe-Hellman keys have to be uniformly distributed on the underlying group as well. Yet, when the private key is not shown to the user, this is not a concern. Nevertheless, the keys are generated

39 5. Proposal of SETUP for TLS from TLS 1.2 PRF. Hence they shall appear perfectly random to the inquirer.

Recall that non-volatile memory of the infected device contains AES key K with the counter and the public key Y . Only the key Y is relevant to the conﬁdentiality of the shared secret S. Notice that obtaining shared x secret gk from gk and gx is equivalent to solving ECDH problem. We therefore conclude that the property 6 holds. We stress that the backdoor uses a single nonce for two purposes, which is generally considered a bad practice. Indeed, the ClientHello nonce is used as an input for the master secret derivation and moreover, the pre-master secret is determined by the nonce. We conjecture that this property cannot be eliminated.

To summarize, properties 1,2,3,4,6 hold unconditionally for our proposal. The property 5 holds in a computational sense. Recall that Yung and Young utilised complicated construction to achieve polynomial indistinguishability of the kleptogram. Without inventing new methods, there is a trade-oﬀ between the provable indistinguishability and the performance of the backdoor. In terms of practical detection, the speed of the construction seems more pressing than provable indistinguishability. We speculate that the backdoor of Yung and Young could be easily spotted via timing channel.

5.1.4 Additional key exchange methods

The OpenSSL supports several additional key exchange methods described in various TLS extensions; However, they are rarely used in practice. The thesis does not implement the backdoor for these methods, but comments on how the current approach could be elaborated to compromise those methods. This subsection is not intended to be self- explanatory in the means of the key exchange methods. The reader is always referred to the corresponding RFC where a thorough explanation of the method is given.

40 5. Proposal of SETUP for TLS Kerberos

This key exchange method is defined in [32]. The method is very similar to the RSA key exchange method. The difference is that the pre-master secret (46 bytes selected by the client) is encrypted with Kerberos session key instead of RSA certificate. Consequently, an attacker can compromise this method with the same technique that is applied to the RSA method.

Secure remote password protocol

TLS can utilise secure remote password protocol of version 6 (SRP) [33]. The protocol ampliﬁes the security of shared passwords by combining them with ephemeral DH keys. In this way, strong security can be obtained from short passwords, as brute-forcing the password requires brute-forcing the corresponding DH key space. The asymmetric backdoor could be easily used to generate private DH key known to the attacker similarly to regular DH key exchange. Therefore, an attacker with knowledge of the shared secret would be left to brute-force only the static password. This severely hurts the protocol. Still, brute-forcing the password may not be feasible for the attacker. In that case, asymmetrically encrypted ciphertext could be used to exﬁltrate the captured password from the device over multiple handshakes inside the ClientHello nonce as an ElGamal ciphertext.

Pre-shared symmetric keys

This key exchange method [34] is similar to SRP, but it uses symmetric keys instead of passwords. The pre-shared key can be further enhanced with either RSA or ephemeral DH secret. Those are generated the same way as the secrets in vanilla TLS. Knowledge of the RSA/DH secret allows for so-called offline brute-force attack (not requiring the responses from server). Our backdoor can hence hurt the protocol to allow for an offline attack. Once again, if the pre-shared key can be accessed by the device, it can be exfiltrated by the attacker using the subliminal channel in the ClientHello nonce.

41 5. Proposal of SETUP for TLS 5.2 Implementation

We have modified the OpenSSL library of version 1.1.1-pre2. The pre- release version was chosen because it provides certain functions for computations on the X25519 curve not available in previous releases. The X25519 is implemented in a different way than other elliptic curves in OpenSSL and older releases did not allow for the creation of specific keys on this curve; only random keys could be created. We have decided to expose the low-level functions for direct use, in order to achieve simpler implementation. This resulted into modification of the header files. Nevertheless, high-level interfaces could be used instead and the backdoor could be deployed as a compiled library. We state that we have faced no serious obstacles that would prevent the backdoor installation to the library. Besides the infected library, we have further created a recovery tool that emulates a passive eavesdropper with knowledge of the private key. The tool requires ClientHello nonce, ServerHello nonce, attacker’s private key, attacker’s AES key and counter, and possibly DH parameters. The output of the tool is the master secret for the session. Both tools are implemented as a proof of concept. Accordingly, certain choices were decided for the sake of clarity rather than security. The infected OpenSSL library also contains modified s_client application that serves as TLS connection debugger and emulates client. The appendices contain both recovery tool and the infected library, as well as a tutorial on how to use those.

42 6 Heuristic Backdoor Detection

The purpose of this chapter is to discuss possible ways for detection of the asymmetric backdoor from the previous chapter. The proposed techniques are however heuristic in their nature since there are no established methods of detection applicable to all backdoors. Nevertheless, our malware exhibits several features that could be detected as anomalies. For instance, one could examine the randomness of the ClientHello nonce. Also, newly introduced exponentiations to the TLS protocol could be detected either via timing channel or power analysis, depending on the inspected device. The thesis concentrates on the former case, since all experiments were conducted in a desktop environment, where power analysis is impractical.

6.1 Tests of randomness

The published kleptogram should appear perfectly random to the user, since it is encrypted with AES in counter mode. To our best knowledge, no distinguisher exists for AES-CTR as of 2018. To conﬁrm the conjecture that kleptograms appear random, we have evaluated the statistical properties of the AES-CTR keystream with two batteries for validation of random number generators. Recall that the keystream is added to the plaintext by XOR operation. Therefore, it suﬃces to examine the properties of the keystream, as they propagate to the resulting ciphertext. To assess the properties of the keystream, NIST [29] and Dieharder [35] batteries were used. In both cases, AES-CTR was turned into PRNG with constant key and incremented counter initially set to 0.

NIST battery of version 2.1.2 was run on 109 bytes with settings rec- ommended by the document [36]. In particular, 1000 sequences were tested, each of length 106 bytes. The null hypothesis of the tests can be stated as ‘The data appear uniformly distributed’, and was tested on signiﬁcance level α = 0.01. All tests were performed with default parameters, and neither of them failed. As a result, the null hypothesis cannot be rejected, and the kleptograms can be considered random.

43 6. Heuristic Backdoor Detection

Given that some of Dieharder tests require more than 1 GB of data, the AES input was fed dynamically to the suite using Linux pipe. That allowed to avoid rewinding of the data. All tests were performed with default settings on Dieharder of version 3.31.1. The suite was run multiple times and always returned 2 or 3 WEAK results out of 114 tests. Yet, the authors of Dieharder claim that 1 test out of 100 is expected to return the WEAK result. Further, the results marked as WEAK always diﬀered. To conclude, neither NIST or Dieharder are reliable distinguishers for the AES-CTR keystream. Consequently, the published kleptograms appear random to the inquirer. They are therefore indistinguishable from clean ClientHello nonces, as those appear random as well (they were tested with the same methodology). The complete results for both batteries are included in Appendix A.

6.2 Timing experiments

Several code snippets of both infected and clean version of OpenSSL were isolated and their performance was evaluated and compared. This creates possible detection mechanism of the backdoor, yet, with certain limitations. As expected, the backdoor performs slower than the clean version. Nevertheless, this does not necessarily create a distinguisher. Suppose that all devices of a certain kind are infected. Then there exists no reference to how the uninfected version should perform. The inquirer must therefore somehow guess the expected performance and measure deviations based on this estimate. Also, the library could be used on various hardware and outperform clean versions when running on faster hardware. This constraint could be solved by measuring features that are independent of the unit of measurement. Such feature is for instance the variation coeﬃcient σ C = X µ of random variable X, where σ is a mean of the variable and µ is a standard deviation. The paper [20] studies detection of asymmetric backdoors with measuring changes in variation coeﬃcient of the execution times. The authors assume that the distribution of the execution times of many cryptographic protocols is mostly determined by the execution times of the involved exponentiations. This matches our observation

44 6. Heuristic Backdoor Detection

on the backdoored algorithm. Consequently, the authors claim that the evolution of variation coefficient can be predicted when new exponentiations are introduced to the corresponding algorithm. They claim that the technique requires that the number of exponentiations differs between the clean and the infected version of the protocol. However, their constraint is imprecise. To successfully conduct their detection mechanism, the clean version of the protocol must contain at least one exponentiation. This is not the case of TLS, where the ClientHello nonce is generated as an output of PRNG with no exponentiations involved. Still, we have experimented with this technique and successfully predicted the evolution of variation coefficient for X25519 exponentiations; despite the implementation of X25519 in OpenSSL is said to be constant time. In conclusion, the technique could work as an efficient detection mechanism for various asymmetric backdoors. The thesis follows with a presentation of the experiment, during which, the time measurements were taken.

6.2.1 Experiment setup

The measured variable was the time that the process spent on the processor, measured with C function

clock_gettime(CLOCK_PROCESS_CPUTIME_ID, ...) with resolution 10−6 s = 1 µs. The isolated snippets of the code were the minimal parts with changes between the infected and the clean version. For each snippet, 106 measurements were taken. All snippets were compiled with gcc 5.4.0 with default settings. Further, all measurements were taken on slightly loaded Ubuntu 16.04 without the graphical interface. The used processor was Intel i7-4770. In addition, Hyper-threading and Intel turbo boost were disabled. Before each execution of the corresponding binary, L1 cache was completely rewritten. Despite all measures, we were not able to obtain clean measurements without noise in the form of outliers. We conjecture that the outliers were present due to a scheduler, as they remained in similar magnitudes even when the empty program was measured. Further, only the outliers that showed longer execution times were present (no shorter execution

45 6. Heuristic Backdoor Detection times). In addition, despite the measured data exhibited almost constant execution times, the outliers were larger by magnitudes. We have decided to remove the outliers using the Turkey’s fences. To be exact, any observation outside the interval

[q1 − 1.5 · (q3 − q1), q3 + 1.5 · (q3 − q1)], where qi is i-th quartile, was removed from the dataset. In practice, 1% to 5% of values were marked as the outliers. Three code snippets were measured for the infected algorithm. In particular, those were the RSA pre-mater secret generation snippet, the DH private key generation, and the ClientHello nonce generation snippet. The last snippet was measured in two versions. The ﬁrst version contained only one exponentiation (computation of the public-key presented as kleptogram). The second version was expanded by shared-secret derivation between the attacker and the device. As the backdoor does not require any initialization except for loading the AES counter (other keys can be hard-coded in the binary), this aspect was ignored in the experiments. We have further measured single exponentiation on X25519 (to support the idea that distribution time of ClientHello nonce generation is determined mostly by the exponentiations. We have studied both performance of the snippets and the distribution of execution times w.r.t. variance. Average execution times are presented in table 6.1. The exact distribution of execution times is depicted in the Appendix B.

6.2.2 Average execution times

The measurements show that whole subverted version runs by 248 ms (282 ms) slower than the clean version when RSA (DH) key exchange method is used. The subverted RSA key exchange method runs slower by the factor of 2.28 over the clean version. On the contrary, the subverted DH key exchange method runs slower only by the factor of 1.01. It also can be seen that such increase in time cannot be spotted just by using the device. The increase is negligible considering that TLS is a network protocol where latency plays a role. The interaction over the network actually creates the opportunity for obfuscating the computation times.

46 6. Heuristic Backdoor Detection

Code snippet Average computation time Timer overhead 312 µs gk on X25519 171132 µs ClientHello clean 4726 µs ClientHello subverted 176293 µs ClientHello subverteda 246843 µs RSA PMS clean 4887 µs RSA PMS subverted 11185 µs DH private key gen. clean 3178587 µs DH private key gen. subverted 3218496 µs TLS context builder 374500 µs

Table 6.1: Average execution times of code snippets a. Version with the shared secret precomputation.

The exponentiations, or even parts of it, could be precomputed once the handshake is initiated, stored, and only loaded from memory when needed. The more complex the underlying protocol is, the larger is the space for obfuscations. It is also questionable, whether the inquirer will be able to isolate the corresponding snippets on the tamper-proof device to obtain precise measurements. To conclude, neither of the presented methods is reliable, and most likely could be evaded by the skilled adversary. Nevertheless, the proposal can be detected when a clean version of the OpenSSL is at hand and benchmarking is available on the same hardware on which the suspected version is running. As the largest increase in time is seen when the ClientHello nonce is generated, this could be the sweet spot for malware detection. Recall that the execution time of the ClientHello nonce function should correspond to the time in which the library generates 32 random bytes. If the function takes substantially larger amount of time, the backdoor is likely to be present.

7 Conclusions

The goal of the thesis was to decide whether a kleptographic backdoor can be embedded into the TLS protocol in a practical manner. To answer this question, the thesis ﬁrst introduced the notion of subliminal channels and presented the concept of asymmetric backdoors. The possibilities of asymmetric backdoors were further illustrated on the RSA and ElGamal encryption schemes, and on Diﬃe-Hellman key exchange protocol. This allowed to study and compare already proposed backdoors for TLS. Their security was assessed, and their compliance to SETUP conditions was formally treated. Subsequently, several improvements for the backdoor by Gołębiewski et al. were proposed. Additionally, the resulting proposal was proved to be a SETUP assuming that AES is a pseudorandom function. The practical part of the thesis implemented the backdoor into OpenSSL library as a proof-of-concept. Together with the backdoor, a recovery tool was designed that mimics the actions of the eavesdropper and enables recovery of cryptographic material of backdoored TLS session; naturally, with the knowledge of the attacker’s private key. In Chap- ter 6, the kleptogram was shown to be indistinguishable from random noise by statistical tests of randomness. Eventually, the performance of the backdoor was measured and distribution of execution times was studied. The sixth chapter concluded that the backdoor may or may not be practically detected by timing analysis, depending on the level of obfuscation and powers of the inquirer. For future research, the injective encodings of the elliptic curve points on bit strings should be studied for their provable properties of indistinguishability from random noise. It is also important to decide whether the timing analysis detection, or even power analysis, of our proposal is feasible in embedded black-box devices. Thus, the proposal could be translated into tamper-proof hardware device and possible detections of the backdoor further studied. We view the side channel analysis as a very promising path in asymmetric backdoor detection, since other defences are overly complicated to be adopted by the industry.

Bibliography

[1] A. Young and M. Yung, “The Dark Side of “Black-Box” Cryptogra- phy or: Should We Trust Capstone?” in Proceedings of Advances in Cryptology — CRYPTO ’96, 1996, pp. 89–103. [2] Z. Gołębiewski, M. Kutyłowski, and F. Zagórski, “Stealing Secrets with SSL/TLS and SSH – Kleptographic Attacks,” in CANS’06 Proceedings of the 5th international conference on Cryptology and Network Security, 2006, pp. 191–202. [3] A. Young and M. Yung, “Kleptography from Standard Assumptions and Applications,” in Proceedings of Security and Cryptography for Networks, 2010, pp. 271–290. [4] A. Young and M. Yung, Malicious Cryptography: Exposing Cryp- tovirology. Hoboken, NJ: Wiley, 2004. [5] B. W. Lampson, “A note on the Conﬁnement Problem,” Communi- cations of the ACM, vol. 16, no. 10, pp. 613–615, 1973. [6] A. J. Menezes, P. C. Van Oorschot, and S. A. Vanstone, Handbook of Applied Cryptography. Boca Raton: CRC Press, 1997. [7] G. J. Simmons, “The Subliminal Channel and Digital Signatures,” in Proceedings of Advances in Cryptology — EUROCRYPT’84, 1985, pp. 364–378. [8] H. Anderson, R. Anderson, S. M. Bellovin, J. Benaloh, M. Blaze, W. Diﬃe, J. Gilmore, P. G. Neumann, R. L. Rivest, J. I. Schiller, and B. Schneier, “The Risks of Key Recovery, Key Escrow, and Trusted Third-Party Encryption,” World Wide Web Journal - Special issue: Web security: a matter of trust, vol. 2, no. 3, pp. 241 – 257, 1997. [9] A. Young and M. Yung, “Cryptovirology: extortion-based security threats and countermeasures,” in Proceedings of IEEE Symposium on Security and Privacy, 1996, pp. 129–140. [10] A. Young and M. Yung, “Kleptography: Using Cryptography Against Cryptography,” in Proceedings of Advances in Cryptol- ogy — EUROCRYPT ’97, 1997, pp. 62–74.

51 BIBLIOGRAPHY

[11] A. Young and M. Yung, “Bandwidth-Optimal Kleptographic At- tacks,” in Proceedings of Cryptographic Hardware and Embedded Systems — CHES 2001, 2001, pp. 235–250. [12] A. Young and M. Yung, “A Timing-Resistant Elliptic Curve Back- door in RSA,” in Information Security and Cryptology. Berlin, Heidelberg: Springer Berlin Heidelberg, 2008, pp. 427–441. [13] M. Bellare and P. Rogaway, “Random oracles are practical: a paradigm for designing eﬃcient protocols,” in CCS ’93 Proceed- ings of the 1st ACM conference on Computer and communications security, 1993, pp. 62 – 73. [14] N. Koblitz and A. J. Menezes, “The random oracle model: a twenty- year retrospective,” Designs, Codes and Cryptography, vol. 77, no. 2, pp. 587 – 610, 2015. [15] E. Barker and J. Kelsey, “Recommendation for Random Number Generation Using Deterministic Random Bit Generators,” National Institute of Standards and Technology, Tech. Rep., 2012. [16] K. Gjøsteen, “Comments on dual-ec-drbg/nist sp 800-90, draft december 2005,” Tech. Rep. [17] S. Checkoway, et al., “On the practical exploitability of dual ec in tls implementations,” in SEC’14 Proceedings of the 23rd USENIX conference on Security Symposium, 2014, pp. 319 – 335. [18] A. Russell et al., “Generic Semantic Security against a Klepto- graphic Adversary,” in Proceedings of ACM SIGSAC Conference on Computer and Communications Security, 2017, pp. 907–922. [19] Q. Tang et al., “Cliptography: Clipping the Power of Kleptographic Attacks,” in Proceedings of Advances in Cryptology – ASIACRYPT 2016, 2016, pp. 34–64. [20] D. Kucner and M. Kutylowski, “Stochastic Kleltography Detecion,” in Proceedings of Public-Key Cryptography and Computational Number Theory, 2001, pp. 137 – 149. [21] I. Ristic, Bulletproof SSL and TLS: understanding and deploying SSL/TLS and PKI to secure servers and web applications. London: Feisty Duck, 2015.

52 BIBLIOGRAPHY

[22] T. Dierks and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” Internet Requests for Comments, RFC 5246, 2008. [Online]. Available: https://www.ietf.org/rfc/rfc5246.txt [23] A. Young and M. Yung, “Space-Eﬃcient Kleptography Without Random Oracles,” in IH’07 Proceedings of the 9th international conference on Information hiding, 2007, pp. 112–129. [24] D.J. Bernstein et al., “Elligator: elliptic-curve points indistinguishable from uniform random strings,” 2013, pp. 967–980. [25] M. Tibouchi, “Elligator Squared: Uniform Points on Elliptic Curves of Prime Order as Uniform Random Strings,” in Financial Cryp- tography and Data Security: 18th International Conference, pp. 139–156. [26] L. von Ahn and N. J. Hopper, “Public-Key Steganography,” in Proceedings of Advances in Cryptology - EUROCRYPT 2004, 2004, pp. 323–341. [27] B. S. Kaliski, “A Pseudo-Random Bit Generator Based on El- liptic Logarithms,” in Proceedings of Advances in Cryptology — CRYPTO’ 86, 1986, pp. 84–103. [28] P. Rogaway, “Evaluation of Some Blockcipher Modes of Operation,” 2011. [29] E. B. Barker and J. M. Kelsey, “Recommendation for Random Number Generation Using Deterministic Random Bit Generators,” National Institute of Standards and Technology, Tech. Rep., 2015. [30] D. J. Brenstein, “Curve25519: New Diﬃe-Hellman Speed Records,” in Proceedings of Public Key Cryptography - PKC 2006, 2006, pp. 207 – 228. [31] E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3 draft-ietf-tls-tls13-28,” Internet Requests for Comments, RFC, 2018. [Online]. Available: https://tools.ietf.org/html/ draft-ietf-tls-tls13-28 [32] A. Medvinsky and M. Hur, “ Addition of Kerberos Cipher Suites to Transport Layer Security (TLS),” Internet Requests

53 BIBLIOGRAPHY

for Comments, RFC 2712, 1999. [Online]. Available: https: //www.ietf.org/rfc/rfc2712.txt [33] Taylor D. et al., “Using the Secure Remote Password (SRP) Protocol for TLS Authentication,” Internet Requests for Comments, RFC 5054, 2007. [Online]. Available: https: //www.ietf.org/rfc/rfc5054.txt [34] P. Eronen and H. Tschofenig, “Pre-Shared Key Ciphersuites for Transport Layer Security (TLS),” Internet Requests for Comments, RFC 4279, 2005. [Online]. Available: https: //www.ietf.org/rfc/rfc4279.txt [35] R. G. Brown, “Robert g. brown’s general tools page,” 2004, accessed: 30.4.2018. [Online]. Available: https://webhome.phy.duke. edu/~rgb/General/dieharder.php [36] A. Rukhin, et al., “A Statistical Test Suite for Random and Pseu- dorandom Number Generators for Cryptographic Applications ,” National Institute of Standards and Technology, Tech. Rep., 2010.

54 Appendices

A Statistical Tests of Randomness Results

The following documents represent results of statistical tests of randomness. Those were performed on AES-CTR that was transformed into PRNG.

Results of NIST suite

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− RESULTS FOR THE UNIFORMITY OF P−VALUES AND THE PROPORTION OF PASSING SEQUENCES −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− generator is −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 P−VALUE PROPORTION STATISTICAL TEST −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 93 97 112 107 108 105 98 84 98 98 0.731886 997/1000 Frequency 88 102 108 90 99 110 101 101 118 83 0.328297 990/1000 BlockFrequency 88 102 107 102 91 96 103 103 108 100 0.924076 997/1000 CumulativeSums 92 95 100 101 107 94 110 105 97 99 0.960198 996/1000 CumulativeSums 101 111 110 92 92 106 99 95 96 98 0.889118 993/1000 Runs 99 112 96 90 109 93 122 101 87 91 0.258307 986/1000 LongestRun 97 110 91 102 112 114 84 112 77 101 0.101311 989/1000 Rank 105 89 94 112 120 89 107 90 103 91 0.285427 994/1000 FFT 113 98 109 103 74 94 102 107 99 101 0.326749 982/1000 NonOverlappingTemplate 98 111 80 105 92 103 100 105 97 109 0.597620 990/1000 NonOverlappingTemplate 103 113 99 82 84 111 116 109 91 92 0.136499 990/1000 NonOverlappingTemplate 91 102 107 109 94 91 101 101 97 107 0.916599 988/1000 NonOverlappingTemplate 100 84 95 87 100 117 106 100 109 102 0.474986 989/1000 NonOverlappingTemplate 121 92 104 88 105 91 91 93 106 109 0.336111 998/1000 NonOverlappingTemplate 84 95 121 94 108 103 95 86 120 94 0.094285 992/1000 NonOverlappingTemplate 104 98 93 97 88 106 94 108 114 98 0.781106 993/1000 NonOverlappingTemplate 109 91 105 104 107 77 97 103 92 115 0.284024 995/1000 NonOverlappingTemplate 99 99 96 122 94 99 90 100 104 97 0.674543 985/1000 NonOverlappingTemplate 90 115 89 107 99 109 89 96 97 109 0.530120 990/1000 NonOverlappingTemplate 110 102 119 103 100 96 93 103 85 89 0.442831 986/1000 NonOverlappingTemplate 110 90 94 99 92 92 101 107 124 91 0.295391 987/1000 NonOverlappingTemplate 110 106 102 74 117 102 88 122 72 107 0.002287 987/1000 NonOverlappingTemplate 90 100 107 98 93 93 96 104 121 98 0.607993 994/1000 NonOverlappingTemplate 97 82 103 109 111 90 116 93 99 100 0.392456 986/1000 NonOverlappingTemplate 107 98 121 95 114 87 89 91 86 112 0.113372 987/1000 NonOverlappingTemplate 97 92 97 102 84 120 111 109 98 90 0.313041 994/1000 NonOverlappingTemplate 95 84 84 106 117 102 114 96 108 94 0.225998 992/1000 NonOverlappingTemplate 105 92 95 86 94 118 105 90 107 108 0.429923 988/1000 NonOverlappingTemplate 90 113 102 90 99 97 110 93 104 102 0.786830 994/1000 NonOverlappingTemplate

57 A. Statistical Tests of Randomness Results

96 85 101 98 114 111 101 115 74 105 0.093720 990/1000 NonOverlappingTemplate 119 98 98 111 107 104 96 78 91 98 0.249284 987/1000 NonOverlappingTemplate 99 107 88 98 99 83 99 102 126 99 0.230755 991/1000 NonOverlappingTemplate 97 105 96 89 91 109 100 109 106 98 0.872425 991/1000 NonOverlappingTemplate 98 98 100 114 99 96 113 94 94 94 0.836048 993/1000 NonOverlappingTemplate 114 94 84 97 109 127 84 100 84 107 0.028056 992/1000 NonOverlappingTemplate 102 108 82 119 101 91 106 91 104 96 0.363593 989/1000 NonOverlappingTemplate 94 93 117 106 103 79 87 115 104 102 0.174728 995/1000 NonOverlappingTemplate 87 91 105 89 115 109 92 96 100 116 0.320607 987/1000 NonOverlappingTemplate 111 104 98 84 106 109 111 96 91 90 0.502247 992/1000 NonOverlappingTemplate 102 77 110 113 85 87 115 100 109 102 0.089301 988/1000 NonOverlappingTemplate 105 103 90 97 104 109 87 99 96 110 0.811080 991/1000 NonOverlappingTemplate 96 110 93 116 100 108 107 91 91 88 0.494392 991/1000 NonOverlappingTemplate 91 98 99 111 101 106 110 102 100 82 0.666245 992/1000 NonOverlappingTemplate 106 102 70 114 92 97 97 120 89 113 0.024521 987/1000 NonOverlappingTemplate 106 109 106 98 89 83 105 110 102 92 0.574903 989/1000 NonOverlappingTemplate 96 97 118 106 86 108 89 114 82 104 0.161703 988/1000 NonOverlappingTemplate 89 103 119 98 114 92 113 79 89 104 0.090388 996/1000 NonOverlappingTemplate 116 109 101 91 89 100 90 106 96 102 0.641284 990/1000 NonOverlappingTemplate 104 99 109 97 91 99 123 104 81 93 0.246750 992/1000 NonOverlappingTemplate 95 104 88 105 107 99 101 101 89 111 0.830808 992/1000 NonOverlappingTemplate 105 105 102 93 112 115 81 88 104 95 0.336111 991/1000 NonOverlappingTemplate 84 111 100 105 101 106 89 94 95 115 0.488534 994/1000 NonOverlappingTemplate 115 86 104 111 94 98 97 105 99 91 0.622546 985/1000 NonOverlappingTemplate 99 90 81 109 102 98 86 109 100 126 0.089843 995/1000 NonOverlappingTemplate 97 111 96 100 118 83 80 114 107 94 0.108791 988/1000 NonOverlappingTemplate 94 113 101 88 98 110 99 96 98 103 0.848027 986/1000 NonOverlappingTemplate 98 111 94 95 100 91 104 103 99 105 0.956729 994/1000 NonOverlappingTemplate 98 115 103 92 95 112 87 91 102 105 0.585209 988/1000 NonOverlappingTemplate 102 100 107 95 100 90 82 111 104 109 0.616305 993/1000 NonOverlappingTemplate 87 105 89 91 99 102 122 95 102 108 0.368587 990/1000 NonOverlappingTemplate 88 102 111 89 88 88 108 114 108 104 0.336111 985/1000 NonOverlappingTemplate 110 90 91 107 102 92 90 112 95 111 0.546283 988/1000 NonOverlappingTemplate 113 96 102 102 93 84 102 89 124 95 0.200115 992/1000 NonOverlappingTemplate 93 98 119 110 83 95 78 103 105 116 0.066465 991/1000 NonOverlappingTemplate 100 101 102 86 76 103 104 108 108 112 0.293952 983/1000 NonOverlappingTemplate 86 110 100 105 123 91 103 107 99 76 0.074330 992/1000 NonOverlappingTemplate 98 108 92 107 104 92 104 113 89 93 0.723804 997/1000 NonOverlappingTemplate

58 A. Statistical Tests of Randomness Results

90 91 88 101 102 104 107 107 112 98 0.747898 991/1000 NonOverlappingTemplate 104 102 100 100 103 91 98 101 91 110 0.965860 991/1000 NonOverlappingTemplate 111 107 98 101 94 87 101 90 102 109 0.773405 989/1000 NonOverlappingTemplate 95 116 111 94 107 111 109 90 85 82 0.146152 992/1000 NonOverlappingTemplate 89 104 107 87 107 85 107 87 122 105 0.138860 988/1000 NonOverlappingTemplate 88 114 89 106 114 94 130 76 83 106 0.002657 989/1000 NonOverlappingTemplate 131 98 112 90 101 105 101 88 77 97 0.023705 989/1000 NonOverlappingTemplate 97 103 86 103 107 101 113 102 91 97 0.801865 993/1000 NonOverlappingTemplate 79 100 106 91 98 115 118 95 113 85 0.083018 993/1000 NonOverlappingTemplate 97 93 115 73 96 92 103 128 104 99 0.025023 987/1000 NonOverlappingTemplate 99 99 100 87 103 111 101 99 104 97 0.952152 986/1000 NonOverlappingTemplate 92 102 86 98 96 103 88 105 133 97 0.075719 993/1000 NonOverlappingTemplate 87 108 109 97 101 86 109 110 100 93 0.585209 993/1000 NonOverlappingTemplate 83 92 109 98 105 99 94 108 93 119 0.371941 992/1000 NonOverlappingTemplate 112 98 98 96 99 100 99 110 99 89 0.916599 986/1000 NonOverlappingTemplate 113 98 108 105 73 93 103 107 99 101 0.275709 982/1000 NonOverlappingTemplate 112 95 111 86 88 93 108 106 109 92 0.415422 987/1000 NonOverlappingTemplate 91 90 97 108 118 107 117 100 92 80 0.129620 996/1000 NonOverlappingTemplate 103 110 87 94 95 105 114 107 98 87 0.552383 991/1000 NonOverlappingTemplate 93 92 118 101 82 98 105 113 120 78 0.030399 988/1000 NonOverlappingTemplate 101 112 112 101 96 108 100 89 92 89 0.662091 994/1000 NonOverlappingTemplate 93 97 120 94 99 88 100 103 105 101 0.664168 983/1000 NonOverlappingTemplate 108 95 104 96 105 103 109 93 91 96 0.922855 990/1000 NonOverlappingTemplate 98 92 95 111 103 103 110 95 95 98 0.920383 995/1000 NonOverlappingTemplate 109 94 115 90 115 102 105 86 95 89 0.320607 983/1000 NonOverlappingTemplate 112 81 104 91 98 99 106 98 106 105 0.628790 990/1000 NonOverlappingTemplate 110 93 98 86 85 86 111 99 126 106 0.066051 987/1000 NonOverlappingTemplate 91 125 82 106 96 116 93 108 80 103 0.028817 988/1000 NonOverlappingTemplate 97 84 90 115 105 104 88 112 98 107 0.373625 992/1000 NonOverlappingTemplate 96 83 109 101 103 95 102 97 114 100 0.709558 988/1000 NonOverlappingTemplate 111 93 95 99 99 97 111 100 99 96 0.944274 993/1000 NonOverlappingTemplate 96 105 91 111 93 99 103 103 102 97 0.954015 988/1000 NonOverlappingTemplate 94 98 96 94 105 99 112 98 102 102 0.973718 989/1000 NonOverlappingTemplate 81 117 86 104 93 99 102 120 86 112 0.056069 994/1000 NonOverlappingTemplate 93 115 95 110 100 104 90 96 94 103 0.763677 990/1000 NonOverlappingTemplate 98 110 119 101 97 82 104 96 101 92 0.440975 991/1000 NonOverlappingTemplate 97 91 118 95 104 93 89 110 115 88 0.279844 990/1000 NonOverlappingTemplate 102 94 115 102 105 99 110 98 82 93 0.562591 988/1000 NonOverlappingTemplate

59 A. Statistical Tests of Randomness Results

99 105 88 118 114 86 104 108 79 99 0.119508 990/1000 NonOverlappingTemplate 105 90 104 106 106 87 90 93 104 115 0.562591 993/1000 NonOverlappingTemplate 115 83 94 121 107 89 92 95 99 105 0.173770 991/1000 NonOverlappingTemplate 120 102 91 100 109 92 100 85 105 96 0.440975 983/1000 NonOverlappingTemplate 102 97 113 108 109 80 103 91 97 100 0.508172 993/1000 NonOverlappingTemplate 93 116 92 101 100 91 102 104 102 99 0.854708 995/1000 NonOverlappingTemplate 104 91 106 88 108 113 114 89 99 88 0.373625 985/1000 NonOverlappingTemplate 97 100 95 117 103 92 104 83 104 105 0.593478 994/1000 NonOverlappingTemplate 98 102 137 111 107 92 97 81 97 78 0.003273 993/1000 NonOverlappingTemplate 80 99 114 91 107 91 99 104 108 107 0.402962 991/1000 NonOverlappingTemplate 108 106 89 100 94 103 100 100 108 92 0.915317 989/1000 NonOverlappingTemplate 73 85 113 96 125 91 108 109 95 105 0.015598 998/1000 NonOverlappingTemplate 93 92 98 104 99 99 100 107 90 118 0.731886 990/1000 NonOverlappingTemplate 103 88 97 114 97 100 118 87 99 97 0.465415 994/1000 NonOverlappingTemplate 91 98 105 116 110 86 100 102 89 103 0.538182 987/1000 NonOverlappingTemplate 93 108 101 86 121 110 90 88 100 103 0.272977 993/1000 NonOverlappingTemplate 99 109 102 89 100 97 104 102 95 103 0.975012 992/1000 NonOverlappingTemplate 87 82 111 105 96 91 121 118 101 88 0.057875 995/1000 NonOverlappingTemplate 92 100 95 95 110 106 93 90 92 127 0.217857 986/1000 NonOverlappingTemplate 104 83 91 114 102 105 110 92 101 98 0.554420 987/1000 NonOverlappingTemplate 94 93 105 111 91 100 94 102 113 97 0.807412 987/1000 NonOverlappingTemplate 110 107 94 120 118 75 89 73 97 117 0.001498 991/1000 NonOverlappingTemplate 89 101 89 105 113 107 99 114 101 82 0.344048 990/1000 NonOverlappingTemplate 98 109 98 102 102 92 100 95 109 95 0.967382 989/1000 NonOverlappingTemplate 93 93 104 103 89 105 99 111 94 109 0.827279 989/1000 NonOverlappingTemplate 92 93 109 98 102 106 110 102 86 102 0.796268 994/1000 NonOverlappingTemplate 93 107 115 93 98 95 101 102 101 95 0.889118 986/1000 NonOverlappingTemplate 101 92 105 100 95 101 114 97 90 105 0.878618 983/1000 NonOverlappingTemplate 83 109 98 118 88 104 99 110 110 81 0.115387 990/1000 NonOverlappingTemplate 103 96 106 103 90 107 95 92 124 84 0.249284 994/1000 NonOverlappingTemplate 106 94 91 102 102 103 90 94 98 120 0.626709 985/1000 NonOverlappingTemplate 103 83 111 98 97 112 112 100 96 88 0.455937 991/1000 NonOverlappingTemplate 101 99 99 99 101 99 90 104 101 107 0.995162 993/1000 NonOverlappingTemplate 103 109 97 82 99 111 114 95 85 105 0.337688 984/1000 NonOverlappingTemplate 84 97 97 80 116 117 95 87 111 116 0.036352 992/1000 NonOverlappingTemplate 112 100 101 116 90 89 101 104 96 91 0.599693 988/1000 NonOverlappingTemplate 89 105 115 98 115 102 93 82 108 93 0.282626 994/1000 NonOverlappingTemplate 119 80 111 117 95 104 78 113 81 102 0.007975 986/1000 NonOverlappingTemplate

60 A. Statistical Tests of Randomness Results

94 116 91 110 89 91 94 115 110 90 0.251837 990/1000 NonOverlappingTemplate 105 92 105 89 115 85 121 110 81 97 0.067722 989/1000 NonOverlappingTemplate 108 83 102 91 109 110 79 108 95 115 0.131879 986/1000 NonOverlappingTemplate 95 95 100 104 113 101 103 99 96 94 0.965083 990/1000 NonOverlappingTemplate 95 80 86 101 92 105 96 106 121 118 0.083526 990/1000 NonOverlappingTemplate 96 120 104 88 100 92 113 98 94 95 0.461612 992/1000 NonOverlappingTemplate 102 92 115 100 100 107 102 94 90 98 0.846338 993/1000 NonOverlappingTemplate 89 93 100 109 91 93 99 111 102 113 0.662091 990/1000 NonOverlappingTemplate 91 85 94 130 109 94 99 90 106 102 0.090936 988/1000 NonOverlappingTemplate 86 95 96 93 101 96 97 105 105 126 0.320607 989/1000 NonOverlappingTemplate 102 106 99 96 101 78 107 87 119 105 0.245490 991/1000 NonOverlappingTemplate 94 103 102 100 102 100 104 89 101 105 0.988677 994/1000 NonOverlappingTemplate 112 98 98 96 100 100 98 110 99 89 0.915317 986/1000 NonOverlappingTemplate 107 107 100 108 110 84 89 81 90 124 0.052610 992/1000 OverlappingTemplate 106 104 104 102 104 99 101 89 97 94 0.979226 989/1000 Universal 106 98 115 101 81 98 98 100 107 96 0.637119 995/1000 ApproximateEntropy 64 51 69 62 71 71 61 58 72 46 0.247035 624/625 RandomExcursions 61 58 70 75 62 65 55 55 51 73 0.378595 619/625 RandomExcursions 66 51 59 72 67 52 66 66 67 59 0.632081 618/625 RandomExcursions 58 64 73 52 57 57 61 65 78 60 0.432820 618/625 RandomExcursions 65 67 65 52 58 70 63 67 60 58 0.887740 616/625 RandomExcursions 59 63 66 63 53 64 68 66 65 58 0.962346 621/625 RandomExcursions 59 70 66 74 64 47 44 66 69 66 0.122900 620/625 RandomExcursions 55 66 58 70 66 65 58 70 60 56 0.861473 616/624 RandomExcursions 62 50 79 65 58 63 48 65 76 59 0.121753 619/625 RandomExcursionsVariant 57 71 62 67 62 63 59 60 54 70 0.882929 620/625 RandomExcursionsVariant 55 71 69 45 77 65 63 49 70 61 0.087881 622/625 RandomExcursionsVariant 54 67 60 68 56 68 64 70 52 66 0.718763 620/625 RandomExcursionsVariant 51 65 70 70 59 63 64 60 67 56 0.794815 622/625 RandomExcursionsVariant 57 67 64 74 68 60 55 55 69 56 0.658939 624/625 RandomExcursionsVariant 57 67 69 61 58 65 68 65 63 52 0.885346 622/625 RandomExcursionsVariant 57 68 62 67 52 72 71 59 57 60 0.685690 617/625 RandomExcursionsVariant 68 63 52 63 57 63 73 62 69 55 0.722038 615/625 RandomExcursionsVariant 67 63 58 50 63 63 69 63 67 62 0.894779 615/625 RandomExcursionsVariant 60 69 62 63 51 51 59 63 84 63 0.173863 617/625 RandomExcursionsVariant 63 64 51 61 83 59 51 59 65 69 0.194881 619/625 RandomExcursionsVariant 55 62 68 75 70 57 64 63 43 68 0.212402 620/625 RandomExcursionsVariant 62 65 58 61 60 74 68 66 65 46 0.542293 620/625 RandomExcursionsVariant 63 69 59 56 56 59 59 61 75 68 0.767016 618/625 RandomExcursionsVariant 68 58 61 53 68 60 54 60 74 69 0.635440 618/625 RandomExcursionsVariant 69 55 54 62 65 54 75 48 83 60 0.051038 621/625 RandomExcursionsVariant 67 57 61 61 68 46 60 76 57 72 0.290356 620/625 RandomExcursionsVariant 94 112 86 100 101 109 99 89 116 94 0.463512 993/1000 Serial 95 101 94 113 93 102 100 105 93 104 0.927677 988/1000 Serial

61 A. Statistical Tests of Randomness Results

79 90 98 99 104 94 108 121 114 93 0.142062 993/1000 LinearComplexity

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− The minimum pass rate for each statistical test with the exception of the random excursion (variant) test is approximately = 980 for a sample size = 1000 binary sequences.

The minimum pass rate for the random excursion (variant) test is approximately = 611 for a sample size = 625 binary sequences.

For further guidelines construct a probability table using the MAPLE program provided in the addendum section of the documentation. −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

Results of Dieharder suite

#======# # dieharder version 3.31.1 Copyright 2003 RobertG. Brown # #======# rng_name |rands/second| Seed | mt19937| 1.70e+08 | 445413937| #======# test_name |ntup| tsamples |psamples| p−value |Assessment #======# diehard_birthdays| 0| 100| 100|0.29236632| PASSED diehard_operm5| 0| 1000000| 100|0.08551227| PASSED diehard_rank_32x32| 0| 40000| 100|0.54847352| PASSED diehard_rank_6x8| 0| 100000| 100|0.10585248| PASSED diehard_bitstream| 0| 2097152| 100|0.98330432| PASSED diehard_opso| 0| 2097152| 100|0.99205496| PASSED diehard_oqso| 0| 2097152| 100|0.13892914| PASSED diehard_dna| 0| 2097152| 100|0.96540904| PASSED diehard_count_1s_str| 0| 256000| 100|0.06323869| PASSED diehard_count_1s_byt| 0| 256000| 100|0.38952072| PASSED diehard_parking_lot| 0| 12000| 100|0.37180234| PASSED diehard_2dsphere| 2| 8000| 100|0.99351723| PASSED diehard_3dsphere| 3| 4000| 100|0.69893166| PASSED diehard_squeeze| 0| 100000| 100|0.88195385| PASSED diehard_sums| 0| 100| 100|0.33135349| PASSED diehard_runs| 0| 100000| 100|0.20184999| PASSED diehard_runs| 0| 100000| 100|0.68796622| PASSED diehard_craps| 0| 200000| 100|0.68010118| PASSED diehard_craps| 0| 200000| 100|0.84049954| PASSED marsaglia_tsang_gcd| 0| 10000000| 100|0.07448317| PASSED marsaglia_tsang_gcd| 0| 10000000| 100|0.97081170| PASSED sts_monobit| 1| 100000| 100|0.97090422| PASSED sts_runs| 2| 100000| 100|0.12206353| PASSED sts_serial| 1| 100000| 100|0.85744641| PASSED sts_serial| 2| 100000| 100|0.69852346| PASSED sts_serial| 3| 100000| 100|0.99628668| WEAK sts_serial| 3| 100000| 100|0.91305115| PASSED sts_serial| 4| 100000| 100|0.80248053| PASSED sts_serial| 4| 100000| 100|0.58336775| PASSED sts_serial| 5| 100000| 100|0.32151476| PASSED sts_serial| 5| 100000| 100|0.47107199| PASSED sts_serial| 6| 100000| 100|0.35433938| PASSED sts_serial| 6| 100000| 100|0.92861700| PASSED sts_serial| 7| 100000| 100|0.73750030| PASSED sts_serial| 7| 100000| 100|0.61237030| PASSED sts_serial| 8| 100000| 100|0.70103634| PASSED sts_serial| 8| 100000| 100|0.59427368| PASSED sts_serial| 9| 100000| 100|0.85218168| PASSED sts_serial| 9| 100000| 100|0.96407758| PASSED sts_serial| 10| 100000| 100|0.98899441| PASSED sts_serial| 10| 100000| 100|0.84619625| PASSED sts_serial| 11| 100000| 100|0.32174978| PASSED sts_serial| 11| 100000| 100|0.33386603| PASSED sts_serial| 12| 100000| 100|0.29655450| PASSED sts_serial| 12| 100000| 100|0.65142410| PASSED sts_serial| 13| 100000| 100|0.41517328| PASSED sts_serial| 13| 100000| 100|0.34328918| PASSED sts_serial| 14| 100000| 100|0.25019560| PASSED

62 A. Statistical Tests of Randomness Results

sts_serial| 14| 100000| 100|0.32019035| PASSED sts_serial| 15| 100000| 100|0.98840256| PASSED sts_serial| 15| 100000| 100|0.72758818| PASSED sts_serial| 16| 100000| 100|0.86822033| PASSED sts_serial| 16| 100000| 100|0.30767590| PASSED rgb_bitdist| 1| 100000| 100|0.03865045| PASSED rgb_bitdist| 2| 100000| 100|0.52556619| PASSED rgb_bitdist| 3| 100000| 100|0.29167458| PASSED rgb_bitdist| 4| 100000| 100|0.32228969| PASSED rgb_bitdist| 5| 100000| 100|0.71617249| PASSED rgb_bitdist| 6| 100000| 100|0.82043325| PASSED rgb_bitdist| 7| 100000| 100|0.67364484| PASSED rgb_bitdist| 8| 100000| 100|0.24061082| PASSED rgb_bitdist| 9| 100000| 100|0.61557738| PASSED rgb_bitdist| 10| 100000| 100|0.96862624| PASSED rgb_bitdist| 11| 100000| 100|0.39793059| PASSED rgb_bitdist| 12| 100000| 100|0.17182798| PASSED rgb_minimum_distance| 2| 10000| 1000|0.46958114| PASSED rgb_minimum_distance| 3| 10000| 1000|0.57747136| PASSED rgb_minimum_distance| 4| 10000| 1000|0.51250760| PASSED rgb_minimum_distance| 5| 10000| 1000|0.09453181| PASSED rgb_permutations| 2| 100000| 100|0.29532061| PASSED rgb_permutations| 3| 100000| 100|0.76668667| PASSED rgb_permutations| 4| 100000| 100|0.41237930| PASSED rgb_permutations| 5| 100000| 100|0.35711873| PASSED rgb_lagged_sum| 0| 1000000| 100|0.65300264| PASSED rgb_lagged_sum| 1| 1000000| 100|0.98513108| PASSED rgb_lagged_sum| 2| 1000000| 100|0.92580209| PASSED rgb_lagged_sum| 3| 1000000| 100|0.03975353| PASSED rgb_lagged_sum| 4| 1000000| 100|0.38019970| PASSED rgb_lagged_sum| 5| 1000000| 100|0.15623103| PASSED rgb_lagged_sum| 6| 1000000| 100|0.83189636| PASSED rgb_lagged_sum| 7| 1000000| 100|0.77638797| PASSED rgb_lagged_sum| 8| 1000000| 100|0.72481025| PASSED rgb_lagged_sum| 9| 1000000| 100|0.99925360| WEAK rgb_lagged_sum| 10| 1000000| 100|0.30375754| PASSED rgb_lagged_sum| 11| 1000000| 100|0.92515630| PASSED rgb_lagged_sum| 12| 1000000| 100|0.58588081| PASSED rgb_lagged_sum| 13| 1000000| 100|0.32070003| PASSED rgb_lagged_sum| 14| 1000000| 100|0.39763036| PASSED rgb_lagged_sum| 15| 1000000| 100|0.38819638| PASSED rgb_lagged_sum| 16| 1000000| 100|0.66482007| PASSED rgb_lagged_sum| 17| 1000000| 100|0.80917374| PASSED rgb_lagged_sum| 18| 1000000| 100|0.67600005| PASSED rgb_lagged_sum| 19| 1000000| 100|0.37342394| PASSED rgb_lagged_sum| 20| 1000000| 100|0.72180987| PASSED rgb_lagged_sum| 21| 1000000| 100|0.66116262| PASSED rgb_lagged_sum| 22| 1000000| 100|0.95459656| PASSED rgb_lagged_sum| 23| 1000000| 100|0.44747675| PASSED rgb_lagged_sum| 24| 1000000| 100|0.06763271| PASSED rgb_lagged_sum| 25| 1000000| 100|0.78287885| PASSED rgb_lagged_sum| 26| 1000000| 100|0.20961635| PASSED rgb_lagged_sum| 27| 1000000| 100|0.75534099| PASSED rgb_lagged_sum| 28| 1000000| 100|0.11237894| PASSED rgb_lagged_sum| 29| 1000000| 100|0.73496194| PASSED rgb_lagged_sum| 30| 1000000| 100|0.75411371| PASSED rgb_lagged_sum| 31| 1000000| 100|0.29056380| PASSED rgb_lagged_sum| 32| 1000000| 100|0.27077505| PASSED rgb_kstest_test| 0| 10000| 1000|0.78808435| PASSED dab_bytedistrib| 0| 51200000| 1|0.51769693| PASSED dab_dct| 256| 50000| 1|0.69359611| PASSED Preparing to run test 207. ntuple = 0 dab_filltree| 32| 15000000| 1|0.73602996| PASSED dab_filltree| 32| 15000000| 1|0.68258738| PASSED Preparing to run test 208. ntuple = 0 dab_filltree2| 0| 5000000| 1|0.74543353| PASSED dab_filltree2| 1| 5000000| 1|0.04701997| PASSED Preparing to run test 209. ntuple = 0 dab_monobit2| 12| 65000000| 1|0.62186337| PASSED

B Distribution of Execution Times

The following plots depict the densities of execution times of the code snippets from chapter 6. The span of the x axis is kept constant across the corresponding sub-graphs, but the center is shifted according to the mean values.

65 B. Distribution of Execution Times

66 C Data Attachment

The electronic archive of this thesis — https://is.muni.cz/th/410390/ fi_m/ — contains the following data attachments: • The results of the NIST battery as presented in Appendix A. • The results of the Dieharder battery as presented in Appendix A. • The zip archive subverted_library.zip that contains both subverted OpenSSL library and a recovery tool as described in Chapter 5. A consise tutorial is also included in the archive.