9

Say you have a picture with 1 megapixels taken at random and with $2^{24}$ possible colours per pixel (RGB-24). That image would be unique and the possible combinations $(2^{24})^{10^6}$ immense.

However when taking a picture in the real world, say of a clear sky, there will be a lot of repetition.

The question is: would such repetition present a security risk when used as a one-time pad, where the requirements of randomness is so high?

My hunch is that it is, as true randomness would require the possibility of all pixels being #FF0020 or whatever, but I would like to be proven right or wrong.

If I've been unclear at some point, please let me know and I will edit my post.

Paŭlo Ebermann
  • 22,656
  • 7
  • 79
  • 117
youjustreadthis
  • 215
  • 2
  • 6
  • 1
    I am pretty sure that at 1MP it's "okay" if it's not truly random. Also, is it really "less random" or does it just have "less distribution"? –  Sep 07 '12 at 22:18
  • Oops, wrong click... And now I voted for a wrong comment.. Sorry – Alex Cohn Sep 10 '12 at 07:51
  • You need full control of the acquisition process in order to avoid fake images (as demonstrated by John Deters). You usually have better sources of random bits than camera. – Alex Cohn Sep 10 '12 at 07:54

6 Answers6

13

No. This is not safe. The one-time pad requires that the pad be generated by a true-random process, where each bit of the pad is chosen uniformly at random (0 or 1 with equal probability), independent of all other bits.

Any deviation from that, and what you haven't is no longer the one-time pad cryptosystem -- it is some kludgy thing. In particular, once you deviate from that requirement even a little bit (and you're talking about a huge deviation), you are skating on thin ice and there will probably be security problems with your scheme.

If you're gonna use the one-time pad, you gotta use it exactly as it is defined, with a truly-random pad. There are no shortcuts, no halfway stuff. Messing around with this sort of thing is exactly what enabled the US to cryptanalyze Soviet use of a "one-time pad" in the VENONA project.

But in practice, you probably don't want to use the one-time pad anyway. The key management issues are enough that it is rarely a good choice in practice.

