Steganographic Packets

#1

Post by NullUsr » Wed, Jan 30, 2019, 5:05 PM UTC

Re: Steganographic Packets

#2

Post by LinuxBender » Wed, Jan 30, 2019, 5:27 PM UTC

This 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.

Re: Steganographic Packets

#3

Post by NullUsr » Wed, Jan 30, 2019, 8:54 PM UTC

LinuxBender wrote: post #2

This 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.

Thanks. 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!

Re: Steganographic Packets

#4

Post by gpm » Thu, Jan 31, 2019, 8:43 AM UTC

NullUsr wrote: post #3

LinuxBender wrote: post #2

This 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.

Thanks. 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!

The 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

Re: Steganographic Packets

#5

Post by brad0 » Thu, Jan 31, 2019, 9:51 AM UTC

Would 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.

Re: Steganographic Packets

#6

Post by detaro » Thu, Jan 31, 2019, 9:54 AM UTC

Messing with packet sizes could also be an option?

Re: Steganographic Packets

#7

Post by bebna » Thu, Jan 31, 2019, 10:31 AM UTC

For more like this, see pluggable transports [0] from tor.

[0] https://www.torproject.org/docs/pluggable-transports.html.en...

Re: Steganographic Packets

#8

Post by egberts1 » Thu, Jan 31, 2019, 2:18 PM UTC

That’s why we have waterfall defense against these kind of offense, oh wait. No, really, it is a 25yo solved problem, non-academically.

Re: Steganographic Packets

#9

Post by egberts1 » Thu, Jan 31, 2019, 2:20 PM UTC

brad0 wrote: post #5

Would 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.

Delays in pulse width modulation are easily overcome with lower bandwidth and/or error correction coding: a function of Shannon’s limit.

Re: Steganographic Packets

#10

Post by egberts1 » Thu, Jan 31, 2019, 2:21 PM UTC

LinuxBender wrote: post #2

This 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.

Ummm, think of those dedicated phones between two ATM switches in the old days.