The mystery of steganography | Hacker News Reader

The mystery of steganography

increment.com

63 pointsskilled11 comments

If you'd like to try doing some steganography yourself, I wrote a simple tool for hiding data in JPEGs: https://github.com/lukechampine/jsteg

Did you manually implement the jpeg file format? How did you get it to save without jpeg compression overwriting your bits? I'm working on a similar project https://github.com/smchughinfo/steganographyjr but so far only png files work. I think it would be nice to manually implement gifs and jpegs but they are not easy algorithms and I suspect there are multiple flavors of each so it just seems like a huge undertaking. ...i will probably try ImageSharp https://github.com/SixLabors/ImageSharp

I copied most of the implementation from the Go standard library. The actual diff required to implement the steganography is very small: https://github.com/lukechampine/jsteg/commit/d35a0bb4e6c545d...

Re-encoding the JPEG will destroy the hidden bits, so it's very fragile.

You can make it less fragile with a significant loss of bandwidth.

The great thing about steganography is that as long as information is expected to arrive unmolested and unchanged you can't defeat it - at least as long as encryption is used along side it. Lets say you have an image, maybe lena.jpg or whatever, it's difficult to find out whether the image contains a hidden message or is an 'original' or has even been degraded because people don't know how to use photoshop/gimp/mspaint or what have you. If you want to store that image on a public site to contact other people in your league of evil doers then the it's easy enough as long as you're following the same protocol, they know where to look, how to look and have the keys to make it not look like garbage. The problem lies in the destruction of the data. In the case of storing an image on a public site with a hidden message, even if that message isn't just LSB but maybe you're doing fun stuff in the frequency domain the site would need to degrade the image in a way that destroys the message. imgur already alters images but there are some techniques that work even when resolution is reduced or the format changes.

At some point in the future you can bet your ass that there's going to be a country that implements mandatory filters on uploaded images that destroy any numerical data that could be encoded into them if it's uploaded by an anonymous user. It's too dangerous otherwise (lol).

There are some papers on it that I haven't read yet which may provide a generic attack that preserves image quality but what about audio? Video? Typos in web novels, ebooks? The list goes on. You can hide your info anywhere. I'm waiting for a future where there's an addon for pgp that takes images as an input and outputs something that looks normal instead of just proudly stating you can't see what I'm saying haha. The best defense is one that isn't seen right?

I am not a cryptographer; perhaps someone who is can comment on my thoughts here?

The flip side is that standardized steganography is far less effective. If you write "FooSteg" that can embed messages in jpeg files, I can probably write "FooStegStripper" that can remove messages encoded with FooSteg.

A counterargument is that it's trivial to write a steganography program if someone doesn't think you're using steganography, but it's much harder to not leave a statistical signal if someone is looking for (an unknown) stegnanography. Tools that are sufficiently good enough to defeat generic analysis are hard enough that the ease of which known steganographic tools are defeated becomes an issue.

The main thing is encryption. Before you write anything to the image you encrypt it. That way even if someone does manage to recover all of the bits that you write they still can't read them (because they're encrypted). So even standardized steganography will be as difficult to crack as the type of encryption that's used. But also, if you are encoding using the least significant bit (aka 1 bit per color channel per pixel) you can vary the order in which you encode the bits using the same password that is used for encryption.

I've heard it's possible to detect least significant bit steganography using statistics (like we've noticed the red channel varies from neighboring pixels more than usual) but even if that is possible, and I absolutely have doubts about that, there isn't any way to recover the sequence of pixels or decrypt it.

The beauty of steganography is that is satisfying the basic need of discretion: everyone has secrets (even silly ones) that we want to share with just a few people. Yes, kiddies: back in time there was no smartphone and no emails to teenagers to communicate, and even using "codes" to write to friends was embarrassing because everyone would see that you were hiding something.

Then a whole world of steganography appears :)

Well, there was writing in invisible ink (e.g. lemon juice) in the whitespace of apparently normal letters. Or having the first word of each sentence spell your secret message. Etc.

Which reminds me, when at school we had code-names for various drugs so they could be freely spoken of within earshot of anyone, including parents/teachers. Claude = cigarettes, Harry = alcohol, George = marijuana etc hehe. Worked very effectively.

Steganography is a way to defend against rubber-hose cryptanalysis. See "Security": https://xkcd.com/538/

Maybe in the future people will be using something like Rubberhose FS.

StegFS existed back in the kernel 2.4 days as a variant of ext2. https://en.wikipedia.org/wiki/StegFS

It is old and defunct, but this is a filesystem version of runlevel containers in an encrypted ext2 volume. Runlevel X can read all data at runlevel 0-X but not deeper. Typing in a "bad password" only lead to data corruption of existing data as there was no password check.

This provided plausible deniability in that I could have many runlevels, and "juicy" fake docs to lead people off the trail.

Reply on news.ycombinator.com