Using Protocol Obfuscation some internet protocols have tried to evade traffic shaping. BitTorrent supports Protocol Obfuscation for instance.

Is it possible to build unbreakable Protocol Obfuscation? Unbreakable in the sense that an observer cannot (heuristically) tell what kind of protocol this is?

I can think of a simple, but breakable Protocol Obfuscation scheme: Encrypt all traffic with a static pre-shared key. But traffic shaping network nodes can simply try to decrypt and identify the protocol that way.

  • 2
    This is an interesting question but, unfortunately, it isn't well suited for this place. In order to properly answer it, you'd need a formal proof which is seriously out of scope – Stephane Jan 12 '16 at 14:13
  • @Stephane did I at least hit the right Stack Exchange site? There are many. Also maybe there is an existing result. – boot4life Jan 12 '16 at 15:16
  • I don't think any stackexchange sit would be a good fit because of the scope of your question: you might want to go to a discussion forum instead. Otherwise, for specific questions about protcol obfuscation, this is the best place. – Stephane Jan 12 '16 at 15:44
  • If the OP is interested in theoretical aspects, crypto SE might be a better fit. – Dmitry Grigoryev Jan 12 '16 at 16:22

Both sides (client and server) can encrypt everything by a shared secret. The handshake would start by a salt and then everything would be encrypted by a stream cipher.

Possible sniffer would see only the random mess being send between server and client, no handshake, no packet headers, no readable/open data. So, the only way how to determine the protocol would be the observation of traffic of random bytes. You can obfuscate that by sending nonce data randomly.

After short thinking I'm convinced I can design the same protocol with DH key exchange or public key encr., so no shared secret would be needed.

  • A sniffer could read the salt and then decrypt to unmask the protocol with the first proposal, right? Is that weakness gone with the key exchange version? – boot4life Jan 12 '16 at 16:44
  • No, the encryption key is salt+sharedsecret. Salt is there just to keep all the sessions different. The problem with the key exchange is that you need (due to DH) to send and receive a big number which may not be necessarily like random. For instance it could be rounded and someone may make an unreliable guess about the protocol. – smrt28 Jan 13 '16 at 8:07

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