# Designing a key expander out of ciphers

Is it possible to compose or combine $n$ ciphers ($cipher_0, cipher_1, ... cipher_n$) in such a way that they generate $n$ ciphertexts from the same key, $k$, and that recovering the key, $k$, from the $n$ ciphertexts is equivalent to breaking all $n$ ciphers.

Note that the size of the key, $k$, is the same as the size of the $n$ ciphertexts.

$$||k|| = ||cipher_i(k, k)||$$ $$n \times |k| = ||cipher_0(k, k)||+||cipher_1(k, k)||+...+||cipher_n(k, k)||$$

I'm not asking about finding the pre-image of the $n$ ciphertexts, but rather the original key that was used.

This is related to this answer ( Changing algorithms during encryption ).

-
Hmm, a simple way would be to split the key in $n$ parts (e.g. the original key would have length $\sum k_n$), and use each part in one cipher. Not sure if this counts :-) – Paŭlo Ebermann Sep 20 '11 at 20:57
@PaŭloEbermann Well played. Question edited to prevent cheating. – Ethan Heilman Sep 20 '11 at 21:03

I believe we can do it far more simply than the above protocol by using a Combinatorial design technique called Orthogonal Arrays and even by Resilient functions. All we need to do is a simple Resilient function. For definition, we can write as:

Let $t,m,$ and $n$ be positive integers ($t < n$) and suppose $f \in \mathcal{B}_{n,m}$, the set of all functions that maps from $\mathbb{F}_q^n$ to $\mathbb{F}_q^m$. A function $f$ is $t$-resilient if for every $t$ subset of $\{ 1, \ldots , n \}$ and for every choice $z_j \in \mathbb{F}_q$, and every outputs of $f$, we have that

$$\mathbb{P}[f(x_1, \ldots , x_n) = (y_1, \ldots, y_m) | x_{i_j}=z_j, 1 \leq j \leq t] = 2^{-m},$$ then $f$ is $(n,m,t)$-resilient function.

In other words, even if we fix or chose adaptively $t$ inputs, the output is uniformly distributed given that $n-t$ inputs are chosen uniformly. There are known constructions for $(n,1,n-1)$-resilient functions.

Using this understanding and based on that indistinguishability definition of secure ciphertext, we can assume that at least one of the ciphertext is uniform. The idea is to apply $f$ on the ciphertexts, get an output in $\mathbb{F}_q$. Let us call this $y$. We can encrypt $y$ once, twice, thrice, and up until $n$ times to get $n$ keys. You can prove the security of the scheme based on the uniformity of $(n,1,n-1)$-resilient functions and a hybrid type argument.

Please let me know if you find flaw in this protocol. Of course, you can use MAC or your favorite authentication scheme if you like.

