Provably Secure Public-Key Encryption for Length-Preserving Chaumian Mixes

Transcription

1 Technical Report TI-5/02 (9th August 2002) TU Darmstadt, Fachbereich Informatik Provably Secure Public-Key Encryption for Length-Preserving Chaumian Mixes Bodo Möller Technische Universität Darmstadt, Fachbereich Informatik Abstract. Mix chains as proposed by Chaum allow sending untraceable electronic without requiring trust in a single authority: messages are recursively public-key encrypted to multiple intermediates (mixes), each of which forwards the message after removing one layer of encryption. To conceal as much information as possible when using variable (source routed) chains, all messages passed to mixes should be of the same length; thus, message length should not decrease when a mix transforms an input message into the corresponding output message directed at the next mix in the chain. Chaum described an implementation for such length-preserving mixes, but it is not secure against active attacks. We show how to build practical cryptographically secure lengthpreserving mixes. The conventional definition of security against chosen ciphertext attacks is not applicable to length-preserving mixes; we give an appropriate definition and show that our construction achieves provable security. Keywords: Cryptographic r ers, chosen ciphertext attack security, public-key cryptosystems with length-expanding decryption 1 Introduction Chaum s mix concept [5] is intended to allow users to send untraceable electronic without having to trust a single authority. The idea is to use a number of intermediates such that it suffices for just one of these to be trustworthy in order to achieve untraceability. (The sender does not have to decide which particular intermediate he is willing to trust, he just must be convinced that at least one in a given list will behave as expected.) These intermediates, the mixes, are r ers accepting public-key encrypted input. Messages must be of a fixed size (shorter messages can be padded, longer messages can be split into multiple parts). To send a message, it is routed through a chain of mixes M 1,..., M n : the sender obtains the public key of each mix; then he recursively ( encrypts the message (including the address of the final recipient) yielding E M1 EM2 (... E Mn (payload)...) ) where E Mi denotes encryption with M i s public key, and sends the resulting ciphertext to mix M 1. (The public-key cryptosystem will typically be hybrid, i.e. involve use of symmetric-key cryptography for bulk data encryption.) Each mix removes the corresponding layer of encryption and 1

2 forwards the decrypted message to the next mix; thus mix M n will finally recover payload. Each mix is expected to collect a large batch of messages before forwarding the decryption results. The messages in the batch must be reordered (mixed) to prevent message tracing. It is important to prevent replay attacks a mix must not process the same message twice, or active adversaries would be able to trace messages by duplicating them at submission to cause multiple delivery. (Timestamps can be used to limit the timespan for which mixes have to remember which messages they have already processed; see [5] and [6].) Usually it is desireable to allow source routing, i.e. let senders choose mix chains on a per-message basis. This increases the flexibility of the whole scheme: senders can make use of new mixes that go into operation, and they can avoid mixes that appear not to work properly; in particular, they can avoid mixes that suppress messages (be it intentionally or because of technical problems). For source routing, in the recursively encrypted message, each layer must contain the address of the next mix in the chain so that each mix knows where to forward the message. A problem with the straightforward implementation of source routing is that messages will shrink as they proceed through the chain, not only because of the forwarding address for each layer that must be included, but also because public-key encryption increases message sizes. For optimal untraceability, we need length-preserving mixes: the messages that mixes receive should essentially look like the resulting messages that they forward to other mixes. A construction of length-preserving mixes is given in [5] (a variant of this is used in fielded systems [12]): mix messages consist of a fixed number of slots of a fixed size. The first slot is public-key encrypted so that it can be read the first mix in the chain. Besides control information directed at the respective mix (such as the address of the next mix in the chain or, in case of the last mix, the address of the final recipient), decryption yields a symmetric key that the mix uses to decrypt all the other slots. Then slots are shifted by one position: the decryption of the second slot becomes the new first slot, and so on. A new final slot is added consisting of random (garbage) data to obtain a mix message of the desired fixed length, which can the be forwarded to the next mix. On the way through the chain, each mix message consists of a number of slots with valid data followed by enough slots with garbage to fill all available slots; mixes are oblivious of how many slots contain valid data and how many are random. Each mix in the chain, when decrypting and shifting the slots, will decrypt the garbage slots already present and add a new final slot, thus increasing the number of random slots by one. We note that while the transformation of an incoming mix message to the corresponding outgoing mix message is lengthpreserving, the decryption step itself is actually length-expanding because some of the data obtained by decryption is control data directed at the current mix. The problem with this method for obtaining a hybrid public-key cryptosystem with length-expanding decryption is that it is not secure against active attacks: assume that an adversary controls at least one mix, and that all senders submit well-formed messages. Now when the victim submits a message, the ad- 2

