Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
The Science of Hiding in Plain Sight

By scorbett in Science
Tue Oct 26, 2004 at 04:00:31 PM EST
Tags: Software (all tags)
Software

Steganography is the science of hiding one message inside another message - hiding in plain sight, so to speak. Think of steganography as the soft-spoken yet elegant sister of cryptography. Where cryptography scrambles a message to prevent unauthorized people from reading it, steganography opts instead to hide the message in such a way that it is not obvious that there is anything there to see. Read on for a description of steganography, with examples.


Although steganography is far from a new science, it arguably did not reach its full potential until the computer age. Early attempts at steganography involved things like invisible ink, microdots, or even secret messages tattooed on a messenger's body, either under the clothes or under the hair on his head. All of these pale in comparison to what is possible today.

Digital messages are composed of bits and bytes, which can be manipulated in subtle ways to achieve the desired results - we can embed a secret message into an innocent looking "container" message, and no casual observer will be alerted to anything out of the ordinary. Even most non-casual observers can be fooled into overlooking your secret message.

WHY STEGANOGRAPHY?
If you have sensitive information that you wish to transmit over a potentially insecure communications channel (such as the Internet), you may wonder what advantage steganography has over, say, GnuPG for secure communications. The problem with cryptography is that it is obvious - that is, anyone who observes an encrypted message in transit can reasonably assume that the sender of that message does not want it to be read by casual observers. They may then deduce that the message contains some valuable information - information worth stealing. Steganography provides a more elegant way of communicating the sensitive information in question... by disguising it as something inane and/or otherwise uninteresting.

So, perhaps you wish to discreetly communicate sensitive information without sending up any red flags, or perhaps, like me, you're a coder who is easily mesmerized by neat data manipulation tricks and other interesting algorithms. Either way, read on.

HOW DOES IT WORK?
One of the more common approaches to steganography is to store your secret message in the least significant bit(s) of every byte of your container message. Depending on the nature of your container message, this can work quite well - for example, let's say an uncompressed audio stream or a lossless image format such as PNG.

In the case of audio, we can easily overwrite the lowest bit of data in every tenth or so byte without causing an audible loss of sound quality. In the case of image data, we can steal even a little bit more than that without the result of our manipulation being visible to the human eye. For example, consider this image - pretty boring, right? Let's embed a secret message into the lowest two bits of every byte of image data and see what it looks like: no visible differences. We can even get a little bit braver and try to steal 4 bits out of every byte of image data: here. If you look closely, you can see something appears wrong with the sky near the top of the photo, but unless you are inspecting very closely, it would be easy to write it off as simply an image quality problem - perhaps this image was scanned in from a magazine or something. It's not until we get up to six bits per byte or even eight bits per byte that you can instantly see something is wrong.

