Steganography is the term given to the art of hiding a message, for example in a photograph, in such a way that unless you know it’s there you wouldn’t suspect it was there.

While this is, to some extent, security through obscurity, it can be handy in some situations. Since a cursory look at the files will show something relatively innocuous (holiday snaps for example), an attacker may not notice the presence of the hidden data, and so move on without even attempting to break it.

There are many sophisticated technologies for doing this, however you can do a basic version using fairly standard unix tools.

Preparing your files

The first step is to encrypt your data.

To some extent, this is optional, however should your ruse be rumbled you can be sure that your precious data doesn’t fall into the wrong hands.

gpg -e -u "you@example.com" -r "them@example.com" businessplan.doc

Then, you compress the output using Zip. This is important, since unzip will ignore anything it doesn’t recognise as zipped data, which we’ll get onto later.

zip businessplan.zip businessplan.doc.gpg

Hiding your file

Hiding your file in an image is relatively straightforward.

cat photo.jpg businessplan.zip > myholiday.jpg

What’s happening here is that we’ve combined a photo and your encrypted zip file together into one file (order is important). Your image viewers will only see the first image file, and anyone looking at the directory will just see a (somewhat large) jpeg. If thumbnails are enabled you’ll just see the contents of photo.jpg.

Retrieving your file

To retrieve your file, all your recipient needs to do is run unzip the image file. Unzip will skip over the jpg content with a warning, and then reveal the hidden file. They then need to unencrypted it using their secret key.

unzip myholiday.jpg
gpg -d businessplan.doc.gpg > businessplan.doc

In conclusion

This technique will allow you to hide an encrypted file in a jpeg image, which affords you a certain amount of extra protection. Unless you know a particular image contains encrypted data (or suspect it might and look a little harder) then chances are the presence of the encrypted data won’t be discovered. However, this technique is probably pretty easy to spot if an attacker is looking for it, or performing any kind of data analysis on the file (or even looking at the file size, which could be a give away depending on how much data you’re hiding).

If you are a journalist carrying evidence of war crimes or mass surveillance programs to Brazil, you are likely facing some highly skilled adversaries, so this technique is probably not suitable. But, if you’re a business person who wants to take your new business plan securely across a border without the hassle of possibly being detained and forced to decrypt the file, then this might be more useful.

In any case, I thought it was pretty cool, and I thought I’d share.

If you’re like me, you have a number of servers running on the wider internet. These servers generate a whole bunch of system emails that are really valuable to an administrator to keep track of the health of their system, but could also give valuable and exploitable information about your system to the bad guys, and since many administrators automatically forward these emails to an external address, it’d be handy if they were automatically encrypted.

Thankfully, on unix at least, this is relatively straightforward.

Setting up an encrypted forward…

  1. Firstly, install the packages you need:

    apt-get install procmail gnupg

  2. Next, in the account you use to forward your email (usually root email is redirected to a non-privileged user, check /etc/aliases), install the public key of the account you’re forwarding messages to:

    gpg --import /path/to/public.key

  3. Now, install the following script in ~/.procmailrc:


    SUBJECT=`formail -xSubject:`
    FROM=`formail -xFrom:`
    :0 c
    *^To:.*root.*
    |formail -I "" | gpg --trust-model always -ear "you@example.com" | mail -r "$FROM" -s "$SUBJECT" you@example.com

If this works, you’ll have an unencrypted copy of the email left on the server, but anything that gets sent externally will be encrypted with your public key.

Thanks to DRG, for the original script for this, which I modified.

Just a quick update to point you good folk over to a couple of Idno plugins I’ve put up on github.

The first, LoginSyslog, is a simple plugin that outputs login events (success and failure) to the Auth.log, in much the same way as my Elgg fail2ban plugin. This allows you to audit login attempts on your Idno site, as well as use a tool like fail2ban to protect your site from brute force attacks.

The second, Pingback, adds support for incoming Pingback. Idno primarily supports webmention as a notification mechanism, and while legacy support for outgoing pingbacks, however incoming pingback support was missing. This plugin adds the missing functionality, meaning your Idno site will play nicely with WordPress and similar.

Happy hacking!