3 versary can mark it by modifying one of the slots. This mark will persist as the message is forwarded through the mix chain: due to the decryption and slot shifting performed by each mix, the corresponding slot will essentially contain garbage. If the final mix is controlled by the adversary, the adversary may be able to notice the modification and thus break untraceability. To rule out such attacks, the hybrid public-key cryptosystem should provide security against adaptive chosen ciphertext attacks (CCA security): that is, it should be secure against an adversary who can request the decryption of arbitrary ciphertexts. In this paper, we present a secure and practical hybrid construction for length-preserving mixes, which is also more flexible than the slot-based approach. The standard notion of CCA security for public-key cryptosystems is not applicable to our hybrid public-key cryptosystem with length-expanding decryption because the encryption operation must be defined differently for our application: encryption cannot be treated as an atomic black-box operation that takes a plaintext and returns a ciphertext in this model, we cannot have lengthextending decryption. Rather, our encryption process first is input part of the desired ciphertext and determines a corresponding part of what will be the decryption result (it is this step that provides length expansion); then it is input the payload plaintext and finally outputs the complete ciphertext, which includes the portion requested in the first input. We describe the hybrid construction in section 2. Section 3 discusses appropriate security notions and gives a provable security result for the construction. This paper shows for the first time how to implement length-preserving mixes cryptographically secure against active attacks. We use many ideas and techniques described by Cramer and Shoup in [7], but adapt them to fit the new notions of security needed in the context of length-preserving mixes. 1.1 Notation Strings are binary, i.e. elements of {0, 1}. The concatenation of strings s and t is denoted s t. The length of string s is s. For s w, prefix w (s) denotes the string consisting of the leftmost w bits of s; thus, prefix s (s t) = s. Messages (plaintexts, ciphertexts) are strings. Algorithms are usually probabilistic (randomized). 2 A Construction for Length-Preserving Mixes Our construction allows much flexibility in the choice of cryptographic schemes, even in a single chain. The single parameter that must be fixed for all mixes is the desired mix message length l. Also it may be desireable to define a maximum length for the actual message payload, i.e. the part of the plaintext as recovered by the final mix that can be chosen by the sender: as a message proceeds through the mix chain, more and more of the data will be pseudo-random gibberish; the length of the useful part of the final plaintext reveals that chains leaving less 3

4 than this amount cannot have been used. The length n of the mix chain need not be fixed. For purposes of exposition, we number the mixes M 1,..., M n according to their position in the chain chosen by the sender (note that the same mix might appear multiple times in one chain). For each mix M i, the following must be defined and, with the exception of the secret key SK Mi, known to senders who want to use the mix: A key encapsulation mechanism and a key pair KEM Mi (PK Mi, SK Mi ) consisting of a public key PK Mi and a secret key SK Mi for this key encapsulation mechanism. A key encapsulation mechanism, similarly to a public-key encryption mechanism, provides an algorithm KEM Mi.Encrypt using the public key and an algorithm KEM Mi.Decrypt using the secret key. In contrast with public-key encryption, the first algorithm takes no input apart from the public key: KEM Mi.Encrypt(PK Mi ) generates a ciphertext K of a fixed length KEM Mi.CipherLen corresponding to a (pseudo-)random string K of a fixed length KEM Mi.OutLen and outputs the pair (K, K). Evaluation of KEM Mi.Decrypt(SK Mi, K) will return said string K. That is, ciphertext K encapsulates the random message K (which can be used as a key for symmetric-key cryptography). On arbitrary inputs K, the computation KEM Mi.Decrypt(SK Mi, K) may either return some string K or fail (return the special value invalid). Associated with key encapsulation mechanism KEM Mi is a key generation algorithm KEM Mi.KeyGen that returns appropriate key pairs (PK, SK). If M i is a correctly operating mix, its key pair (PK Mi, SK Mi ) has been generated by this algorithm. (Otherwise PK Mi may have been constructed differently; it might even be invalid in the sense that there is no corresponding secret key SK Mi that could be used for decryption.) Note that we use no explicit security parameter, so desired key sizes are implicit to KEM Mi.KeyGen. 4

