in reply to Re: Gif steganography
in thread Gif steganography

ahhh! i should have realised that compression bit.. now, how dumb do i feel?

As an alternative i could then convert the gif to a jpg, however wouldnt that be reasonably expensive for a web application?..

The reason i'm interested particularly in gifs is i have a CGI that generates a graph as a gif. What i need to be able to do is determine whether the generated graph is authentic (ie a user has not altered it..) As the website generates a reasonable amount of hits, what i cant do is store a digest anywhere..
i figure embedding a 'fingerprint' in the graph is a reasonable method of achieving this.

The next question is, what do i use as a message? i figure a SHA1 or MD5 digest seeded with a combination of the users name and a long, strong password, known only to administrators.

Replies are listed 'Best First'.
Re^3: Gif steganography
by tadman (Prior) on Aug 13, 2001 at 07:10 UTC
    If that's what you're trying to do, you needn't be so devious. Instead, I would suggest using a PGP-type signature and putting that in the "comment" field of the GIF file. When you validate the GIF for authenticity, you can strip the comment out and evaluate the image for integrity. The GIF comment field should be able to contain a regular signature, which is really just text.

    This way, if the image is modified, the comment signature will not check out, and since the signature is based on a private key that they don't have, they can't forge a new one. You could achieve the same thing with SHA1 or MD5 using a long and secure "passphrase" as well.

    JPEG, as I have tried to emphasise, is a very bad idea since the compression will pretty much destroy any subtle fingerprinting you do on a bit level. A more sophisticated "watermarking" technique is required in that case, and these are generally non-trivial to implement, as they often involve things like "fuzzy logic" to detect partial patterns, or to correct damage done by the JPEG compression.
[reply]

      The commet thingy sounds interesting, and makes a lot more sense than going around playing with file formats.. i'll go check it out.

      The gif->jpg transition would go something like:

      1. Generate gif
      2. Convert to jpg
      3. Bit fiddle
      4. send to browser

      The advantage i can see in this, is if the output jpg is modified the fingerprint is destroyed, hence the modified jpg is a fake.

      the downside is it's an expensive process..
[reply]
        Your proposed four step process might seem sensible, but the JPEG step is what is going to break it. Maybe I'm not being clear enough about what "bit fiddling" will do to your image.

        Since both JPEG and GIF, and for that matter, PNG are compressed, you cannot modify the bits and expect the image to still be decompressible. The modification must occur before the compression stage, on the bit-map data that is sent to be compressed. You would have the same trouble if you tried to apply your technique to a ZIP file, to "sign it", and when the user tried to decompress this damaged file, it would generate all sorts of CRC errors.

        First, GIF and PNG have the property that the image you put in, and the image you get out are identical, bit for bit. GIF is somewhat limited, because you can only have up to 256 colors (8-bit, indexed color) out of a possible 24-bit color space. PNG is better because you can have 16-bit or 24-bit images, but with the same "exact" decompression you'd expect from GIF.

        JPEG, on the other hand, always destroys some information in the process of compression. At maximum compression, the image turns into a huge smudge. At minimum compression, it might not look like much, but little 1 or 2 bit variations are eliminated from the image to achieve the compression. The higher the compression, the more the image is an approximation of the original.

        Here's a numeric representation of what might occur to an image: 
        Original      GIF         JPEG
--------    --------    --------
12141551    12141551    14141551
24140015    24140015    14140014
14140014    14140014    14140014
12230223    12230223    12220222

        [download]
        On the pixel level, the GIF and the original are identical, since there are only 6 different colors used here. The JPEG, though, by virtue of its "lossy" compression, results in a smeared image, where groups of similar pixels are averaged together to achieve compression. The subtle differences between two colors are often eliminated, or approximated using a pattern.

        GIF compression works on a bit level, removing redundancy using LZW data compression, the same sort of technique employed by the ZIP program. JPEG uses a more sophisticated form of compression that uses a Fourier transform, or in plain English, a technique that strips out information that is the least relevant. For instance, fine detail in the image is the first to go, and as the compression increases, the amount of detail you get decreases.

        A curious thing to note is that JPEG is specifically intended for use with images that are to be seen by the human eye. Since the human eye is not particularly good at distinguishing subtle changes in blue light, the blue in the RGB image is compressed much more than the other two more visible colors. You can see this if you split the image into different channels, such as in Photoshop.
[reply]
[d/l]

In Section Seekers of Perl Wisdom