-
I'm not sure I understand, you apply the resilient function $f$ to 'the ciphertexts' but how are these ciphertexts being generated? How are you encrypting $y$, are you using all the ciphers? It's interesting (learning about resilient functions now) but I don't fully understand all the steps. – Ethan Heilman Jan 26 '12 at 20:44
You reformulated the question like that. Alice is given $n$ ciphertexts, one of them is secure, and hence the corresponding encryption scheme satisfies the indistinguishability definition of the security, hence the output of that encryption scheme is uniform, giving me the $1$ variable to construct the $n-1$ resilient function. Once $y$ is computed, Alice keeps on re-encrypting $y$ using the key, $k$, $i+1$ times to get $i^{th}$ key. Now on the part of Bob, since he knows $k$, he can generate the keys in decrypting the $n^{th}$ encryption that corresponds to $n^{th}$ key and so on. – Jalaj Jan 26 '12 at 22:01
Lets see if I understand. We generate $n$ ciphertexts by encrypting the key $k$ with itself over all the ciphers $cipher_{0}(k,k) .. cipher_{n}(k,k)$. We use these $n$ ciphertexts to generate a function $\mathbb{F}_q$ which we use to generate the value $y$. If I got all that correct, my next question is how to you encrypt $y$ under $k$. Do you use all the ciphers? How do you compose the ciphers? Do you break $y$ into $n$ pieces and encrypt each one of the pieces? – Ethan Heilman Jan 27 '12 at 0:45
My idea is to use the same resilient function to encrypt as well. Since the output of the resilient function is uniform even if $n-1$ input are fixed, we can use $y$ as one of the uniformly randomly picked value and rest of the value some fixed $IV$, just like hash function. Once we do this, we get two random values. We can use a $n,1,n-2$ or the same old resilient function with $y$ and last iteration output as the randomly chosen input and rest as $IV$ and so on. The resilient function is a public knowledge, so it can act as the encryption scheme. I see it is like iterated hash function! – Jalaj Jan 27 '12 at 1:00
This scheme is secure as long as you never use the same keys with a different set of ciphers. For instance using $k$ with ciphers: $A, B, C$ and then reusing $k$ with ciphers: $E, B, C$ (consider the case where $E$ produces exactly the same output as $A$ except for the last bit). Given two nearly identical sets of ciphertexts mapped through $f$ we should be able to learn some bits of the key $k$, as long as $f$ is not a random oracle (I am still not completely familiar with resilient functions, but if resilient function are not vulnerable in this way they are as powerful as Random Oracles). – Ethan Heilman Jan 30 '12 at 14:09

I think you can just generate all the plaintexts but one randomly, and make the last one the XOR of the key and the other plaintexts. To recover the key, one must recover all the plaintexts and XOR them. Even every plaintext but one gives you no information about the key.

-
This works. Alternatively, any all-or-nothing transform could be used, such as OAEP, but then that transform could be attacked. XOR is only weak in the sense that knowing the first byte of every plaintext reveals the first byte of the key - but hopefully the ciphers used are not weak like this. – Nakedible Sep 21 '11 at 6:57
It seems any secure hash algorithm will do then. To form each generated key: take the master key, append the index number of the key to be generated, run it through all the ciphers concatenating their outputs, and then securely hash the concatenated output of all the ciphers. – David Schwartz Sep 21 '11 at 18:26
If a hash algorithm is used to expand the key, then that hash algorithm can be attacked to gain knowledge of all the keys - in effect, if your hash algorithm isn't stronger than all the ciphers, the hash algorithm becomes the weakest link. Alternatively, if your hash algorithm is stronger than all the ciphers, you can just use the hash algorithm for encryption (although that is somewhat non-trivial to do securely if your hash algorithm isn't really good). – Nakedible Sep 21 '11 at 19:14
You can use all the ciphers, in series, as the hash algorithm. – David Schwartz Sep 21 '11 at 19:15
Yes, that's better. (Otherwise, if the last cipher always outputs all zeroes, for example, you're screwed.) – David Schwartz Sep 21 '11 at 20:32

Reformulation of the question: Alice is given $n$ ciphers ( $cipher_0,cipher_1,...cipher_n$) to build a key expander, one of these ciphers is a secure cipher (random permutation) and the rest ($n-1$ of them) can be maliciously controlled by Eve. Alice are unable to inspect these ciphers or their input/outputs to determine which one is secure. Alice and Bob both know a key, $k$, they wish to derive a series of generated keys $k'_0, ... k'_n$ from $k$ using the ciphers.

Eve should not be able to figure out $k$ from the generated keys $k'_0, ... k'_n$ without having to break all $n$ of the ciphers.