D.W.
  • 36,365
  • 13
  • 102
  • 187
  • 1
    I see, so despite the ridiculous number of combinations the pixels in a photo provide, the fact that there is a limit at all, makes it insecure? I appologize if I seem a bit thick, but it's hard to understand how the scattering of light such as that picked up by a camera does not fill the above criteria. The thought was to reduce key generation time but now I'm all confused (that's a good thing though :) – youjustreadthis Sep 08 '12 at 01:10
  • Yes, it is insecure. The "number of configurations" is not the parameter that is relevant to security. The security of the one-time pad relies upon the requirement that the pad be truly random, with no patterns whatsoever. Violate that requirement, and it's not a one-time pad any longer. Anyway, the one-time pad is not really suitable for practical use in any case, so this is pretty much moot in practice anyway. Use modern crypto; its key generation time is negligible. – D.W. Sep 08 '12 at 01:13
  • I see, thanks for the help. I know that key distribution issues and practicality makes it outdated, but the concept of "perfect security" (at least the cryptological part) is intriguing. – youjustreadthis Sep 08 '12 at 01:31
8

You should not use the raw data of any image as a one time pad. This is even worse with an image of a sky, because of the large amount of blue pixels. For all images, adjacent pixels tend to be the same colour - which means there is a large amount of repetition.

If you want to use some of the data of the image as a one time pad, you will need to condition the data (concentrating the entropy present in the image).

A simple example of concentration of entropy is to take 2 not-so-random integers, a and b, and perform an operation, such as (a*b+a+b), then extracting the lower order bits (probably half). This scheme would eliminate bias present in the original integers. Of course, a more complex scheme is probably required.

A simple scheme you could use, which would be quite random, is to use a digest on the data. If for example, you believe that a third of the bits in the image contain useful entropy, then from every 64 pixels, containing 64*24 = 1536 bits, feed it into a SHA512 hash function, which will output a 512 bit digest (that is 64 bytes). You can then use that output for your one-time pad.

An IEEE article on Bull Mountain, Intel's Random Number Generator, includes some discussion on "concentration" of randomness, when the input data is not random enough.

ronalchn
  • 181
  • 1
  • 3
  • 5
  • 1
    Thanks for the thorough and useful answer. I do understand your point about repetition, however I'm not sure I managed to follow you on the useful entropy bit. Wouldn't the unpredictable nature of a large picture result in sufficient entropy for every bit involved, be it after a thorough shuffling or for example hashing pixel nr 1 with nr 10, 2 with 11 and so on? – youjustreadthis Sep 08 '12 at 00:01
  • 3
    I agree with the first paragraph, but the remaining paragraphs are problematic. Any scheme that begins with "take something not-so-random, then process it a bunch, and use it as a pad with the one-time pad" is deeply dubious, and probably violates all of the security benefits of a one-time pad. The main benefit of the one-time pad is it is "provably secure", but this only holds if the pad is truly random (all bits iid uniform random). If the pad is generated by taking something sorta-random and then processing them, the security proof no longer applies, and you're on sketchy ground. – D.W. Sep 08 '12 at 00:35
  • 2
    Fully random means having enough entropy for the number of bits. For example, if you have 10 bits of random data, it should have entropy equivalent to 10 bits. If you have instead 20 bits of data with entropy equivalent to 10 bits, it is not completely random. However, if you are able to shrink the data to 10 bits, so that it is 10 bits with 10 bits of entropy, it becomes fully random. – ronalchn Sep 08 '12 at 04:42
  • 1
    It means that even though the image might be 1MB, you do not have 1MB of fully random data, by concentrating the entropy down to say 100KB, you might then have random data. – ronalchn Sep 08 '12 at 04:43
  • 4
    This will only work if you have a good randomness extractor, which is not as trivial as you seem to think. – Paŭlo Ebermann Sep 08 '12 at 14:34
  • 1
    @PaŭloEbermann: Yes, Lavarand shows that, with (a) photographs that have adequate randomness, and (b) a good randomness extractor, one can produce excellent truly random numbers. – David Cary May 16 '13 at 11:34
3

The reason repetition is so dangerous is imagine trying to attack a worst case scenario: a BMP picture file that contains all black. The contents of the image file will be #000000 #000000 #000000 #000000 ... Now consider how a one-time pad works: it XORs the cleartext with the bit stream. So if your plaintext was "ATTACK ON 10 SEPT", and you XORed it with an image that started with some repeating black pixels, the resulting "cipher text" would be "ATTACK ON 10 SEPT". I wouldn't be surprised if your enemy is not surprised.

Any swath of repeating bytes in the key file will do the same. The attacker just has to try 255 guesses to look for stretches of intelligible ASCII text.

Long ago a friend of mine wrote a proxy that used XOR "encryption" like this. My first attempt to discover his key was to download a black .GIF file, and his "secret key" printed itself in front of my eyes.

John Deters
  • 3,728
  • 15
  • 29
  • 1
    ... although if the process involves controlled capture with an attached camera, the #000000 problem can be excluded. – Alex Cohn Sep 10 '12 at 07:50
  • 2
    @AlexCohn, certainly, a controlled environment can be different. That was the basis for LavaRand. But taking pictures of a stochastic system is different than taking random pictures, which is what the question was about. Regardless, you wouldn't use the photos of LavaRand directly anyway, as there was a lot of repeat in the background. LavaRand used the images as input to a hash, and derived relatively few bytes per frame from the pictures. – John Deters Sep 11 '12 at 03:54
  • 1
    methinks that taking random pictures should be OK. No way as a 1M3/28 random bits, but (wild guess) 256K random bits, provided the lighting conditions are in *natural* range. – Alex Cohn Sep 11 '12 at 06:15
3

The amount of randomness in common pictures has actually been studied thoroughly, just not for applications to encryption, but rather for stenography. An artifact of images is that the least significant bit (it is what changes between slightly different shades of blue) has the highest entropy.

A simple stego-system is to overwrite the least significant bits of a picture with, say, a ciphertext or key (both of which are random—either pseudo or truly random respectively), a compressed plaintext (high entropy) or a raw plaintext (which is of low entropy). In either case, it is generally practical to distinguish between the true distribution of LSBs of an image and either things of higher/lower entropy.

A consequence of this is that an image does not make a good one-time pad, as even the most random aspect of the image is not random enough.

PulpSpy
  • 8,617
  • 1
  • 30
  • 46
2

Great question. I had actually been thinking about the same thing some time ago, but I realized that using an image as a one-time pad isn't a good idea. Try to take some random pictures and then open the pictures with a hex editor (like XVI32). I did that and noticed that the bytes were not all that random, for example many picture files have a lot of 0x00 bytes. Even though this is only for a part of the picture, it would still give someone a head start on trying to decrypt.

Thomas
  • 1,174
  • 5
  • 16
  • 33
1

Photographs make perfect sources of randomness for OTPs. This question may be a little stale, but most of the answers here are wrong and it's an interest of mine.

One of the great questions facing Mankind is where to get entropy from? Entropy is a fundamental tenet of the Universe and is all around. It's just a question of getting at it. Since this is a photographic question, the following is an example of a typical cryptographic cat:-

a cat

The original unopened JPEG file is 3.4MB in size.

My best estimate via compression (fp8) of the entropy is 2.5MB. Let's be extremely clear - I'm compressing the original JPEG file without opening it. Never ever open a JPEG to measure entropy. You'll just measure the JPEG extraction algorithm and fall in to the entropy vs. complexity trap.

Let's be ultra conservative (and lazy) and use a safety factor of 2.5. It is impossible that compression will improve this much as all the latest compression tests already show a very pronounced asymptotic tendency. fp8 is amongst the best (non text specific) compression program available that you can compile reasonably easily .

So usable entropy of image = 1 MB.

You then extract 1MB of entropy using a simple extractor on the original (unopened) JPEG file. You can use:-

  • Multiple Pearson hashes
  • Large matrix extractor
  • Wide substitution & permutation network
  • SHA1 & counter based extractor

Each way will render the 1MB of pure entropy to use as a perfect OTP. This is sufficient for 7000 Twitter messages. Then you can take another photo for next month.

The reason this technique works perfectly is for two simple reasons:-

  1. Assume I didn't show you the photo. I just take a photo of something, extract the entropy and then eat the storage card. The cat is an example, please do not say that looks like my cat. You wouldn't know what the image was. It could be anything in the world, from any angle and under any lighting condition.
  2. The avalanche effect will ensure that even photographs that look identical to your eye will have entirely different extracted entropy sequences. And you have to factor in the sensor noise that makes unique all JPEG images ever taken by Man. All that's required is a single bit's difference in the unopened JPEG file.

Ultimately this relies on the entropy of your camera's viewpoint. And considering how many views there are on Earth, that's why photographs make perfect entropy sources for OTPs. This is trivially proven beyond doubt. I challenge anyone reading this to produce photo1 and photo2 where:-

SHA3-512(photo1.jpg) = SHA3-512(photo2.jpg)

EDIT.

As an exercise I did ent CUTE_CAT.JPG.fp8 which produced:-

Entropy = 7.999926 bits per byte.

Optimum compression would reduce the size of this 2503292 byte file 
by 0 percent.

Chi square distribution for 2503292 samples is 256.14, and randomly
would exceed this value 46.81 percent of the times.

Arithmetic mean value of data bytes is 127.4831 (127.5 = random).

Monte Carlo value for Pi is 3.140577400 (error 0.03 percent).

Serial correlation coefficient is -0.000503 (totally uncorrelated = 
0.0).

This is actually a very good prima facie pass for randomness. Even without the randomness extraction surprisingly.

Paul Uszak
  • 15,390
  • 2
  • 28
  • 77
  • I feel like you've got to do 'other stuff'. If you are using an image as a random noise source you can reverse how you steganography a picture, take blurry photos, use the least significant bits. – daniel Jun 13 '17 at 04:35
  • @daniel I'm sorry, I can't quite understand what you're getting at. Can you please expand your comment..? – Paul Uszak Jun 13 '17 at 12:44
  • I don't see in your method how one bit of your OTP is independent to all others. would you get some amount of pad from a completely white image? if you changed it to a completely white image but the first pixel is 1 shade darker does this generate a very different pad? This sounds like a hash, a PRNG with your image as a seed, not a TRNG. With other methods you could use the camera as a TRNG, shot noise could be sampled as a source of entropy. – daniel Jun 13 '17 at 14:47
  • @daniel You're correct, but. H(seed) = TRNG if entropy(seed) > entropy(out). By a factor of 2.5 in my cryptographic cat's example . This is how commercial TRNGs operate such as those by Quantique. Matrix multiplication in that case but that's materially a hash. You only need to rely on shot noise if you know what the photo's of. – Paul Uszak Jun 13 '17 at 23:01
  • I read that using hashes for whitening in TRNG has the possible disadvantage of hiding when the entropy source becomes unplugged, and I think that might be whats happening here, if the picture file was swapped out for a completely white image would the size of the generated random data drop? What if the image was a Mandelbrot set. The reason I think using the LSB of pixels of an image is better is because you can look at it and it looks like white noise, there's no patterns unlike in a full jpeg file. – daniel Jun 14 '17 at 01:06