# 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.

• Comments are not for extended discussion; this conversation has been moved to chat. – e-sushi Jun 28 '17 at 15:14

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.

• Thanks for your comment. Very insightful. What I don't understand is how channel masking can work without the sender and receiver having a common identification of valid messages already established? Unless they have telepath,y the receiver must KNOW what is a valid message in the message stream. If this is not truly randomised and agreed to apriori then it would seem to me that this is a weakness- especially in high volume channels. – Spencer Jun 26 '17 at 4:41
• How can channel masking work without a common means of msg ID? Unless randomised, this is a weakness- especially in high volume channels. I understand that a OTP is unbreakable but it consumes far more random numbers in its encryption than would be consumed by just identifying valid and invalid messages. Any prior exhanged OTP of random numbers for msg ID would last longer. Refreshing OTPs is always a security risk. Lastly, the encryption can be anything, not just OTPs. This would allow keys to change while still keeping valid mg randomisation intact. – Spencer Jun 26 '17 at 4:54