It seems that Eve can do two malicious things in designing her ciphers (if I'm leaving something out please let me know):

1. Eve can use the trivial permutation for her ciphers and thereby leak the key. For example: $k = cipher_{eve}(k, k)$.

2. Eve can reduce the entropy of the output of the cipher. For example if she knows the root of our construction is $cipher_{eve}(k, k)$ where $k$ is the key we are expanding, she can set $cipher_{eve}$ to always return all $0$'s when the plaintext and the key are equal. While this won't allow her to guess the key it might allow her to reduce the entropy of the expanded keys ( $k'_0, ... k'_n$ ).

• Consider the case $n = 1$: The construction $$k'_0 = cipher_0(k, k)$$ is secure. That is, finding the key from $k$ from $k'_0, ... k'_n$ is not possible without guessing $k$ or breaking the cipher, $cipher_0$. Since by our definition $cipher_0$ must be secure, this solution is also secure of $n = 1$.

• Consider the case $n = 2$: This case is much more difficult because it introduces a maliciously designed cipher $cipher_{eve}$. The construction

$$k'_0 = cipher_1( cipher_0(k+1, k+1) \oplus k, cipher_0(k, k) )$$ $$k'_1 = cipher_1( cipher_0(k+2, k+2) \oplus k, cipher_0(k, k) )$$

is secure. We can show this by considering both cases:

1. $cipher_0$ is secure and $cipher_1 = cipher_{eve}$: Because $cipher_1$ doesn't know the value of $k$ it is unable to leak using the trivial permutation. Nor can $cipher_1$ reduce the entropy because the inputs to $cipher_1$ are random and different. Thus if $cipher_0$ is secure this construction is secure.

2. $cipher_1$ is secure and $cipher_0 = cipher_{eve}$: All outputs from $cipher_0$ will be securely encrypted by $cipher_1$ so $cipher_0$ can't leak the value of $k$. $cipher_0$ can reduce the entropy of it's output ($0^m = cipher_0(k, k)$), but this will not effect the entropy of the input to $cipher_1$ since the entropy of $k$ is preserved by xoring it into the input to $cipher_1$. Thus if $cipher_1$ is secure this construction is secure.

Therefore if $cipher_0$ or $cipher_1$ is secure the secrecy of $k$ is preserved.

The case $n = 2$ also provides the construction for $n > 2$, since the value of $k$ can't be leaked past the secure cipher and the insecure ciphers can't reduce the entropy of the generated keys $k'_0, ... k'_n$.

Does anyone know if this is a known result?

EDIT: I was thinking about this some more and found a serious weakness. Consider the case in which $cipher_0 = cipher_{eve}$ and $cipher_{eve}$ emits $k$ with probability of $0.5$ when the key is equal to the plaintext.

$$pr( cipher_{eve}(a, b) = k | a = b ) = 0.5$$

Thus half the time $cipher_1$ will get a key of $0$. Knowing the key that $cipher_1$ gets allows you to recover the original key by decrypting the output of $cipher_1$.

$$k'_0 = cipher_1( k \oplus k, cipher_0(k, k) )$$ $$k'_0 = cipher_1( 0, cipher_0(k, k) )$$ $$cipher_0(k, k) = cipher_1.decrypt(0, k'_0)$$

And since $cipher_0 = cipher_{eve}$ we can invert it half the time and get k.

-
If cipher_1 is just xor, all the k primes will be exactly k. Or am I missing something? – BCS Jan 25 '12 at 16:55
+1 Good catch! You are correct and a lesson for us all about hobby cipher schemes. Especially troubling because I remember worrying about this exact case when I was coming up with this. I believe I have fixed it now(new readers can see look at the old revision to see my change), but I will be thinking this over to see if I missed anything. – Ethan Heilman Jan 25 '12 at 18:18
Yup, that looks correct to me un-trained eyes. OTOH the programmer in me sees the risk that comes from not having the second k change as well: if you somehow end up with an off-by-one error and generate "k prime -1", you are back where you started. – BCS Jan 25 '12 at 20:08
I see your point, I think that what you describe is what happened when I was copying the formulas from my notes. An implementation should probably have some test cases to check for that sort of mistake. – Ethan Heilman Jan 25 '12 at 20:49
Edited post to add I just found a weakness in this. – Ethan Heilman Jul 24 '12 at 18:21