Indeterminate Message Validity as a Noise Source in High Volume Channels Question Rephrased:

Does randomisation of valid and invalid messages in a high volume channel add security?

Scheme: valid messages are identified by a pre-shared random number sequence and noise- large volumes of random messages which can be encrypted by a large range of dummy keys- are ignored by the receiver but can be used to consume the resources of an attacker regardless of the attack mechanism/approach.

Any such arrangement using high volumes of noise must allow the receiver to ID valid messages. A truly random pre-shared number list would appear to be superior to any other sequencing.
Please take this with all respect and decency you deserve, but you're absolutely wasting your time with this elaborate scheme :-) What you propose is a protection system for true OTP transmissions. The OTP doesn't need protection.  We know this and I'm not going to further champion its virtues.  But I will put some numbers to my reasoning:-


Assume what I call computer Morse code (characters A-Z, 0-9, space, period).  That's a 38 character alphabet.
Also assume for comparison a 256 bit key for something like AES.
There is an answer here as to how much energy it would take to simply cycle through a 256 bit counter from a thermodynamics perspective. The answer quotes Bruce Schneier's back of the envelope assessment at needing  all the energy from a super nova (and more), which is quite a lot of batteries.
Using our computer Morse alphabet, 256 bits of entropy is equivalent to 49 characters.  That's a short message.
A more likely Twitter length message (160 characters) is 840 bits of entropy, or 2^840 permutations.
That would take many more super novae + even more batteries and it proves that it's impossible to brute force a Twitter length OTP message.
This is all based on having a good OTP generated with a good true random number generator made from physical components like cogs, diodes and wires.  Absolutely no cheating and using /dev/random and certainly not CryptGenRandom.


So don't bother making the NSA's life more difficult that it already is.

Where your system has merit though is channel masking.  The high and perhaps constant level of comms traffic obscures the time and number of real messages. This is standard counter intelligence against traffic analysis and chatter measurement as part of military communications intelligence.  Heavy stuff.

For no practical reason, this is a very recent super nova, lovingly named G1.9+0.3:-



and is more likely to reoccur than breaking a good OTP. Instead focus your effort on generating the OTP correctly.