5

Consider a communication channel that needs to be secure (Encryption can not use full "volume" encryption, since future messages are not known). Would it be better to

  • only transmit encrypted messages and remain silent the rest of the time (therefore letting eavesdroppers know when a message is passed),
  • or sending encrypted pseudo-random data (or almost-meaningful garbage messages) during the remaining time - yielding a continuously encrypted stream which on the one hand hides the information of message transmission times, but otherwise adds the risk of a Known-plaintext attack should the garbage-generator (or the way separating actual message) be predicted.

Does the answer also depend on whether the messages shall be secure "forever" or if it is sufficient to maintain secrecy for a limited amount of time?

Tobias Kienzler
  • 313
  • 6
  • 20

3 Answers3

4

It depends on what your requirements are. In general, it is accepted that an observer knows when meaningful data is exchanged - even if he can't read it - because, well, we simply don't care. But in some cases this may be unacceptable, such as in p2p protocols where anonymity is very desirable and a fuzzy network can add a decent amount of secrecy.

On the other hand, continuously streaming is quite heavyweight, as it is in general not possible to keep streaming indefinitely (and intercepting all the garbage data and interpreting it as meaningless probably isn't free either, although that depends on your transmission protocol).

or sending encrypted pseudo-random data

Huh? Why would you encrypt pseudorandom data? This is actually a bad idea - by doing that and encrypting your pseudorandom stream with the same key, you will have tainted all the garbage data with your key material - the same key used to encrypt your precious ciphertext - thereby giving the attacker orders of magnitude more stuff to work with. If the underlying pseudorandom data that you originally encrypted is broken, boom, you just gave your opponent lots of plaintext/ciphertext pairs, and your key (and therefore, your ciphertext) is now potentially compromised.

No, just send pseudorandom data that's independent of all other information you might rely on, so just grab a few hundred bits of entropy and run some cipher in CTR mode or something to produce a nice pseudorandom bitstream - this way, even if this part of your scheme is broken, your ciphertext remains safe (even if the attacker now knows its size and roughly when it was sent).

but otherwise adds the risk of a Known-plaintext attack should the garbage-generator (or the way separating actual message) be predicted.

How so? If your cryptography is sound, and the garbage data does not leak any information about the plaintext or any key material (which it shouldn't, since it's just random bits), the two methods should provide equally optimal privacy. Even if an attacker somehow managed to distinguish the relevant ciphertext, he still wouldn't be able to decrypt it.

Does the answer also depend on whether the messages shall be secure "forever" or if it is sufficient to maintain secrecy for a limited amount of time?

Again, it depends on your requirements. There is no "one size fits all" cryptography, and every application needs its own version of it, that's why there are so many different protocols and schemes around. You need to figure out yours and implement it.

So basically, define your use of the word "secure" in your first sentence. Secure against what, and how secure should it be (should it provide only privacy? privacy and anonymity? perhaps integrity too, what about authenticity? etc...)

Thomas
  • 7,478
  • 1
  • 31
  • 44
  • Thanks for your answer - re "How so?" I only thought of the implication of encrypting the garbage as well, leading to the KPA, instead of simply considering the smart way™ of just using random data of entropy comparable to the encrypted data... I.e. your reply to sending encrypted pseudo-random data already makes by KPA-statement superfluous. – Tobias Kienzler Aug 13 '12 at 12:39
  • @TobiasKienzler You were right about KPA, I feel a bit hypocrite since I dismissed it after assuming your garbage data was not going to be encrypted, I didn't consider it until after and the paragraph remained. Still, it shouldn't happen if you do the garbage right. – Thomas Aug 13 '12 at 13:10
  • Well, I spotted only the symptom while you removed the cause first and then wondered about the cough :-7 Anyway you're right that the garbage shouldn't be encoded, while the "correct" garbage might allow keeping actual data transmission times sufficiently secret – Tobias Kienzler Aug 13 '12 at 13:15
3

By sending either a continual stream of data, or regular bursts of data, you can help reduce "traffic analysis". Traffic analysis is where an attacker correlates your network traffic to other events. For example, they may see you always have a burst of encrypted data right before your next software release.

Supposedly the pizza delivery guys in Washington D.C. know when a national crisis is underway from all the 2AM pizzas they deliver to the Pentagon, or to the congressional offices. That's literally traffic analysis.

If you have reason to believe traffic analysis is a threat to your security, you can thwart it to a degree by transmitting regular constant-sized packets of data, even when you have nothing to say to the receiver. You have to be diligent when you have data to send, as your transmission rate must never send more than your "background" level of data. In other words, if you regularly order 3 pizzas a night, during a crisis you better not order 30.

Continual transmission leaks some different information to your attackers, however. He knows you are still actively communicating, he has lots of messages to work on, and he may discover who you are communicating with at any time.

It all depends on your particular threat model. But for the vast majority of applications, it probably isn't worth it.

John Deters
  • 3,728
  • 15
  • 29
  • Thanks, the pizza example is great! Of course one could permanently use a public transmission (i.e. order pizza for every household...) - that way, everyone knows you communicate, but there is practically no way to determine who actually decrypts the data. Which may turn out to be a disadvantage of course, since a leak will then be just as difficult to backtrack... – Tobias Kienzler Aug 14 '12 at 08:05
-2

No, sending a constant stream of garbage does nothing to improve security. A basic principle of secure system design is Kerckhoff's principle: essentially, that the enemy knows the system. An adversary that knows the system will know when you send a message, so you gain nothing from all the junk data before and after.

pg1989
  • 4,636
  • 23
  • 42
  • 1
    Please review/explain the following sentence, "An adversary that knows the system will know when you send a message". – Thomas Aug 13 '12 at 23:21
  • Ok, I checked Wikipedia: A cryptosystem should be secure even if everything about the system, except the key, is public knowledge. [...] The enemy knows the system [...] is called Shannon's maxim. Do I understand it correctly that your point is, as long as the actual data encryption works, adding garbage is just security through obscurity? In that case I don't understand the downvotes, it sounds like a valid point to me. – Tobias Kienzler Aug 14 '12 at 07:59
  • @TobiasKienzler Absolutely not. Kerckhoff's principle has nothing to do with this, because an attacker that knows how you send out your garbage-embedded-with-message data will not know when you sent the message itself, that's the whole point. You are not using security with obscurity here, even if the enemy knows exactly how you lay out your data (with encrypted begin/end symbols for instance), he cannot differentiate them from the garbage stream. – Thomas Aug 14 '12 at 08:41
  • @Thomas Won't the worst-case attacker also know the garbage-generator and can then by reproducing it deduce from deviations that a transmission occurred? Of course if one assumes the garbage is coupled to a truly random generator, that is indeed not possible. So whether this is STO or not depends on the garbage generator's randomness, correct? – Tobias Kienzler Aug 14 '12 at 08:56
  • 1
    @TobiasKienzler As outlined in my answer, the ciphertext itself will remain secure no matter what, so from that point of view it's not STO. However, yes, if the attacker can distinguish the garbage from the ciphertext, then adding garbage becomes merely obfuscation, which is a form of STO. But consider that breaking the underlying PRNG that generates the garbage may be as hard as breaking the cipher with which your message was encrypted, and the whole point is moot. – Thomas Aug 14 '12 at 08:59
  • 1
    @Thomas Thanks for the clarification. I think this is an important preposition to countering traffic analysis. One should also keep John's point in mind, that permanent communication may make it easier to determine who are communicating with, should that be worth keeping secret... – Tobias Kienzler Aug 14 '12 at 09:15
  • Thanks for the discussion, guys. I don't even mind the downvotes. – pg1989 Aug 17 '12 at 17:54