But what about encrypting the image data itself, the pixels, rather than the file as a whole? That can certainly be done, but using a standard encryption algorithm would only make sense with an uncompressed format that stores raw data (like BMP), because otherwise the compression algorithm would likely perform poorly on the encrypted data, and in the case of lossy compression, it would mess it up. Also, depending on the cipher, the encrypted data (ciphertext) might be longer than the original (due to padding), and that would mess up the image or require a change in dimensions.

Since standard encryption algorithms cannot be used, alternative, graphical methods must be used instead. A quick google search for “image encryption” summons lots of results with (apparently) advanced stuff, but here I will discuss a very simple method I invented to “encrypt” images that has a few advantages. I write “encrypt”, in quotes, because this simple method is not cryptographically secure at all, but it may be used to prevent image hotlinking, or to make it hard for someone to steal (especially mass-steal) images from your server or app, etc. In fact, I came up with this technique while working on a game, to protect my artwork, because a few images from other apps of mine had been stolen, and I was a little paranoid back then.

Perhaps the best term to describe this method is scrambling rather than encryption. The idea is very simple: slice the image into small squares and shuffle them, making it look like an unsolved picture puzzle.

The shuffling has to look random, but it must be deterministic and repeatable in order to be easily reversible. This can be achieved with any PRNG (pseudo-random number generator), like the stock ones provided in most platforms (e.g Math.random() in JavaScript). The seed can be thought of as the “encryption” key: each seed number will yield a different block arrangement, and “decryption” is performed by reversing the shuffle process using the same seed.

There’s a problem, though: using stock random() functions will not work across platforms! Each language/platform may use a different algorithm –or different algorithm settings– and this may even happen within a single “platform”, as is the case with JavaScript in browsers (each one has a different Math.random() implementation).

The solution for this is simple: we just write our own PRNG! Since this method is not meant to be cryptographically secure, we can use a simple PRNG like an LCG (linear congruntial generator), which is really easy to code (it just involves a state variable, three carefully chosen constants, one multiplication, one addition, one modulus and one division). My Javascript version is:

var LCG = function(seed) {
  this.state = seed;
};
(function() {
  var m = 4294967296,
      a = 1664525,
      c = 1013904223;

  LCG.prototype.rand = function() {
    this.state = (this.state * a + c) % m;
    return this.state / m;
  }
})();

One last thing to consider is block size: how small should the squares be? It is clear that, the smaller they are, the harder it will be to reconstruct the image without the key, and that is visually intuitive: if we just slice an image into four quadrants, it’s trivial to figure out their order in one glance, as the image is still perfectly clear. If we split each quadrant into another four quadrants, and so on, it quickly becomes much harder to guess what it is you are looking at. The extreme case would be to use 1×1 blocks, effectively shuffling individual pixels into a big block of colourful noise.

As we shrink the blocks, however, two problems may arise. One is that the computational cost increases, but this may not be much of an issue, since it’ll probably be fast enough anyway. The real problem is image compression: the more the image looks like noise, the worse all algorithms will perform. This is because large solid color areas, repeating patterns or smooth transitions (which are features that different algorithms target or expect) will be destroyed.

I planned to use JPEG, and in that specific case, scrambling not only causes poor compression but may also introduce undesirable artifacts or noise in the image, particularly when low quality settings are used. Luckily, knowing a little about the internals of the JPEG algorithm allowed me to solve that problem: since JPEG slices the image in 8×8 squares (or 16×16, or 16×8 in some cases) and processes those independently, minimum interference is achieved by using 8 or 16 as the scrambler’s block size.

The following images illustrate all this. Consider this source image:

Its file size is 285.9 KB. Scrambling it with a block size of 4, we get this one:

which is pretty scrambled indeed (you can’t tell what the original image looked like). But this image has a file size of 566.8 KB. Twice as big! Here we observe the scrambling interefering with compression. On the other hand, if we use a block size of 8 to minimize interference, we get:

which is still pretty unintelligible, but has a file size of 286.2 KB. The size difference is now only just about 300 bytes!

You can try a demo, or check my JavaScript source code on GitHub. I adapted it from a previous ActionScript version I had written for my game.

While googling for different generators and their properties, I recently stumbled upon a website that describes a new algorithm and shows some comparisons between that novel approach and many other popular ones (including LCGs, Mersenne Twister, etc) on different quality metrics (statistical quality, prediction difficulty, time and space efficiency, and more). It’s called PCG, (Permuted Congruential Generator), and, judging by the comparisons shown there, it beats the crap out of most other generators!

What makes it so good? Well, as the site states, the PCG family combines properties not previously seen together in a single algorithm, including: small code size, low memory and CPU usage, powerful features (jump ahead, distance), low predictability, excellent performance in statistical tests, and a permissive open source license (the Apache license).

How does it achieve all that? Its power apparently comes from the combination of an LCG (Linear Congruential Generator) as its state-transition function (the function that dictates how the internal state changes every time a new number is returned) and a new technique called permutation functions on tuples as its output function (the one that turns the internal state into the actual random number returned).

LCG is one of the simplest and fastest algorithms known, and has some desirable features, but used on its own it has horrible statistical performance (among other drawbacks) . It seems that by combining it with a clever output function, though, an excellent generation scheme is achieved.

The website is full of interesting information and explanations, and you can download the full technical paper and the reference C/C++ implementations.