5 One example of a key encapsulation mechanism is the Diffie-Hellman key exchange [8] with static keys for one party and ephemeral keys for the other party where the concatenation of the ephemeral public key with the common secret group element is hashed to obtain a symmetric key (cf. [1], [14]); KEM Mi.CipherLen can be kept particularly small for elliptic curve Diffie- Hellman using just x coordinates of points (see [11]). Specifications for various key encapsulation mechanisms can be found in [14]. A one-time message authentication code with key length and output length MAC Mi MAC Mi.KeyLen MAC Mi.OutLen. A one-time message authentication code specifies an efficient deterministic algorithm that takes as input a key K of length MAC Mi.KeyLen and a bit string s and returns a string MAC Mi (K, s) of length MAC Mi.OutLen. In our construction, MAC Mi will only be used for strings s of fixed length l KEM Mi.CipherLen MAC Mi.OutLen. Candidate one-time message authentication codes are UHASH [9] 1 and HMAC [2]. A pseudo-random bit string generator taking as input a key K of length STREAM Mi STREAM Mi.KeyLen and deterministically generating an output string STREAM Mi (K) of length STREAM Mi.OutLen. This will be used for an XOR-based stream cipher. A convenient example implementation is the so-called counter mode of a block cipher (the output sequence is the prefix of appropriate length of E K (0) E K (1) E K (2)... where E K denotes block cipher encryption using key K; see [3] and [10]). An integer PlainLen Mi specifying the length of the prefix of each decrypted message that is considered control data directed to mix M Mi and will not be forwarded. (This is the amount of message expansion: the decrypted message minus the prefix must be of size l because that is what will be sent to the next mix.) 1 UHASH is the combination of a key derivation function with an almost strongly universal hash function [15] and is the core of UMAC as specified in [9]. Note that the security arguments provided for the earlier version of UMAC in [4] are based on a different approach. 5

6 The parameters must fulfil the following conditions: 2.1 Encryption KEM Mi.CipherLen + MAC Mi.OutLen + PlainLen Mi < l (1) KEM Mi.OutLen = STREAM Mi.KeyLen + MAC Mi.KeyLen (2) STREAM Mi.OutLen = PlainLen Mi + l (3) We now describe encryption for sending a message through a chain M 1,..., M n. Let payload be the message of length payload = l (KEM Mi.CipherLen + MAC Mi.OutLen + PlainLen Mi ) (4) 1 i n (messages shorter than this maximum should be randomly padded on the right). For each i, let plain i be the control message of length PlainLen Mi directed to the respective mix. The encryption algorithm for these arguments is denoted or chain encrypt M1,...,M n (plain 1,..., plain n ; payload) chain encrypt M1,...,M n (plain 1,..., plain n ; payload; λ) where λ is the empty string. The algorithm is defined recursively. Let 1 i n, and let C i be a string of length C i = (KEM Mk.CipherLen + MAC Mk.OutLen + PlainLen Mk ) (5) 1 k<i (thus specifically C 1 = 0). Then algorithm works as follows: chain encrypt Mi,...,M n (plain i,..., plain n ; payload; C i ) 1. Use KEM Mi.Encrypt(PK Mi ) to generate a pair (K i, K i ). 2. Split K i in the form K i = K i,mac K i,stream such that K i,mac = MAC Mi.KeyLen (so K i,stream = STREAM Mi.KeyLen by (2)). 3. Compute STREAM Mi (K i,stream ) and split this string in the form stream i,l stream i,r such that the left part stream i,l is of length l C i KEM Mi.CipherLen MAC Mi.OutLen and the right part stream i,r accordingly, by (3), is of length C i + KEM Mi.CipherLen + MAC Mi.OutLen + PlainLen Mi. 6

7 4. If i = n (last mix), then by (4) and (5) it follows that stream n,l = PlainLen n + payload. In this case, set Otherwise, let C n = ( stream n,l (plain n payload) ) C n. C i+1 = stream i,r (C i 0 KEM M i.cipherlen+mac Mi.OutLen+PlainLen Mi ), by recursion compute and let x i = chain encrypt Mi+1,...,M n (plain i+1,..., plain n ; payload; C i+1 ), C i = ( stream i,l (plain i prefix streami,l PlainLen Mi (x i )) ) C i. 5. Compute M i = MAC i (K i,mac, C i ). 6. Return the ciphertext K i M i C i, which is of length l. Appendix A.1 illustrates a ciphertext generated by chain encrypt M1,...,M n. 2.2 Decryption The decryption algorithm for mix M i (1 i n) works as follows, given a length-l ciphertext K M C (split into its three components according to parameters KEM Mi.CipherLen = K and MAC Mi.OutLen = M ). We denote it mix decrypt Mi (K M C). Remember that M i in general is not aware of the mix chain used by the sender or even of its own position i in the chain. 1. Compute K = KEM Mi.Decrypt(SK Mi, K). If this computation fails, abort with an error (return invalid). 2. Split K in the form K = K MAC K STREAM such that K MAC = MAC Mi.KeyLen. 3. Compute M = MAC Mi (K MAC, C) and test whether M = M. If this is not the case, abort with an error (return invalid). 4. Compute the string of length STREAM Mi.OutLen. stream = STREAM Mi (K STREAM ) 7

8 5. Compute stream (C 0 KEM M i.cipherlen+mac Mi.OutLen+PlainLen Mi ) and split the resulting string in the form plain i P where plain i is of length PlainLen Mi 6. Return the pair (plain i, P ). (and thus, by (3), P is of length l). If this algorithm finishes without an error, plain i is a control message directed to the current mix, and P is the message to be forwarded to another mix or to the final recipient (as requested by the control message). It is straightforward to verify that for ciphertexts computed as chain encrypt M1,...,M n (plain 1,..., plain n ; payload), iterative decryption by mixes M 1,..., M n will indeed work without an error and recover the respective strings plain i and finally also the message payload concatenated with some (useless) extra data. Appendix A.2 illustrates decryption. 3 Provable Security The mix concept is intended to provide security when at least one mix can be trusted and behaves correctly. (However note that denial-of-service attacks by incorrectly operating mixes cannot be ruled out, the only option is to avoid mixes that appear to malfunction.) Thus we assume that some mix M i works as expected while all other mixes are controlled by the adversary and may not follow the protocol (also the cryptographic schemes KEM Mj, MAC Mj, and STREAM Mj associated with mixes M j, j i, might be not secure). This leaves only M i to be attacked: outer layers of encryption for mixes that appear before M i in a mix chain are easily removed by the adversary and thus are not relevant for security; and inner layers of encryption for mixes that appear after M i in a mix chain are involved in the encryption process chain encrypt Mi,...,M n (plain i,..., plain n ; payload; C i ) described in section 2.1, but cannot provide protection against the adversary. Section 3.1 shows how the security of the mix construction can be captured formally. We then provide security definitions for the underlying key encapsulation method (section 3.2), one-time message authentication code (section 3.3), and pseudo-random bit string generator (section 3.4). Finally, section 3.5 presents a security result that relates the security of the mix encryption scheme to the security of these cryptographic schemes: we will see that if the mix encryption scheme is not secure, then this is because one of the underlying cryptographic schemes is not secure. 8

9 3.1 Security of the Mix Encryption Scheme To show that our construction for length-preserving mixes is secure, we want to model an active adversary who is able to launch an adaptive chosen ciphertext attack (CCA). Due to the recursive nature of our encryption algorithm for mix chains, we cannot directly apply the usual CCA definitions for ordinary publickey encryption; we adapt the attack game described in [7, section 3.2] (which goes back to [13]) as follows to take into account the special properties of our construction: 1. The adversary queries a key generation oracle, which uses KEM Mi.KeyGen to compute a key pair (PK, SK) and responds with PK (and secretly stores SK). 2. The adversary makes a sequence of queries to a decryption oracle. Each query is an arbitrary string s of length l, and the oracle responds with mix decrypt Mi (s), using the secret key SK from step 1. That is, each oracle response is either a pair (plain, P ) where plain = PlainLen Mi and P = l, or the special value invalid. 3. The adversary uses an interactive encryption oracle as follows (compare with the encryption algorithm in section 2.1): First the adversary submits some string C i subject only to the condition that 0 C i < l KEM Mi.CipherLen MAC Mi.OutLen. The interactive encryption oracle uses KEM Mi.Encrypt(PK) to generate a pair (K oracle, K oracle ) and splits K oracle in the form K oracle = K MAC K STREAM such that K MAC = MAC Mi.KeyLen; it computes STREAM Mi (K STREAM ) and splits the resulting string stream in the form stream = stream L stream R such that stream L = l C i KEM Mi.CipherLen MAC Mi.OutLen; and it computes C i+1 = stream R (C i 0 KEM M i.cipherlen+mac Mi.OutLen+PlainLen Mi ) and sends C i+1 to the adversary. The adversary submits a pair of strings (m 0, m 1 ) satisfying m 0 = m 1 = l C i KEM Mi.CipherLen MAC Mi.OutLen. 9

