Will random data appended to a JPG make it unusable?

Question

So, to simplify my life I want to be able to append from 1 to 7 additional characters on the end of some jpg images my program is processing*. These are dummy padding (fillers, etc - probably all 0x00) just to make the file size a multiple of 8 bytes for block encryption.

Having tried this out with a few programs, it appears they are fine with the additional characters, which occur after the FF D9 that specifies the end of the image - so it appears that the file format is well defined enough that the 'corruption' I'm adding at the end shouldn't matter.

I can always post process the files later if needed, but my preference is to do the simplest thing possible - which is to let them remain (I'm decrypting other file types and they won't mind, so having a special case is annoying).

I figure with all the talk of Steganography hullaballo years ago, someone has some input here...

(encryption processing by 8 byte blocks, I don't want to save pre-encrypted file size, so append 0x00 to input data, and leave them there after decoding)

Drown

Answer 1

No, you can add bits to the end of a jpg file, without making it unusable. The heading of the jpg file tells how to read it, so the program reading it will stop at the end of the jpg data.

In fact, people have hidden zip files inside jpg files by appending the zip data to the end of the jpg data. Because of the way these formats are structured, the resulting file is valid in either format.

Disclamation

unusable (which was the question) is not the same as reducing it's usability. Bit of a nickpick, I'll grant. But, an important distinction because it may be a viable solution. – Papal

Ok, I'm not sure that saying "without reducing its usability" could mean "make it unusable" but I will edit this just to make it more clear. – Disclamation

Answer 2

You can .. but the results may be unpredictable.

Even though there is enough information in the format to tell the client to ignore the extra data it is likely not a case the programmer tested for.

A paranoid program might look at the size, notice the discrepancy and decide it won't process your file because clearly it doesn't fully understand it. This is particularly likely when reading data from the web when random bytes in a file could be considered a security risk.

Deacon

Answer 3

You can embed your data in the XMP tag within a JPEG (or EXIF or IPTC fields for that matter). XMP is XML so you have a fair bit of flexibility there to do you own custom stuff.

It's probably not the simplest thing possible but putting your data here will maintain the integrity of the JPEG and require no "post processing".

You data will then show up in other imaging software such as PhotoShop, which may not be ideal.

Prosthodontist

Answer 4

As others have stated, you have no control how programs process image files and therefore some programs may find the images valid others may not.

However, there is a bigger issue here. Judging by your question, I'm deducing you're practicing "security through obscurity." It's widely considered a very bad practice. Use Google to find a plethora of articles about the topic.

Malvie

What indicates this? I'm using the TEA algorithm to encrypt the data, but it encrypts 8 bytes at a time. Rather than including meta data inside the encrypted file to tell me how big the original data was, I'm padding the original out to an 8 byte boundary, and leaving the padding in place. – Drown