1
$\begingroup$

I encrypt 2 random keys with the same 'one' time pad. You can get both encrypted keys. You don't know anything besides the size.

Is there a way to attack the two time pad in this scenario?

And what if I would encrypt 1000 random keys. is there a way to attack the 'one' time pad?

PS. I have read a lot of posts about plain text attacks and language analysis which both certainly don't apply here.

Improve this question
$\endgroup$
1
  • $\begingroup$ possible duplicate of this and this $\endgroup$
    – mikeazo
    Apr 28 '15 at 14:50
5
$\begingroup$

At least, doing the goof of reusing the OTP makes one vulnerable to disclosure of any of the key, which trivially reveals all the others.

For the rest, the consequences depends heavilly on what the keys are intended for. If the keys are intended for a block cipher that is secure including under related-key attack (as AES almost is), then there is not consequence beyond the aforementioned.

But in other cases the goof can be damaging, even disastrous. Simple example of the worse: the two random keys enciphered under two-times Pad are really random half-keys, intended to be held separately and combined by XOR to form a full key when needed (which is a simple and most common form of secret sharing with 2-out-of-2 parameterization); with the goof, the full key is the XOR of the ciphertexts for the two half-keys, thus is compromised, even though the individual half-keys remain confidential.

There is a spectrum in-between if the keys are for ciphers with poor security, especially under related-key attacks. In particular, if there are many keys enciphered under many-times pad, the goof allows the attacker to effortlessly pinpoint a key pair with much lower Hamming distance than average, and that pair might become the basis of a cryptanalysis (e.g. from ciphertexts for known plaintexts enciphered under both keys).

Improve this answer
$\endgroup$
2
$\begingroup$

Let's just consider keys of bitlength 1, it works like that for any length.

  • We have $k_1$ and $k_2$, the 2 random keys.
  • And we have $k_3$, the OTP key.
  • And then we give $x_1 = k_1 \oplus k_3$ and $x_2 = k_2 \oplus k_3$ to the attacker

How can you attack the OTP? You can't. However, you don't need it. Because $x_1$ and $x_2$ quite obviously reveal a lot about the things you wanted to hide in the first place:

$$x_1 \oplus x_2 = k_1 \oplus k_2$$

So if their "encryptions" are equal, then the keys are equal. Without knowing the "encrypted" keys, there are 4 possibilities ($k_1,k_2 \in \{0,1\}$), and then you reduce it to 2 possibilities (which ones depend on $x_1$ equal to $x_2$ or not).

Yes, this is bad. Over $n$ bit keys, instead of having $2^{2n}$ possibilities for both keys, you only have $2^n$. And you have to store 3 instead of 2 keys.

Improve this answer
$\endgroup$
2
  • $\begingroup$ so essentially what you are telling me: if i encrypt two 128 bit keys and someone can actually brute force one of the keys he will be able to get the other one? that does not seem like a big problem. $\endgroup$
    – yamm
    Apr 28 '15 at 14:16
  • $\begingroup$ @yamm, it also tells you that if you encrypt two 128 bit keys and the attacker is able to learn bits on one (say through a side channel attack), they know bits on the other. This is significant because say one key is used near the attacker (that is how they have access to the side channel) and the other key is used on the other side of the world. That said, security is all about tradeoffs, so this is nothing new. The real question is what do you really gain by doing this as opposed to some other method that does not have this "feature"? $\endgroup$
    – mikeazo
    Apr 28 '15 at 14:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.