Two-timing a one-time pad Is a one-time pad still breakable on a depth of 2+ if the plaintext is completely random?

I'm assuming this idea is wrong, mostly because it occurred to me, but let me walk you through my logic so you can concisely correct me:


A one-time pad is unbreakable on a depth of 1 because a comprehensive
brute-force attack will yield numerous reasonable plaintexts.
Upon a depth of 2 or more (e.g., the same pad used with multiple
plaintext messages) it becomes breakable:

Brute-forcing message $A$ may result in (say) 10 plaintexts
Brute-forcing message $B_n$ may result in 10 plaintexts each
The key that commonly results in valid plaintexts is probably the one-time pad used.

If the plaintext is completely random, then this attack won't work, as there is no way to discriminate between "plaintext output" and incorrect outputs.


I was thinking of ways to pass encryption keys and IVs - which, if properly generated, should be very random data - between two systems.  Let's presume they have a trusted channel by which they can exchange the one-time pad, but wish to use an untrusted channel for exchanging more voluminous data.  They can use symmetric encryption to protect data across the untrusted channel if they have away to agree upon the keys used for the symmetric encryption.  If a one-time pad could be used to securely exchange symmetric keys across that untrusted channel, then the sparse use of the trusted channel (exchanging the one-time password) could enable encryption across the untrusted channel.

Would this, instead of a one-time pad, be a shared secret? A key derivation function?

Some "please don't beat me up" caveats:


Yes, I realize this sounds like I'm breaking the "never invent a new cryptosystem" rule, and I realize the importance of that rule.  Rather, I'm using this as a gedankenexperiment to understand encryption better, and/or as a way of identifying an existing model that describes what I'm suggesting.
Yes, I realize SSL is the appropriate model for what I'm suggesting - the certificate exchange and handshaking is the "trusted channel", enabling symmetric encryption of the general data over the "untrusted channel".  I have reason to contemplate lighter-weight solutions.


I humbly appreciate any edification you can give me.
The scheme as you describe it in itself may be secure in some (especially) theoretical environment.
However, I don't suggest to use it, because any attempt to use of values passed between the peers can possibly undermine the security of the scheme as can e.g. insecure RNGs.

I have expressed a few concerns below.



I'm bit concerned about calling the scheme OTP anything, because this this is not OTP. A comment from daniel already mentioned when this practice is secure:

As long as you have after each use, n+1 unknowns on n equations, that's the preshared value plus each key value, seems hard to break (or impossible). Another thing is if it's advisable to use such a protocol for other reasons.

This was in the question:


  I was thinking of ways to pass encryption keys and IVs - which, if properly generated, should be very random data - between two systems.


What do you do with these keys and IVs? Consider they are for instance, used to encrypt data. Also suppose the adversary gets hands on ciphertext and (partial) plaintext processed with these encryption keys (unknown to adversary) and IVs:


The block cipher modes of operation (generally) do not protect IV from disclosure. This is because IV should be value unpredictable by the attacker before it is used. It may be, however, possible for attacker to determine the used IV afterwards; occasionally even pretty easily.
The adversary can use computational attacks the keys instead of information theoretic attacks (like against OTP. This may not be great deal, as for many algorithms keys are pretty hard to break).


Example of foul play

I decided to write an example of foul play, based on my understanding of the scenario written. It is not illustrated very clearly in the question what are the possible uses of communicated values, but this explanation tries to capitalize my point that using the exchanged values easily causes security issues. It is possible the example as-is does not apply here.

Assume that the Key+IV secured with multi time pad is used to do AES-CBC. Also assume that each Key+IV is "secured" with the same pad. The attacker can alter data messages sent (known as $M_i$ below).

We get for first keys and IVs (assuming this scheme uses "XOR" operation), A is multiply used pad:


$M_1 = A \oplus (Key_{1} || IV_{1})$
$M_2 = A \oplus (Key_{2} || IV_{2})$


The attacker may affect contents of $Key_{1}$ and $Key_{2}$. It may be possible to e.g. set keys and IVs to be the same for two different uses. (By replacing $M_2$ with $M_1$.)

Some other concerns


  Let's presume they have a trusted channel by which they can exchange the one-time pad, but wish to use an untrusted channel for exchanging more voluminous data. 


How much faster your untrusted channel is than trusted channel, i.e. how many times you intent to reuse "OTP"?

Where do you get the "plaintext stream" containing passwords and IVs? It is common that random number generators do not provide completely i.i.d. as is required by the scheme you describe.

If you have "OTP" that is kept scret and you use it multiple times to pass secret, this actually becomes some sort of secret sharing scheme. You should examine them to understand how to use them correctly.