How to Encrypt with a Malicious Random Number Generator
Total Page:16
File Type:pdf, Size:1020Kb
How to Encrypt with a Malicious Random Number Generator Seny Kamara1? and Jonathan Katz2?? 1 Johns Hopkins University [email protected] 2 University of Maryland [email protected] Abstract. Chosen-plaintext attacks on private-key encryption schemes are currently modeled by giving an adversary access to an oracle that encrypts a given message m using random coins that are generated uni- formly at random and independently of anything else. This leaves open the possibility of attacks in case the random coins are poorly generated (e.g., using a faulty random number generator), or are under partial ad- versarial control (e.g., when encryption is done by lightweight devices that may be captured and tampered with). We introduce new notions of security modeling such attacks, propose two concrete schemes meeting our definitions, and show generic transforma- tions for achieving security in this context. Key words: Private-key encryption, random number generation 1 Introduction Security against chosen-plaintext attacks (CPA-security) [10, 2, 12] is, nowadays, considered a minimal notion of security that any private-key encryption scheme deployed in practice should satisfy. (We defer for now any discussion of security against chosen-ciphertext attacks, though we will consider such attacks later.) Very roughly speaking, CPA-security means that given a challenge ciphertext generated using an unknown key K, a computationally-bounded adversary can- not recover any partial information about the underlying plaintext even if it is given access to an encryption oracle that returns an encryption (using the same key K) of any message m provided by the adversary. This \encryption oracle" is meant, in part, to model potential real-world actions of an adversary that might influence the honest sender (holding the key K) to encrypt certain messages that are (partially or entirely) under the adversary's control. It is not hard to see that any scheme secure with respect to chosen-plaintext attacks must be probabilistic. Furthermore, it is by now well-understood how to construct CPA-secure schemes under the assumption that the sender is able ? Supported in part by the Phillips and Camille Bradford Fellowship. ?? Research supported in part by the U.S. Army Research Laboratory. to generate a fresh set of uniformly random coins each time a message is en- crypted. In practice, such coins might be generated by using a combination of randomness extractors and pseudorandom number generators (PRNGs) to distill pseudorandom coins from a high-entropy source available to the sender. The above, however, neglects the possibility that the random coins used to encrypt may sometimes be \less than perfect". For example, the sender may be using a faulty PRNG that produces biased or partially predictable outputs. Or, the random source used to seed the PRNG may have less entropy than originally thought. More malicious scenarios include the possibilities that an adversary may have tampered with the PRNG used by the sender, or may be able to effect some control over the random source used to seed the PRNG. In the most extreme case, the adversary may have physical access to the device performing the encryption (as might be the case if, e.g., encryption is carried out on a lightweight device captured by the adversary), and may then have complete control over the \random coins" that will actually be used to encrypt. We refer to such attacks as chosen-randomness attacks. In this work, we introduce new definitions of security that offer protection against the attacks just described. Our definitions assume the worst possible case: that the randomness used by the encryption oracle is under the complete control of the adversary. In fact, the only random coins that are not under the adversary's control (other than those used to generate the key) are those that are used to encrypt the challenge ciphertext; we assume those coins are truly random.1 Our definition, then, can be viewed (informally) as offering semantic security for any messages that are encrypted using \good" random coins, even if the adversary is able to \probe" the system repeatedly and thereby cause the sender to use \poor" random coins when encrypting other messages. Summary of our contributions. We formally define security against chosen- randomness attacks (CRA-security), both with and without the additional pres- ence of a decryption oracle. We then show two secure constructions that can be based on any block cipher. The first is a relatively simple fixed-length construc- tion, while the second is a scheme that can encrypt arbitrary-length messages. We also show a generic transformation converting any CPA-secure scheme into a CRA-secure scheme. Finally, we propose a simple way to extend any CRA-secure scheme so as to also achieve security against chosen-ciphertext attacks. 1.1 Related Work The most relevant prior work is perhaps Rogaway's notion of nonce-based private- key encryption [15], which treats the encryption algorithm as a deterministic 1 It is not hard to see that some assumption regarding those coins is necessary in our setting (if the adversary has complete control over all coins, then the scheme degenerates to a deterministic one that cannot be secure); our assumption that the coins used to generate the challenge ciphertext are truly random is made for simplicity, and can be relaxed by using randomness extractors and assuming only access to a high-entropy source when encrypting the challenge ciphertext. function of the message and a user-provided nonce. (With respect to this view- point, it is the responsibility of the user | not the encryption algorithm | to ensure, e.g., that nonces are chosen at random.) In this context, Rogaway defines a notion of security that, roughly speaking, guarantees semantic security as long as nonces never repeat. While this definition is somewhat similar to our own, we show in Section 3.1 that the notion considered by Rogaway is incomparable to the notion of CRA-security considered here; i.e., there are schemes satisfying his definition and not ours, and vice versa. We remark further that the motivations for our work and Rogaway's work are very different: as argued by Rogaway [15], nonce-based security is best understood as a usability requirement, whereas we are interested in examining a stronger attack model (within the conventional framework for encryption). Adversarial manipulation of a PRNG was mentioned as motivation for our work. While there has been prior work developing \forward-" and \backward- secure" pseudorandom number generators [4, 1, 8], simply composing such gen- erators with a standard CPA- or CCA-secure encryption scheme does not defend against the attacks considered here. The reason is that these prior works con- sider only adversaries that learn the internal state of the PRNG, whereas our notions consider stronger adversaries that may control the state of the PRNG. One can therefore view our notion of CRA-security as achieving a strong variant of backward- and forward-security with respect to the underlying source of ran- domness. In other words, our definitions guarantee that a plaintext encrypted using high-quality randomness is protected even against adversaries that can control the source after the present plaintext is encrypted (i.e., strong forward- security), or that have controlled it in the past (i.e., strong backward-security). Work of McInnes and Pinkas [13] and Dodis et al. [7, 5] has also considered the security of encryption when truly random coins are not available to the sender. Although these works are superficially related to our own, the problems being considered | as well as the motivation | are very different. The work of [13, 7, 5] is unwilling to assume any truly random coins, even during generation of the secret key, and is interested in exploring what can be achieved in such an extreme setting. For this reason, they are primarily concerned with information- theoretic security (although later work [6, 5] treats computational security) and do not consider security against chosen-plaintext attacks at all. In this work, in contrast, we are willing to assume that truly random coins exist (e.g., during key generation and, at least once, when encrypting), but are concerned that the adversary may periodically be able to tamper with the honest user's ability to generate true random coins. We are then interested in the question of whether the analogue of CPA-security is achievable. 2 Notation and Preliminaries We use standard cryptographic notation and terminology. We use ha; bi or akb interchangeably for the concatenation of strings a and b. We let Func[n; m] denote the set of all functions from f0; 1gn to f0; 1gm, and let Perm[n; n] denote the set of all permutations over f0; 1gn. A function f : N ! N is negligible in k, if for every polynomial p and sufficiently large k, f(k) < 1=p(k). We write negl(k) and poly(k) to refer to unspecified negligible and polynomial functions in k. If O is a probabilistic algorithm, then O(x) denotes an execution of O on input x with uniformly chosen random coins, and O(x; r) denotes an execution of O on input x with random coins r. Given a probabilistic algorithm O, we will consider adversaries A given access to an oracle that on input hx; ri re- turns O(x; r) (this is different from the usual case where A is given access to an oracle that on input x returns O(x; r) for uniformly chosen random coins r). 2.1 Cryptographic Tools We use standard cryptographic tools which are reviewed here to fix notation. Pseudo-random functions. Let F be an efficiently-computable keyed func- `in(k) `out(k) tion, where for a fixed key K of length k we have FK : f0; 1g ! f0; 1g with `in; `out polynomial in k.