Does High Frequency Randomisation of valid and dummy messages in a high volume channel add security?

Question

This was originally posed as this question: "Does randomisation of valid and dummy messages in a high volume channel add security?"

But due to the reformulation based on answers provided, Tylo (https://crypto.stackexchange.com/users/4082/tylo) suggested it be posed as a new question.

Note that this question is possibly more communications management rather than true cryptography.

Scheme: valid messages in a high volume comms channel are identified by a pre-shared random number sequence interspersed with a large volume of random noise messages. These 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.

Mechanism: Controller A has different RNG'd lists for each of his field agents B to Z. Controller A wants to send a msg to B. He looks up B's list and the next number on that list is 527. He sends 1000 msgs marked to B's attention. All are random noise but msg 527 which is encrypted with the key that A uses to contact B.

B captures all 1000 msgs and decrypts only msg 527. The attacker must attack all 1000 msgs, does not know who the msg is sent to, has 25 different keys to attack (25 agents) and only 1 real message encrypted with 1 real key per 1000 msgs.

For B to contact controller A he looks up his RN list and sees that 641 is the next number. The procedure is the same as A contacting B but made more complex by B using the key that only he uses to contact A. Now the number of keys is 50.

Since the number lists sequencing this traffic are truly random and cannot be cracked and are never contained in ANY msg or disclosed in any way, then this seems to me to be a useful form of deception that just made the attacker's task 1000 times harder based on volume and 50 time harder based on key variation on top of any decryption difficulty for each key.

Questions: Is this interpretation basically correct? Is the scheme practical or useful? When used as a mechanism for radio contact it would seem to provide one of the most powerful protections possible: not knowing who is a message receiver (as opposed to someone physically logging in from somewhere to open an email), not knowing if a message is a message, and not knowing any key.

Answer 1

In addition to Paul's analysis, I'd point out that theres a few other issues. The primary one is that, at best, you have increased the workload of your attacker by a factor of 1000, in exchange for increasing your own work load by a factor of 1000. Let's say you're using a very poor encryption scheme that's known to be breakable in, say, 2^50 operations. (after all, that's why you're relying on this obscuration right? because you didn't trust your crypto?) Now the attacker needs to spend 1000*2^50 2^59.9 operations to crack it. For the amount of extra resources you applied to send that much extra fluff data, you didn't get very much of a leg up on your attacker.

Worse, if your encryption is as bad as you think it might be, there's no guarantee that the attacker must fully process each message to discard it. It may be very easy to identify which message is real because you may be able to identify the signature of the broken cryptography in the first place.

Finally, consider that you are absolutely dependent on the quality of your random number generator. If you have a PRNG like that, and you have resolved all of the synchronization issues that Paul mentioned, you might as well have just used the PRNG to generate a one-time-use pad. It would give you more security for less trouble.

Answer 2

I would suggest that the scheme is not robust. A predetermined list of authentic messages creates a synchronicity between sender and receiver. Lost messages will cause chaos. There are two more robust schemes:-

1. Passive.

Your ancestral question indicates the use of a true one time pad (OTP). You create a list of OTPs indexed by type 4 UUIDs generated by the hardware generator creating the OTP material. You have no lack of random numbers as you have a random number machine to make them. So for example:-

UUID1, OTP1

UUID2, OTP2

UUID3, OPT3 et cetera.

and you transmit:-

UUIDx | OTPx

where each OTP is of sufficient length to cover most reasonable eventualities. I'm specifically excluding the transmission of full length 4K quality porn films as that's not a suitable use case for a OTP system. The fake messages can be generated via a cryptographic strength pseudo random number generator to preserve OPT material if required, but this has the associated security disadvantage.

The system generates false and authentic messages, and if the UUID received matches one that exists in the receiver's list, then decode it. If it doesn't match simply ignore it. A UUID can have 2^122 possibilities so shouldn't repeat or collide very often.

2. Active.

You transmit OTPs that include an authentication code in a construct like:-

• cipher text = plain text ⊕ OTP
• mac = HMAC(key, cipher text)
• transmission = cipher text |mac

In this case, you decrypt all received messages and throw away those whose macs don't match.

You have to get away from the mindset of encumbering the spy agencies. As shown in my other answer, the OTP is perfectly secure and does not require further protection by slight of hand techniques throwing in extra decryption material. The primary objective here is to mask the level of communication between parties to thwart traffic analysis.