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)
participants (3)
-
Bill Stewart
-
Douglas B. Renner
-
Jeremiah A Blatz