[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: the calculus of encrypting non-textual data (was Re: concrete steps for improving apt downloading security and privacy)

Joel Rees dijo [Tue, Jul 08, 2014 at 11:11:09PM +0900]:
> >> Did you know that encrypting a picture sometimes results in a picture
> >> that looks like it has been through a random color-permuting filter?
> >
> > Can you proof it?
> Memory of coursework in encryption. The professor did some simple
> encryption on uncompressed images and showed how the results tended
> not to hide the things one would want hidden.
> Then he pointed out that the parts of an image with the most
> information are the parts that are least likely to compress. And he
> pointed out that standard encryption methods tend to be byte-oriented,
> for speed.

Well... Yes and no. Yes, that happens when you don't do it right.


If you implement the wrong mode of operation (schemes for the five
modes of operation shown in the next page), you end up with the
problem you mention. This result was achieved using the Electronic
Code Book (ECB). Now, the ECB mode should never be used twice for the
same plaintext blocks.

Oh, and as a sidenote for my images: They are *a bit* tricked. If you
apply ECB to a PNG image, as the PNG image is compressed, you will not
find this pattern. I saved the original image as a BMP, then ciphered
the image, and then copied over (prepended) the BMP header to the new
file; that's the reason for the file to be slightly right-shifted: It
contains a bit of unnecessary noise. But the effect *is* correct.

> He did not require us to do any homework on it, so I don't have any
> special tools in my notebooks. 30 years ago. Heh. The technology has
> changed somewhat since then, but I recently read about some standard
> encrypted sound files that were playable, noisy, but recognizable.
> Same principle.

It is very simple. The implementation is one page earlier in the
document I sent you. If you replace i.e. AES-128-ECB with AES-128-OFB
(and supply an initialization vector, which does not have such secrecy
requirements as the key).

Reply to: