For very-low-bandwidth data transfers hidden in wideband streams, we could maybe use timing of packets. Wouldn't work with more congested networks, and would need some kind of REALLY heavy-duty error correction, but could be rather difficult to spot.
Do some reasonable error-correction on it, and then implement IP over it. Hey, we *said* it was an unreliable transport protocol.... :)
The signal could be transported in the intervals between the IP packets sent, or by dropping selected packets and requesting retransmissions, or by swapping the order of some packets.
The constraint here is that an outsider mustn't be able to distinguish the performance of a stego-enabled system from a non-stego system. So I think you'd have to be really careful about dropping very many packets, swapping packets, etc.
As a first cut, suppose I have a sort of encoding mask for two different bits, e.g.
0 == 01010101 1 == 10101010
Then I decide whether to delay packets by some very small amount based on which mask I'm using, adding a really small delay whenever there's a 1.
The receiver tries both masks, and chooses the more probable one. (For the nine packets he receives, he does some statistics on the delays between packets, and assigns probabilities of 1 symbols in each location, throws out obvious outliers, etc., and then chooses the most probable decoding.) The goal here would be to get down to delays that were small enough that an attacker who didn't know the two candidate masks would have a very low probability of being able to distinguish the behavior of a stego-enabled system from a non-stego system. Sort of like having a timing attack which is impractical because the attacker must guess too much internal information before he can test his guess....
Has anyone done this kind of scheme in the open literature before? This seems like the sort of thing someone would have investigated as a covert channel for leaking information from a compromised system.
The world is crammed full with unused communication channels.
Yep. Mostly unused because they're not all that reliable, or because they offer too little bandwidth to be worthwhile, alas.
...
--John Kelsey, [EMAIL PROTECTED]
