Describe an effective and simple way to destroy data hiding in the jpeg DCT coef

Question

Describe an effective and simple way to destroy data hiding in the jpeg DCT coefficients without
directly modifying the values of the coefficients.

When hiding in the LSB of the DCT coefficients, you cannot hide in a coefficient that has a value of
positive one because _____ .

When hiding in the LSB of the DCT coefficients, why can you hide in a DCT coefficient with a value of
negative one?

When using the high-capacity DCT swap with too many pairs, the image is visually distorted in what
way?

If you are going to both compress and encrypt some data, why do you compress it first?

What is the underlying principal that makes the Huffman code effective?

Briefly describe how F5 alters the DCT coefficients. Which DCT coefficient values must F5 discard
and not use for hiding?

Explanation / Answer

Recently, reversible data hiding (RDH) techniques for JPEG images have become more extensively used to combine image and authentication information conveniently into one file. Although embedding data in JPEG image degrades visual quality and increases file size, it is proven to be useful for data communication and image authentication. In this paper, a data hiding method in JPEG image using a new coefficient selection technique is proposed. The proposed scheme embeds data using the histogram shifting (HS) method. According to the number of zero AC coefficients, block ordering is used to embed data first in the blocks causing less distortion. In order to further reduce the distortion, positions of AC coefficients are selected carefully. Finally, AC coefficients valued +1 and ?1 are used for embedding, and the remaining non-zero AC coefficients are shifted to the left or right directions according to their sign. Compared to the current state-of-the-art method, experimental results show that the proposed method has higher peak signal to noise ratio (PSNR) and smaller file size.

If your encryption algorithm is any good (and AES, with a proper chaining mode, is good), then no compressor will be able to shrink the encrypted text. Or, if you prefer it the other way round: if you succeed in compressing some encrypted text, then it is high time to question the quality of the encryption algorithm…

That is because the output of an encryption system should be indistinguishable from purely random data, even by a determined attacker. A compressor is not a malicious attacker, but it works by trying to find non-random patterns which it can represent with fewer bits. The compressor should not be able to find any such pattern in encrypted text.

So you should compress data first, then encrypt the result, not the other way round.

When compressing some particular data file, some prefix codes do better at compression than others. How do you decide which one to use? Which prefix code is the best for some particular data file?

The Huffman algorithm -- if you neglect the overhead of the Huffman frequency table -- chooses exactly the best prefix code for each data file. There is no singular "the" Huffman code that can be pre-generated without regard to the actual symbol frequencies. The prefix code choosen by the Huffman algorithm is usually different for different files.

The Huffman algorithm doesn't compress very well when we really do have 100,000+ unique elements -- the overhead of the Huffman frequency table becomes so large that we often can find some other "suboptimal" prefix code that actually gives better net compression. Or perhaps some entirely different data compression algorithm might work even better in your application.

The "Huffword" implementation seems to work with around 32,000 or so unique elements, but the overwhelming majority of Huffman code implementations I've seen work with around 257 unique elements (the 256 possible byte values, and the end-of-text indicator).

You might consider somehow storing your data on a disk in some raw "uncompressed" format. (With 100,000+ unique elements, you will inevitably end up storing many of those elements in 3 or more bytes). Those 257-value implementations of Huffman compression will be able to compress that file; they re-interpret the bytes of that file as 256 different symbols.

histogram values after applying the F5 algorithm with maximal possible message, or ? = 0.5 (stars), and the estimate of the cover image histogram (circles). The main reason why we decided to use histograms of individual low-frequency DCT coefficients rather than the global image histogram is as follows. Even with the low-pass pre-filtering, the spatial shift by 4 pixels introduces some non-zero coefficients in high frequencies due to the discontinuities at block boundaries. And the values that are most influenced are 0, 1, and –1, which are the most influential in our calculations. Individual histograms of low frequency coefficients are much less susceptible to this onset of spurious non-zero DCTs. Once the relative number of changes has been estimated, we may attempt to further estimate the total message length. Both the shrinkage and matrix embedding must be taken into account. Let n be the total number of changes in quantized DCT coefficients introduced by the F5 algorithm. We can write n as n = s + m , where s is the shrinkage (modifications that did not lead to message bits embedding), and m is the number of changes due to actual message bit embedding. The probability of selecting a coefficient that may lead to shrinkage is P S = h (1)/ P . Since the coefficients are selected at random, the expected value of s is nP

Related Questions

Navigate

• Browse (All)
• Browse D
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.