
The mystery of steganography - skilled
https://increment.com/security/mystery-of-steganography/
======
nemo1618
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](https://github.com/lukechampine/jsteg)

~~~
nobody271
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](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](https://github.com/SixLabors/ImageSharp)

~~~
nemo1618
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...](https://github.com/lukechampine/jsteg/commit/d35a0bb4e6c545d4f1dd2a28eee514228dab3409)

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

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

------
drenvuk
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?

~~~
aidenn0
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.

~~~
nobody271
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.

------
woliveirajr
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 :)

~~~
yesenadam
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.

------
man-and-laptop
Steganography is a way to defend against rubber-hose cryptanalysis. See
"Security": [https://xkcd.com/538/](https://xkcd.com/538/)

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

~~~
crankylinuxuser
StegFS existed back in the kernel 2.4 days as a variant of ext2.
[https://en.wikipedia.org/wiki/StegFS](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.

