11 ms·
Steganographic Packets
- LinuxBender 8y agoThis is very clever. I hope the author continues to work on this. This could be very useful where speech is censored and encrypted streams are blocked.
- NullUsr 8y agoThanks. I hadn't really given much thought for any widespread practical use. I think the throughput would be the limiting factor, on average (using my encoding scheme, which could definitely be optimised) you average about 5.882 Bps. Would definitely be interested in hearing what uses people see for it though!
- gpm 8y agoThe first thought that comes to mind is Tor's pluggable transports used to bypass censorship. Admittedly 6Bps isn't good enough for that (I think), but it might be possible to combine it with other mechanisms or increase that number? https://www.torproject.org/docs/pluggable-transports.html.en https://www.torproject.org/docs/pluggable-transports.html.en
- egberts1 8y agoWhile TOR represent the worst kind of the variances of inter-packet delay of all network topology, the devil in the details is compensating for the largest “single-hop”-like variance.
- egberts1 8y agoUmmm, think of those dedicated phones between two ATM switches in the old days.
- brad0 8y agoWould this work over a long connection? Say to the other side of the world? Network delays would mess this up afaik. I suppose you could introduce a error correcting code in it but that would kill your throughput even more.
- egberts1 8y agoDelays in pulse width modulation are easily overcome with lower bandwidth and/or error correction coding: a function of Shannon’s limit.
- detaro 8y agoMessing with packet sizes could also be an option?
- bebna 8y agoFor more like this, see pluggable transports [0] from tor. [0] https://www.torproject.org/docs/pluggable-transports.html.en#list-of-pts https://www.torproject.org/docs/pluggable-transports.html.en...
- egberts1 8y agoThat’s why we have waterfall defense against these kind of offense, oh wait. No, really, it is a 25yo solved problem, non-academically.
- egberts1 8y agoThe real art is being able to decipher these pulse-width modulated packets across multiple hops (and switches) while factoring in the variances Of traffic flow that surges through each hops.
- jwbensley 8y agoThis is nothing new. This is a form of covert channel: https://en.m.wikipedia.org/wiki/Covert_channel https://en.m.wikipedia.org/wiki/Covert_channel Specifically from the Wiki artical see the Timing Channel section. Another interesting concept is to hide the bits in the unused options in protocol header fields (see the "Data hiding in TCP/IP Protocol suite by covert channels" section on the same Wiki artical). I was looking for example code snippets online and found some examples of hiding bits in packet headers but, not in inter-packet timings. I ended up writing a transmit and receive script one afternoon at my desk out of boredom (although, just as a proof of concept to myself, I didn't take the time to refine to the superior levels of the OP, such as bit rate or reliability, as I never intended to use it): https://null.53bits.co.uk/index.php?page=icmp-messages https://null.53bits.co.uk/index.php?page=icmp-messages It would be nice to combine the technique used in some header-bit-packing scripts with the OPs timing based script; whereby one specifies the destination IP we want to communicate to secretly and alter the buffering of packets only to that IP. I never bothered to refine my scripts beyond "Hello World" because the timing based approach requires one to generate traffic that possibly otherwise wouldn't exist between the source and destination IP. Encoding bits in the inter-packet delay of existing "legitimate" flows to the destination would require it to be relatively close in terms of latency.
- NullUsr 8y agoNot sure if you spotted the links in the post itself, but there's a working (basic) proof of concept here: https://github.com/vimist/packet_differential_encoding https://github.com/vimist/packet_differential_encoding Boyan commented on the post itself suggesting applying coding & modulation theory, which I thought was an interesting point.