Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

I was reading a question about combatting traffic analysis, and a thought occured. If I send random junk messages periodically, would that defeat traffic analysis?

The messages would contain some form of header to specify "this is junk", and would otherwise be comprised of random data of a random (plausible) length. In fact, the data could just be produced by a CSPRNG, such that the packets would not be decryptable. Someone who knows the key would be able to verify that the decrypted message was invalid, but an attacker wouldn't be able to tell which messages are part of the conversation and which are random, making it difficult to perform cryptanalysis.

Does this idea have merit?

share|improve this question

1 Answer 1

up vote 2 down vote accepted

Well, this isn't a new idea. One place (and probably not the first place) this has appeared before is in IPsec RFC4303, see dummy packets in section 2.6.

Now, IPsec differs from your suggestion in that it isn't using some output from a CSPRNG. Instead it just grabs some arbitrary amount of data of the right length (with the marker that it is a dummy packet), and just encrypts it just like it would a real packet. This is just as indistinguishable as a CSPRNG would be, and (at least for IPsec) it is a bit more convenient (because you can reuse the same infrastructure that does encryption, rather than having a separate CSPRNG infrastructure).

Now, the problem with this idea is that it can be hard to do, at least, if you want something that can fool an intelligent listener. For example, suppose that you are protecting some TCP traffic. Now, with TCP, one side sends a message (a TCP packet with data), and the other side immediately responds with a reply message (the TCP acknowledgement). The problem that this behavior causes is that if one side just sends a dummy packet, and the other side doesn't reply, well, the attacker can pretty much figure out that the two sides aren't really communicating, and that's what we're trying to hide. To effectively hide this, what we'd need to do is send a dummy packet, and have the other side respond with its own dummy packet (with approximately the same timing as a real TCP ack would have). To further complicate things, TCP isn't the only protocol in use; another example might be RTP (which is mostly unidirectional); disguising that would take a different strategy.

On the other hand, if you do know enough about the protocol you're protecting to effectively mimic it, this idea can work.

share|improve this answer
    
That pretty much sums up what I thought. Glad to see I came up with the same idea as the IPSec guys independantly! :D –  Polynomial Jul 11 '12 at 20:38

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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