Re: Stego via TCP/IP (was Re: crypto wish list)

>>>Where is highly sophisticated stego?
>>What are our options?
>>- Stego in english text.
>>- Stego in audio and graphic file formats
>>- Stego in Internet Phone protocols.
>>- Stego in Internet video conference formats

My experience with CU-SeeMe has been that it loses
huge quantities of data, though that's partly because
I've only used it over 14.4 modem, which isn't really
fast enough.  If the data formats are documented,
it wouldn't be hard to add a few frames of "pictures"
every second or ten that are designed to get sidetracked.
CU-SeeMe can talk one-to-one, but is generally used through
"reflectors", which are conference bridges.
One technique is to stego-equip both the client and
reflector; a more generally useful but harder method would
be to see what you could get to pass through a reflector
between two stego clients.

Motion pictures in general give you a lot of slack;
not only do they have high data rates from uncheckable sources,
but you can hide data in ways you correct later,
e.g. for Frame1 ... Frame2 ... Frame3, 
where the values for a given pixel change between Frame1 and Frame3,
you can encode some bits by picking whether the change happened
between Frame1 and Frame2 or Frame2 and Frame3, and your output
is perfectly valid video, readable by anybody, only a bit fuzzier
than it might have been from that cheap $89 camera you're using
in bad lighting with the ceiling fan going in the background.

Stego in innocuous-looking data is another approach.
Send those spreadsheets of traffic data or SNMP stats
or daily sales of products from your supermarket or whatever!

I've been wondering about _un_sophisticated stego,
for cases where you're trying to slip below the radar
of simple bots or dumber eavesdropping thugs.  For instance,
you could send that DOS executable .exe or animated GIF
which really _does_ expand into the cover-traffic file or 
generate the annoying flaming background for your web page,
but which also drags along a bunch of stegobits that
the executable thinks are just data it's ignoring or the
GIF thinks is past the last frame.

Then there are pictures which have inherently high entropy,
so you can get away with a lot more stego - like the
animated cloud picture movie you interpolated from the
weather satellite photos, or the photo of the wheelbarrow of sawdust.

#			Thanks;  Bill
# Bill Stewart, +1-415-442-2215 stewarts@ix.netcom.com
# You can get PGP outside the US at ftp.ox.ac.uk
  Imagine if three million people voted for somebody they _knew_,
  and the politicians had to count them all.

Bill Stewart <stewarts@ix.netcom.com> writes:
> I've been wondering about _un_sophisticated stego,
> for cases where you're trying to slip below the radar
> of simple bots or dumber eavesdropping thugs.  For instance,
> you could send that DOS executable .exe or animated GIF
> which really _does_ expand into the cover-traffic file or 
> generate the annoying flaming background for your web page,
> but which also drags along a bunch of stegobits that
> the executable thinks are just data it's ignoring or the
> GIF thinks is past the last frame.

Actually, animated gifs provide an excellent carrier for regular
stego. Just create your gif with 32 or so colors, then use the rest of
the bits for close matches. You could, say, use the standard
intersection of the Mac/Windoze pallettes. With something like this,
you get like 3 bits per pixel (if you do the color map right), which
could be enormous with a big animated gif.

Liking lossless animation standards,
Jer

"standing on top of the world/ never knew how you never could/ never knew
 why you never could live/ innocent life that everyone did" -Wormhole

> >>>Where is highly sophisticated stego?
> >>What are our options?
> >>- Stego in english text.
> >>- Stego in audio and graphic file formats
> >>- Stego in Internet Phone protocols.
> >>- Stego in Internet video conference formats
> 

Stego in packet timing variations!

The ultimate NSA grep nemesis.   My gut tells me that this information is 
not collected by big bro.   Of course it would be very low bandwith and 
high noise...  But with higher-speed links, and the Internet of 
tomorrow, these will diminish vastly in significance.

Imagine a Linux kernel patch which precisely tracks packet timings 
by every originating host, and modulates the timing of return packets.  A 
full-duplex, error-corrected protocol could be built on top of this 
subtle exchange of information.


-Doug Renner
(Author of several industrial protocols for a previous employer)