10 The interactive encryption oracle chooses a uniformly random bit b {0, 1}, determines C = (stream L m b ) C i and and responds with M = MAC Mi (K MAC, C i ), K oracle M C. 4. The adversary again makes a sequence of queries to a decryption oracle as in step 2, except that this time the decryption oracle refuses being asked for the challenge ciphertext K oracle M C from step 3 (it returns invalid for this case). 5. The adversary outputs a bit b {0, 1}. The bit b output by the adversary is its guess for the value of b. The essential difference to the attack game for ordinary public-key encryption is that we have made the encryption oracle interactive to reflect the recursiveness of the encryption algorithm for mix chains, where encryption to mixes later in the chain than M i can have potentially arbitrary effects on a large part of the plaintext. Let A be any adversary (interactive probabilistic algorithm with bounded runtime) in the above attack game. Its CCA advantage against M i s instantiation of the mix encryption scheme is AdvCCA Mi,A = Pr [ b ] ] = 1 b = 1 Pr [ b = 1 b = Security of the Key Encapsulation Mechanism CCA security for the key encryption mechanism KEM Mi is defined through the following attack game (cf. [7, section 7.1.2]): 1. The adversary queries a key generation oracle, which uses KEM Mi.KeyGen to compute a key pair (PK, SK) and responds with PK. 2. The adversary makes a sequence of queries to a decryption oracle. Each query is an arbitrary string s of length KEM Mi.CipherLen; the oracle responds with KEM Mi.Decrypt(SK, s). Thus each oracle response is either a string of length KEM Mi.OutLen or the special value invalid. 3. The adversary queries an encryption oracle, which works as follows: it uses KEM Mi.Encrypt(PK) to obtain a pair (K 0, K oracle ), it generates a uniformly randomly string K 1 such that K 0 = K 1, chooses a uniformly random bit b KEM {0, 1}, and responds with (K bkem, K oracle ). 4. The adversary again makes a sequence of queries to a decryption oracle as in step 2, but this time the oracle refuses the specific query K oracle and responds invalid in this case. 10

11 5. The adversary outputs a bit b KEM {0, 1}. The CCA advantage of an adversary A 1 (an interactive probabilistic algorithm with bounded runtime) against KEM Mi in this attack game is AdvCCA KEMMi,A 1 = Pr [ bkem = 1 b KEM = 1 ] Pr [ bkem = 1 b KEM = 0 ]. 3.3 Security of the One-Time Message Authentication Code To define the security of MAC Mi, we use the following attack game (cf. [7, section 7.2.2]: 1. The adversary submits a string s (which for our purposes may be assumed to be of fixed length l KEM Mi.CipherLen MAC Mi.OutLen) to an oracle. The oracle generates a uniformly random string K of length MAC Mi.KeyLen and responds with MAC Mi (K, s). 2. The adversary outputs a list (s 1, t 1 ), (s 2, t 2 ),..., (s m, t m ) of pairs of string. An adversary A 2 again is an interactive probabilistic algorithm with bounded runtime; the runtime bound implies a bound on the list length m. We say that adversary A 2 has produced a forgery if s k s and MAC Mi (K, s k ) = t k for some k (1 k m). Its advantage against MAC Mi, denoted AdvForge MACMi,A 2, is the probability that it produces a forgery in the above game. 3.4 Security of the Pseudo-Random Bit String Generator To define the security of STREAM Mi, we use the following attack game: 1. The adversary queries an oracle. The oracle generates a uniformly random string K of length STREAM Mi.KeyLen, computes stream 0 = STREAM Mi (K), generates a uniformly random string stream 1 with stream 0 = stream 1, chooses a uniformly random bit b STREAM {0, 1}, and responds with stream b. 2. The adversary outputs a bit b STREAM {0, 1}. The advantage of an adversary A 3 (again an interactive probabilistic algorithm with bounded runtime) against STREAM Mi is Adv STREAMMi,A 3 = Pr [ bstream ] 1 = b STREAM Security Result Let A be an adversary A against the mix encryption scheme attacking a mix M i as described in section 3.1. It can be shown that there are adversaries A 1, A 2, A 3 against KEM Mi, MAC Mi, STREAM Mi all having essentially the same runtime as A such that AdvCCA Mi,A 2 (AdvCCA KEMMi,A 1 + AdvForge MACMi,A 2 + Adv STREAMMi,A 3 ). The proof uses standard techniques; details can be found in appendix B. 11

12 References 1. Abdalla, M., Bellare, M., and Rogaway, P. DHAES: An encryption scheme based on the Diffie-Hellman problem. Submission to IEEE P1363a Bellare, M., Canetti, R., and Krawczyk, H. Keying hash functions for message authentication. In Advances in Cryptology CRYPTO 96 (1996), N. Koblitz, Ed., vol of Lecture Notes in Computer Science, pp Bellare, M., Desai, A., Jokipii, E., and Rogaway, P. A concrete security treatment of symmetric encryption. In 38th Annual Symposium on Foundations of Computer Science (FOCS 97) (1997), IEEE Computer Society, pp Black, J., Halevi, S., Krawczyk, H., Krovetz, T., and Rogaway, P. UMAC: Fast and secure message authentication. In Advances in Cryptology CRYPTO 99 (1999), M. Wiener, Ed., vol of Lecture Notes in Computer Science, pp Chaum, D. Untraceable electronic mail, return addresses, and digital pseudonyms. Communications of the ACM 24 (1981), Cottrell, L. Mixmaster & r er attacks. r er/r er-essay.html, Cramer, R., and Shoup, V. Design and analysis of practical public-key encryption schemes secure against adaptive chosen ciphertext attack. Manuscript, Diffie, W., and Hellman, M. E. New directions in cryptography. IEEE Transactions on Information Theory 22, 6 (1976), Krovetz, T., Black, J., Halevi, S., Hevia, A., Krawczyk, H., and Rogaway, P. UMAC: Message authentication code using universal hashing. Internet-Draft draft-krovetz-umac-01.txt, ~rogaway/umac/, Lipmaa, H., Rogaway, P., and Wagner, D. Comments to NIST concerning AES modes of operation: CTR-mode encryption. modes/workshop1/papers/lipmaa-ctr.pdf, Miller, V. S. Use of elliptic curves in cryptography. In Advances in Cryptology CRYPTO 85 (1986), H. C. Williams, Ed., vol. 218 of Lecture Notes in Computer Science, pp Mixmaster anonymous r er software. mixmaster/. 13. Rackoff, C. W., and Simon, D. R. Non-interactive zero-knowledge proof of knowledge and chosen ciphertext attack. In Advances in Cryptology CRYPTO 91 (1992), J. Feigenbaum, Ed., vol. 576 of Lecture Notes in Computer Science, pp Shoup, V. A proposal for an ISO standard for public key encryption. Version 2.1, December 20, Wegman, M. N., and Carter, J. L. New hash functions and their use in authentication and set equality. Journal of Computer and System Sciences 22 (1981),

13 A Illustrations A.1 Encryption We depict a ciphertext generated by the encryption algorithm chain encrypt M1,M 2,M 3 (plain 1, plain 2, plain 3 ; payload) as described in section 2.1. In the illustration, we have concatenation horizontally and XOR vertically (i.e. boxes in the same row represent bit strings that are concatenated, and the ciphertext is the XOR of the multiple rows shown). plain 1 K 2 M 2 stream 2,L K 1 M 1 stream 1,L plain 3 payload plain 2 K 3 M 3 stream 3,L A.2 Decryption The result obtained by mix M 1 when applying the decryption algorithm from section 2.2 to the ciphertext from appendix A.1 is composed as follows: plain 3 payload plain 2 K 3 M 3 stream 3,L plain 1 K 2 M 2 stream 2,L stream 1,R The string plain 1 is directed to M 1. The remainder of the decryption result is a ciphertext that should be forwarded to the next mix in the chain, M 2, which will then obtain the following result: plain 3 payload plain 2 K 3 M 3 stream 3,L stream 1,R stream 2,R Similarly, mix M 3 will obtain the following final decryption result: plain 3 payload stream 1,R stream 2,R stream 3,R 13

14 B Security Proof We prove the security result for the mix encryption scheme given in section 3.5. Let G 0 denote the attack game from section 3.1. We will modify it in multiple steps, essentially disabling the underlying cryptographic schemes (key encryption method, one-time message authentication code, and pseudo-random bit string generator) one after another. G 1 is like G 0 except that a uniformly random string is used for K oracle, whereas K oracle is still generated by KEM Mi.Encrypt(PK). In the decryption oracle, K is substituted whenever KEM Mi.Decrypt(SK, K oracle ) would have to be computed. G 2 is like G 1 except that the decryption oracle always responds with invalid when faced with any query prefixed with string K oracle. (This applies to both step 2 and step 4 in section 3.1. Thus, the invocation of KEM Mi.Encrypt(PK) to generate (K oracle, K oracle ) must be advanced from step 3 to an earlier step; this is only a descriptive change, it does not affect the behaviour observed by the adversary.) G 3 is like G 2 except that the interactive encryption oracle uses a uniformly random string stream instead of computing STREAM Mi (K STREAM ). Now we consider an adversary A as in section 3.1, exposed to these different attack games] G x, 0 x 3, and look at the respective success probabilities Pr Gx [ b = b. Based on A, adversaries A1, A 2, A 3 against KEM Mi, MAC Mi, STREAM Mi will be built all having essentially the same runtime as A. A 1 attacks KEM Mi as follows (cf. section 3.2). At first, it generates b {0, 1} uniformly at random. Then, it runs the adversary A; when A queries its decryption oracle, A 1 uses its own decryption oracle to perform the decryption algorithm from section 2.2, and when A queries its encryption oracle, A 1 queries its own encryption oracle to obtain a pair (K oracle, K oracle ) and performs step 3 from section 3.1 using this pair and the pregenerated bit b. Finally, when A outputs its bit b, A 1 outputs 1 if b = b and 0 otherwise. Observe that ] ] Pr G1 [ b = b Pr G0 [ b = b = AdvCCAKEMMi,A 1 (G 0 corresponds to b KEM = 0, G 1 corresponds to b KEM = 1 in section 3.2). A 2 attacks MAC Mi as follows (cf. section 3.3). At first, it generates b {0, 1} and a string K oracle of length KEM Mi.OutLen uniformly at random. Then, it runs the adversary A, playing the roles of the key generation oracle, decryption oracle, and interactive encryption oracle, substituting the pregenerated string K oracle and the pregenerated bit b in step 3 of section 3.1. Whenever A submits a query K M C to the decryption oracle, A 2 adds the pair (C, M) to its own output (A s final output bit b is ignored). Observe that ] ] Pr G2 [ b = b Pr G1 [ b = b AdvForgeMACMi,A 2 (G 2 behaves differently from G 1 only if a forgery has been produced). 14

15 A 3 attacks STREAM Mi as follows (cf. section 3.4). First, it generates b {0, 1} and a string K oracle of length KEM Mi.OutLen uniformly at random. Then, it runs the adversary A, playing the roles of the key generation oracle, decryption oracle, and interactive encryption oracle, substituting the pregenerated string K oracle and the pregenerated bit b in step 3 of section 3.1. When A outputs its bit b, A 3 outputs 1 if b = b and 0 otherwise. Observe that ] ] Pr G3 [ b = b Pr G2 [ b = b = AdvSTREAMMi,A 3 (G 2 corresponds to b STREAM = 0, G 3 corresponds to b STREAM = 1 in section 3.4). ] Finally observe that Pr G3 [ b = b = 1 2. From this we obtain the inequality AdvCCA Mi,A = Pr ] G 0 [ b = b = 2 1 x 3 ( Pr Gx [ b = b ] Pr Gx 1 [ b = b ] ) 2 (AdvCCA KEMMi,A 1 + AdvForge MACMi,A 2 + Adv STREAMMi,A 3 ), which concludes our security proof. 15