(All example images were generated with StegPng, which we'll get to towards the end of this article).

LET'S SEE SOME CODE ALREADY!
At the core of the code for a basic steganographic algorithm will be something vaguely resembling the following:

for each source byte
{
byte sourceByte = getNextSourceByte();
for (int i = 0; i <8; i++)<br> {
byte sourceBit = sourceByte >> (7-i);
byte targetByte = getNextTargetByte();
byte maskedByte = targetByte & 0xFE;
targetByte = maskedByte | sourceBit;

// now write the new target byte back to
// the container data at the index where
// we found it.
}
}

This very basic algorithm takes each byte of source data (your secret message) and breaks it into its eight component bits. For each bit in the source byte, we acquire a target byte from the container data (this could be an RGB value from your wrapper image, or the next byte of audio data from a .WAV file, or whatever). We AND the target byte with 0xFE, which causes the lowest order bit to be zeroed out. We then OR in the next bit of the source byte. Once all eight bits of the source byte have been written out, we advance to the next source byte, and so on until the entire secret message has been stegged in.

The reverse of the above procedure would be something like this:

while (true)
{
byte reconstructedByte;
for (int i = 0; i <8; i++)<br> {
byte steggedByte = getNextSteggedByte();
byte dataBit = steggedByte & 0x01;
reconstructedByte |= (dataBit << (7-i));<br> }

// Now add the reconstructedByte to the
// secret message data.

// If the secret message data has been
// fully reconstructed, break the outer loop.
}

For each byte we wish to reconstruct, we read the next eight bytes of stegged data, taking the lowest order bit out of each one and ORing it back into our reconstructed byte. We then add the reconstructed byte to an array of rebuilt secret message data.

You may wonder how we know when the end of the secret message data is reached... this is where things get a bit complicated. During your steg process, you probably want to write out some kind of stegged header along with the stegged data so that you know when to stop reading during the de-stegging process.

You may also wonder how much the code changes if we want to be able to consume a variable number of bits per byte, instead of a fixed number of 1. This is where things get a lot complicated. Read on for the grisly details.

EXAMPLE STEG PROJECT - StegPng
If you've gotten this far and are still reading, I'll assume you are interested in learning more about how steganography works. If so, I invite you to check out my StegPng project (this is not an advertisement - I don't make any money off of StegPng or anything else on my website... I'm literally doing this for the fun of it).

StegPng includes variable data compaction (this is the number of bits per byte to "consume" in the container data), and comes complete with full source code so you can take it apart and tinker with it if you please.

ADDENDUM - STEGANOGRAPHY AND TERRORISM
A few years ago, steganography made the news, when it was rumoured that terrorists may be using steganography to communicate their plans over the Internet. Although there was very little evidence put forward to substantiate this claim, the rumours persist to this day. Do terrorists use steganography? Some say yes, some say no. Perhaps those who say no are merely being naive, or perhaps those who say yes are simply being alarmist. In any case, there are countermeasures for steganography available, and some have been in use for quite a while, so I doubt there's any steg tool out there that can't be detected.

Personally, my interest in steganography is academic, not practical, and this is reflected in the design of StegPng - simple statistical analysis of the container image would probably reveal the presence of a secret message within a stegged PNG image. So let me preemptively defend myself against anyone who might accuse me of helping out the terrorists - StegPng is a neat idea, but without some serious modifications it is probably useless for serious covert communication.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Steganography
o cool 6%
o geeky 2%
o cool and geeky 71%
o I'd rather talk about Iraq and/or the upcoming US elections 12%
o meh 8%

Votes: 49
Results | Other Polls

Related Links
o Steganogra phy
o cryptograp hy
o invisible ink
o microdots
o GnuPG
o inane
o uninterest ing
o PNG
o this image
o no visible differences
o here
o six bits per byte
o eight bits per byte
o StegPng
o rumoured
o very little evidence
o persist
o naive
o countermea sures
o some
o quite a while
o Also by scorbett


Display: Sort:
The Science of Hiding in Plain Sight | 78 comments (53 topical, 25 editorial, 0 hidden)
practical use (2.66 / 3) (#3)
by the77x42 on Tue Oct 26, 2004 at 01:08:23 AM EST

http://www.spammimic.com/encode.shtml


"We're not here to educate. We're here to point and laugh." - creature
"You have some pretty stupid ideas." - indubitable ‮

(Old) Examples of Steganography (3.00 / 2) (#6)
by For Whom The Bells Troll on Tue Oct 26, 2004 at 05:59:39 AM EST

The Steganography wing of the Gallery of DeCSS Descramblers.

That said, a very interesting project; will look into it in the evening if I'm not tired already. :-)

---
The Big F Word.

This is an old project but.... (none / 1) (#22)
by The Amazing Idiot on Tue Oct 26, 2004 at 11:43:18 AM EST

This does bear much interest in the steg community

http://www.mcdonald.org.uk/StegFS/ : Steanographic file system.

Steg and encryption (3.00 / 2) (#26)
by yamla on Tue Oct 26, 2004 at 01:13:25 PM EST

I found a project a long time ago that stripped out the identifying headers from a PGP-encrypted message and embedded that inside a picture (or maybe inside other data).

The advantage of doing this is that if you are careful (i.e. have a decent implementation), there's no way to tell that the data you pull out isn't MEANT to be part of the picture.  That is, because properly encrypted data looks completely random, and without identifying headers, you are safe from the statistical analysis mentioned in the article.  You are also safe from searching for headers, too.  Unless you know the password, you cannot tell if you have found some hidden data or just noise.


That's not true... (3.00 / 3) (#43)
by skyknight on Tue Oct 26, 2004 at 11:39:34 PM EST

properly encrypted data looks completely random, and without identifying headers, you are safe from the statistical analysis mentioned in the article. You are also safe from searching for headers, too. Unless you know the password, you cannot tell if you have found some hidden data or just noise.

That's not true at all. Images exhibit patterns of data, and those patterns of data are disrupted by the introduction of encrypted data. If the encryption algorithm is good, then the data will be perfectly random, and this will be quite different from the patterns seen in images, thus flagging it as a covert channel. Real steg programs go to great pains to preserve the statistical properties of the original image. It's not good enough that a steganalyst can't extract a message. If he knows that there was any message at all, then you're in trouble.

Crypto is perhaps the most dangerous field to have a little bit of knowledge. Knowing a little is often worse than knowing nothing at all as it engenders a false sense of confidence that can be quite injurious.



It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Interested (none / 0) (#50)
by jolt rush soon on Wed Oct 27, 2004 at 01:44:57 PM EST

What kind of patterns are present in the low bits of images? Is this different in scanned images and digital photography?

I always thought it'd be a bad idea to store extra data in any files that have previously been compressed and then expanded to an uncompressed format. If you can't see the detail lost in the lowest bit, I'm guessing that any lossy formats are going to clobber this kind of data too. I wonder how difficult it would be to look for irregular lower bits in previously compressed images.
--
Subosc — free electronic music.
[ Parent ]

It's not just the low bits... (none / 1) (#57)
by skyknight on Wed Oct 27, 2004 at 09:51:56 PM EST

By definition, any non-random stream of data contains patterns. For a given domain, there may be consistent patterns across samples. If you using this data stream as a carrier for information, you have to be mindful that you maintain its statistical properties or you are going to be obvious.

Speaking of compression, compression tools are probably a pretty good yet simple way to detect steg, at least if they try to put a long message into the image. Presumably the greater the percentage of the message being used as a carrier, the worse it is going to compress (if you're doing lossless).



It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
inherancy (none / 0) (#69)
by Norkakn on Sun Oct 31, 2004 at 08:10:29 PM EST

is the pattern inherent to being a picture?  if I take a random snapshot and run it through the A/Ds on a crappy scanner, it seems that the noise on the low order bits will be dependant on the noise characteristics on the A/D (especially since I doubt that a 50$ scanner would really be able to get 24 bits of intformation, so there is probably some fudging for the low order bits.)

I dunno, I guess to me it seems as though it would be random or based on the particular A/D chip.

[ Parent ]

Well... (none / 0) (#70)
by skyknight on Sun Oct 31, 2004 at 08:32:33 PM EST

I'm not well versed in the theory, so let me appeal to intuition. Yes, there is going to be a noisy channel, but it's not entirely random. Say in the picture you have a patch that is particular color. For the most part, that particular color is going to be encoded the same way, but because of hardware issues there is going to be some noise present. It's not going to be so noisy as to be completely random, however. At least, I expect not. In any case, while this might not be a particularly compelling argument, I trust the authors of crypto papers have a good reason for going to significant trouble to preserve statistical properties of images when doing steganagraphic encoding. Presumably neither of us are particularly hot shit when it comes to information theory, but I'm sure they are.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Half the loss of data (3.00 / 5) (#27)
by yamla on Tue Oct 26, 2004 at 01:25:59 PM EST

One thing to note is that, when you hide RANDOM data (or encrypted data) inside a source image, you probably aren't actually lowering the quality of the source image as much as you'd immediately suspect.

Let us say, for example, that you have an image file where each pixel has 24 bits of colour data, made up of 8 for red, 8 for green, and 8 for blue.  For the sake of this discussion, the image is uncompressed (because I'm too lazy to think how compression affects matters)  And you have some data you are trying to hide in the image, in the least-significant bit of each byte.

Now, you use steganography to place your data in your image.  However, because the least-significant bit of each colour byte is as likely to be 0 as 1 (assuming a scanned or photographed regular picture), and because your hidden data has the same distribution, you will only on average change HALF the bits.  The other half you 'change' to the same value they initially had.

So while the initial image had 24 bits of data per pixel, the new image with the hidden data sort of has 22.5 bits of data per pixel instead of the expected 21 bits per pixel.  That is to say, the container image and the steganographic image only differ by one bit in sixteen.

The other thing is that the human eye is much less sensitive to blue in an image.  You can change the blue data in an image almost twice as much as you can change the green or red without a person being able to see the difference.  This gives you extra bandwidth for virtually no cost.

Not quite correct (none / 1) (#45)
by interjay on Wed Oct 27, 2004 at 06:03:22 AM EST

Going by that logic, if you replaced ALL the bits in a 24 bpp image with random data, you would still have 12 bits of image data per pixel.

One way to think about it is: It's true that 50% of the time the bit would be unchanged. However, the other 50% of the time, you would replace the bit with wrong data, which is even worse than simply removing that bit. So on average you would still lose 1 bit of data for every bit you replace with random data.

[ Parent ]

Not quite correct (none / 0) (#48)
by yamla on Wed Oct 27, 2004 at 11:02:53 AM EST

Ah, but if you replace all the bits in (for this example) an 8 bit image, it doesn't matter what the other seven bits are if you change the first bit.

All I'm saying, really, is that if you only replace the least significant bit AND if you replace it with new data that is randomly distributed AND if the source data was randomly distributed, the resulting image (or sound file, or whatever) will differ less than you'd expect.

True, you still theoretically have thrown away one bit, not half a bit.

[ Parent ]

+1FP technology and (a little) culture centric nt (2.66 / 3) (#29)
by nlscb on Tue Oct 26, 2004 at 02:51:01 PM EST


Comment Search has returned - Like a beaten wife, I am pathetically grateful. - mr strange

SPAM (3.00 / 3) (#32)
by cronian on Tue Oct 26, 2004 at 04:45:01 PM EST

I don't know if anyone is seriously using stenography, but if they were they could hide it in SPAM. They then send it out to all sorts of addresses, among whom would be the actual recipient. If done properly, it would be really hard to figure it out.

I always wonder, how much of the SPAM is actually stenography. Especially, the weird asian porn SPAM, and other SPAM which doesn't link to anything. How widespread is stenography?

We perfect it; Congress kills it; They make it; We Import it; It must be anti-Americanism
That's a freaky thought. (3.00 / 2) (#33)
by Deagol on Tue Oct 26, 2004 at 05:29:20 PM EST

I always wonder, how much of the SPAM is actually stenography. Especially, the weird asian porn SPAM, and other SPAM which doesn't link to anything.

That would be one hell of a way to relay info: hide it in a crapflood of spam. There's a utility to encode arbitrary data as spam-like messages (someone already posted a link). It's certainly possible.

Think of it as the digital equivalent of "numbers stations" heard on shortwave frequencies.

Cool idea.

[ Parent ]

Those number stations (none / 1) (#39)
by GenerationY on Tue Oct 26, 2004 at 07:24:27 PM EST

anyone ever figure them out?
Always found them very sinister in my SW tinkering days.


[ Parent ]
I like text container stego (none / 1) (#34)
by Deagol on Tue Oct 26, 2004 at 05:38:25 PM EST

Someone already posted a link to the spam stego encoder. That's pretty neat.

A long time ago, I found a program that hides data by padding text files with whitespace in such a way that it is visually appears innocous. (Found it on either simtel or garbo, for you old-timers.) While the feds are busy searching the image and audio files on your web server for secret messages from bin Laden, they'll very likely ignore the HTML files the server spits out.

Stego's such a cool science.

ok bee-otches, you deserve it (none / 1) (#36)
by bloodnose on Tue Oct 26, 2004 at 06:28:28 PM EST

here's 1 of my steg designs: manchester (see any networking textbook) encode your data in the capitalization of html codes. add whitespace as an option at encode time. also use empty/nonfunctional html tags if you need more data. whee.

/loch ness guar form

[ Parent ]
Ask K5: Would this work? (3.00 / 3) (#35)
by mcgrew on Tue Oct 26, 2004 at 06:13:22 PM EST

Say you're a terrorist leader who wants to let his minions know that the schedule for blowing up a train station is at 7:30 AM Thursday, and it's the Springfield station.

You write down on a piece of paper "Blow up O'Hare 8:59 Tuesday". Tape it to a TV set tuned to no station- static, snow. Photograph it and scan tha photo into a computer.

Then insert in the photo at a predetermined spot in the screen's snow an encrypted text message "Blow up Springfield train station 7:30 AM Thuursday".

Rename the file "Stupid joke.wav"

Of course, the authorities will outsmart you and figure it's a BMP and rename it. They then see "Blow up O'Hare 8:59 Tuesday". Half the cops in the world swoop down on O'Hare on Tuesday, and nothing happens. False alarm.

Until the train station blows up. There must be a flaw here, where is it?

Seems to me stegnography is a lot more dangerous to our nation (or any nation) than plain crypto.

"The entire neocon movement is dedicated to revoking mcgrew's posting priviliges. This is why we went to war with Iraq." -LilDebbie

Intelligence (none / 0) (#37)
by grahamsz on Tue Oct 26, 2004 at 06:35:44 PM EST

I doubt any intelligence agency would take a message like this at face value. I'm under the impression that most terrorist organizations use codewords for just about everything.

Incidentally, tv snow may be quite a bad image to use stenography with. If the source image were truly random then you might be able to detect the non-randomness where the message is inserted.
--
Sell your digital photos - I've made enough to buy a taco today
[ Parent ]

pre-encrypt (none / 0) (#38)
by yamla on Tue Oct 26, 2004 at 06:53:54 PM EST

As a standard policy, you encrypt your message before using steganography.  This way, your message is converted into a random string of 0s and 1s (not really random, of course, but with no detectable non-randomness).  Provided your source image has essentially random least-significant bits, it should be entirely impossible to detect your hidden message.

Any terrorist organisation smart enough to use steganography is more than smart enough to encrypt their message beforehand and strip out the identifying headers.  Heck, we know a small proportion of terrorist organisations use encryption already.

[ Parent ]

Numbers Stations (3.00 / 2) (#40)
by Stanislav on Tue Oct 26, 2004 at 08:17:45 PM EST

Consensus is that these broadcasts were for agents using one-time pads. A series of 4- or 5-digit numbers is broadcast. The recipient has a pad with columns of similar numbers. Each number broadcast is subtracted from the correlating number on the pad -- the resulting sum indicates a particular word or phrase. The used page of the pad is discarded, and the next message uses the next page. It is a humble, yet basically unbreakable system -- unless you have access to a copy of the pad, you are lost.

[ Parent ]
No, but yes (3.00 / 2) (#55)
by rmn on Wed Oct 27, 2004 at 05:01:35 PM EST

tv snow may be quite a bad image to use stenography with. If the source image were truly random then you might be able to detect the non-randomness where the message is inserted.

Well, no, you wouldn't (it's much easier to hide something in a random background than on a plain white background, for example), but I still agree that TV snow is a silly background to use - it immediately suggests that there's something "fishy" about the background.

On the other hand, maybe the MIB would think it was a stereographic image, and screw up their eyes so badly, trying to see it in 3D, that they would get a headache, and be unable to work for days.

[ Parent ]

Sir (none / 0) (#71)
by sllort on Mon Nov 01, 2004 at 10:01:53 AM EST

The "prearranged spot" you speak of is an offset, which would mean they had time to give the terrorist cell a shared secret. If they can do this, they could make the shared secret a one time pad, which is unbreakable. So why bother? I believe most cryptographic problems are interesting only when there is no time to prearrange a secret.
--
Warning: On Lawn is a documented liar.
[ Parent ]
What about the size? (none / 0) (#41)
by Vesperto on Tue Oct 26, 2004 at 09:43:08 PM EST

The first thing it occurs to me about stego stuff is that you're stuffing something inside something else. If i eat, i get heavier. Then it dawns on me that you're actually replacing bits but yet if you compare the images you showed as examples, the more they're 'stegged', the heavier they get and the longer it takes to be downloaded. A meaningless picture is one thing, but a meaningless high-res pic is another.

Maybe i'm making no sense.
_____________________________
If you disagree post, don't moderate.
Not a Premium User.

Agree- ish (none / 0) (#47)
by Nursie on Wed Oct 27, 2004 at 10:33:50 AM EST

He's just used bad example pics, when compressed in a lossless manor (png is lossless) the pics come out huge. It's just that the first picture is a jpg and as such is comparatively very lightweight.

Changing data as he has done in his examples doesn't necessarily add to the size of the image, it's just not helpful to compare jpg to png.

Meta Sigs suck.

[ Parent ]
Wrong (none / 0) (#54)
by rmn on Wed Oct 27, 2004 at 04:52:41 PM EST

No-one is changing the resolution of the images, or even making them bigger in terms of amount of image data. It's simply harder to (reliably) store data in files that use a lossy codec (like JPEG), so most solutions use lossless compressors (or no compression at all). As a result, the file gets bigger (compared to a JPEG), but the image itself is the same (same resolution, same amount of data, after decompression).

Some systems (ex., Digimarc) can store data in JPEG images (or other files with lossy compression), and can even resist a certain amount of image editing, but those algorithms are much more complex.

RMN
~~~

[ Parent ]

If the file gets bigger... (none / 0) (#56)
by Vesperto on Wed Oct 27, 2004 at 05:52:04 PM EST

...it kinda defeats the purpose of stego, that's what i was trying to point out, rader losely. A bigger file takes longer to download anyway. Eenee way, just passing by.
_____________________________
If you disagree post, don't moderate.
Not a Premium User.
[ Parent ]
But it doesn't (none / 0) (#65)
by rmn on Thu Oct 28, 2004 at 10:27:22 PM EST

But the file doesn't get bigger. The example is comparing a JPEG file to a PNG file. If you compare PNG to PNG, it stays pretty much the same size. And the same holds true if you compare a JPEG to a JPEG, but there you need much more advanced algorithms.

It's just a bad example, because it compares files with completely different (lossy vs. non-lossy) formats.

RMN
~~~

[ Parent ]

Others have corrected your other points (none / 0) (#68)
by Intelligentsia on Fri Oct 29, 2004 at 06:18:05 PM EST

but I just wanted to point out that the instant you concluded the pictures were "meaningless", the steganography did its job ;-) In that regard the file size is meaningless (unless the message is hidden in a stegged copy of a widely distributed file like a trojan).

We need to prove that we can spread rumors just like the mainstream media.—waxmop


[ Parent ]
Ninjas > Steganography (2.60 / 5) (#42)
by Cloud Cuckoo on Tue Oct 26, 2004 at 10:12:48 PM EST

when it comes to hiding in plain sight....and being cool.

Exactly (3.00 / 2) (#53)
by rmn on Wed Oct 27, 2004 at 04:45:43 PM EST

http://www.realultimatepower.net/

[ Parent ]
It seems I was wrong.. (3.00 / 2) (#44)
by ZeroesAndOnes on Wed Oct 27, 2004 at 05:06:06 AM EST

..when I thought (in the past) that steganography was the science of embedding messages in other messages in such a way that one could utterly deny the presence of the embedded message.

This has implications because (in my country at least) the legal-eagles can *require* you to divulge passwords to encrypted stuff, so to be able to claim plausibly that there is no message would get you off that particular hook.

Anyone care to enlighten me as to what I am talking about??

Also, someone's written a perl script to encode data in the ordering of html attributes, which I think is damn sweet.


0000 1001 1010 1101

That's definitely a form of steganography (none / 1) (#46)
by Nursie on Wed Oct 27, 2004 at 10:31:24 AM EST

it's just that steganography covers much more territory than that, it's basically the study of ways to hide data in other data.

Meta Sigs suck.

[ Parent ]
France? (3.00 / 3) (#60)
by gabban on Thu Oct 28, 2004 at 05:33:40 AM EST

One of the funnier implications of that law is that it basically forbids files with random numbers. Ok, perhaps not a big deal to most people, but muslims who are into scientific simulations should beware!

[ Parent ]
That could work too... (none / 0) (#77)
by twestgard on Wed Nov 17, 2004 at 09:25:27 PM EST

Imagine a website where the background images are .jpegs made through random number generation. The server constantly generates new, unique, meaningless bubbly grey backgrounds. Except, one of them is the pictorial version of an encoded message. It might perhaps be available only at a particular time, or under some other restricted protocol. That's open and deniable at the same time.

Besides, what counts as "deniable" if they're beating you to get the secrets out of you? At that point, you get into the utility of cells and so on. If they catch the only Keymaster you have, all the locks are gonna open.

Thomas Westgard
Illinois Mechanics Liens
[ Parent ]

Next step, informaton flood (none / 1) (#49)
by clambake on Wed Oct 27, 2004 at 11:26:37 AM EST

The flaw with steganography is simply that, if you are suspected, the message can be found and recovered.  The next step in the chain is information overload.  If you know you are suspected, forget encryption, send a million messages, each one with slightly different information.  Now THERE is hiding in plain sight...  :)

Recovered? (2.50 / 2) (#52)
by rmn on Wed Oct 27, 2004 at 04:42:15 PM EST

Nothing prevents you from encrypting the message before hiding it. The goal of steganography is not to replace encryption - it's not a way to make a message hard to decypher - it's (just) a way to make it hard to see there's any message at all.

RMN
~~~

[ Parent ]

And that helps you how? /nt (none / 1) (#58)
by skyknight on Wed Oct 27, 2004 at 09:54:15 PM EST



It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Hydan (3.00 / 2) (#59)
by Lemming on Thu Oct 28, 2004 at 05:30:17 AM EST

A nice steganography tool is Hydan, which embeds data into an executable by exploiting redundancy in the i386 instruction set. The functionality or filesize of the exe is not changed.

But wouldn't it be suspicious ... (none / 0) (#74)
by Chakotay on Wed Nov 03, 2004 at 10:23:52 AM EST

... if each time different instructions would be used to code the same (or similar) recurring operations? I would presume that a certain compiler would a certain way of compiling a certain operation, and would not arbitrarily switch between different synonymous operation sequences, and that a deviation from this would raise more than one eyebrow...

Though obviously, one still would have to be LOOKING for it to see it, because it's not something that'll jump up at you while just executing the programme...

--
Linux like wigwam. No windows, no gates, Apache inside.

[ Parent ]

Detectability versus message size (3.00 / 2) (#61)
by Gerhard on Thu Oct 28, 2004 at 06:37:50 AM EST

At eight bits per byte it is not really steganography anymore since the image data is being replaced and not altered.
If bytes are skipped between bit replace operations the changes become almost undetectable which is the most important aspect of steganography.

Correct (none / 1) (#63)
by scorbett on Thu Oct 28, 2004 at 11:22:54 AM EST

I only included that example to show what happens when you go too far.

I also considered adding a staggered pattern of embedded bytes, as you suggest, rather than simply stegging the secret message into the first N bytes of the container image, but I didn't want to overcomplicate things for the first release. If I ever do a version 2, I'll definitely add that capability.

[ Parent ]

File size (none / 1) (#64)
by Gerhard on Thu Oct 28, 2004 at 12:08:27 PM EST

Divide the file size with the message size. This wil allow you to get the optimum strategy for each message and automatic hiding and unhiding of the message. <1 means you need to do multiple Bit replacement.>1 means you can do byte skips.

[ Parent ]
During world war II (none / 1) (#62)
by Saggi on Thu Oct 28, 2004 at 09:57:07 AM EST

I once saw a letter in an museum. It was send from Germany to Denmark during world war II. The message was hidden within the lines - all you had to do was to read every secon line. Something like this:

The wonderfull
german soldiers are
kindly helping us
tracking down jews.
It is obvious
we need help
to catch everyone who tries
to save them.


See? The letter was quite long, and anyone opening it in order to read it would not suspect the real message.
So you don't need computers to hide messages in plain view. This was done with pen and paper.
:-)
-:) Oh no, not again.
www.rednebula.com
Just a thought (none / 1) (#66)
by godix on Fri Oct 29, 2004 at 01:21:20 AM EST

Anyone care to guess how long before Rusty puts 'YHBT YHL HAND' in the bridge on every page?


- An egotist is someone who thinks they're almost as good as I am.
complexity of Steganography (none / 0) (#67)
by little jackal on Fri Oct 29, 2004 at 12:08:59 PM EST

It seems to me that eventhough "stego" is a very interesting way of hiding data/information within other data, its complexity can be reduced to that of , say, the one-time pad. Essentially the problem is only as hard as find out the algorithm used to hide the data.
I haven't read on this subject outside of this article, but I think that because the strength of the algorithm lies in keeping the way the data is scattered, its weakness is also in the same thing. If the malicious party somehow finds out how this is done, then the "stego" is compromised. Obviously it would help if the original message was encrypted using conventional encryption before being scattered around- so to speak- but for an algorithm such as this to get wide use there has to be either:
  • secret algorithm used in placing the data OR
  • a variety of (possibly publicly available) methods that are then transmitted in secrecy to the receiving party
I know I'm probably missing some important aspects, so I would appreciate if someone enlightened me.

the shared gravitational mass would create a supercluster of obese bodies with all the remaining fit bodies orbiting around it. -skewedtree
you're quite right (none / 0) (#72)
by JyZude on Mon Nov 01, 2004 at 04:57:23 PM EST

In general you'd want to encrypt your message with GPG or something before steganographing it. This way even if the message is discovered, it would still be unreadable.

The trick of steganography is that you can put your message in a place where nobody else thinks to look for it. As an example, let's say you want to hide a message to someone but you are worried about some "big brother" agency spying on you. You encapsulate the GPG'd message in a JPEG image. Now what? Well, you can send the image to the recipient via e-mail. Unless big brother knows you are likely to use steganography, they won't have any reason to scan your images as opposed to anyone else's. The assumption is that they don't have the resources to scan all images sent by e-mail from everybody.

Even better, post your message to a newsgroup. There are many newsgroups filled with tens of thousands of JPEG images (yeah, yeah, most of it porn), so "big brother" won't be able to find your message amongst all the message-free images.

The trick is that you and the recipient have to agree beforehand how to find the steganographic message (i.e. a certain e-mail subject line, post subject, key words, etc.) The recipient must be able to find your message amongst all the other normal messages, while big brother must not be able to.

-----
k5 is not the new Adequacy k thnx bye


[ Parent ]
You could even (none / 0) (#75)
by xiox on Sat Nov 13, 2004 at 10:38:39 AM EST

You could even put your message in a standard HTML page. By changing the captialisation of the HTML tags, you could encode any short bit sequence. For example, bit 1 could be an upper case tag, and bit 0 could be lower case.

[ Parent ]
One Time Pads Work Very Well (none / 0) (#76)
by twestgard on Wed Nov 17, 2004 at 09:14:22 PM EST

The perceived complexity is only significant if your purpose is purely theoretical - as for effectiveness, complexity doesn't necessarily always accomplish that. Besides, the basic concept isn't terribly important until it's put into practice.

Combine this with other technologies - call your friend through VOIP and add a secret message in the audio feed that the receiving computer grabs. Imagine a dynamically-generated website that would produce different pages with different messages hidden in the background image, depending on what route you took there, which it reads through a cookie. You could make your website so that every file it generated had stego, but you had to know how to find the one that meant something.

One of the principles of security is that nothing is perfect, but it's worthwhile to make things harder. If I were going to put this into practice, I'd probably go through a list of disguise and encryption methods and combine three or four for a particular application and result. This concept is pretty cool - no doubt we'll get some export controls on it right away, so that American companies miss out on all the programming business the rest of the world will benefit from.

Thomas Westgard
Illinois Mechanics Liens
[ Parent ]

No mention of marutukku? (none / 1) (#73)
by karlandtanya on Tue Nov 02, 2004 at 02:28:47 PM EST

Used to be located at www.rubberhose.org.

This always struck me as the best method of crypto. Even when the bad guys have the all keys, they can't know that they have all the keys.

Strangely, the site is down and google doesn't know about it. Can't find the source code anywhere.

Well, almost anywhere. ;)

Marutukku (pronounced "rubberhose") is a crypto filesystem that mounts a partition as any one of several different virtual filesystems, depending on the key supplied. Here's the blurb from the developer(s):

Ordinarily best strategy for the rubber-hose wielder is to keep on beating keys out of (let us say, Alice) indefinitely till there are no keys left. However, and importantly, in Marutukku, *Alice* can never prove that she has handed over the last key. As Alice hands over more and more keys, her attackers can make observations like "the keys Alice has divulged correspond to 85% of the bits". However at no point can her attackers prove that the remaining 15% isn't simply unallocated space, and at no point can Alice, even if she wants to, divulge keys to 100% of the bits, in order to get the un-divulged portion down to 0%. An obvious point to make here is that fraction-of-total-data divulged is essentially meaningless, and both parties know it - the launch code extent may only take up .01% of the total bit-space.


Guess the k5 folks need the /. sig.

Thought you were smarter than that.

Oh, well.

If all you can complain about is the spelling, everyone assumes you support the content.

Danger of steganography (none / 0) (#78)
by dogeye on Fri Sep 23, 2005 at 01:56:32 AM EST

The danger of "hiding in plain sight, so to speak" is that if someone breaks your code, and you don't know it, you are making the job of spying on you easy.

The Science of Hiding in Plain Sight | 78 comments (53 topical, 25 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!