-1

A One Time Pad (OTP) sounds perfectly secure if we are to believe Wikipedia. But on the surface it also sounds ridiculously impractical - how does one securely distribute the OTP?

Idea: why not have someone distribute it for you in plain sight of everyone?

Presuming I can keep the details secret (as I would with an encryption key), if I wanted to communicate securely, why wouldn't I harvest the images from some source of abundant images (Facebook, news site, dating site, porn site, etc), and make use of the noise in their lower bits to create a one-time-pad?

Even assuming someone hacks my PC and can narrow down the image(s) I may have used, an image is not in itself an OTP - you need to extract the OTP bits from the image pixels. That can be done in an enormous number of ways. The secrets to doing it are more or less equivalent to conventional encryption keys.

E.g. I could shuffle the pixels in the chosen image before using them in one of N! possible shuffles for N pixels, which is enormous after even 50 pixels. I could also extract the OTP bits from the image pixels starting from any pixel and in a bunch of scanning directions/modes. And which bits do I use, and in which order? Plenty more permutations there to be guessed at by anyone wanting to crack my code.

Which raises a different possibility: why don't I distribute the algorithm for permuting the pixels and extracting the bits to create the OTP from a single image?

I'm suggesting this because I noticed a while ago that the original image posted on Wikipedia of the Mona Lisa happened to have prime numbers for its width and height. That sounds like a useful property to someone wanting to generate an OTP. You don't suppose someone is already using it for that, or some other cryptographic purpose, do you? After all, this image size is the only one that Wikipedia has repeated, which seems... improbable as a coincidence.

Yet all of this completely contravenes the advice of "don't roll your own". Does that advice still apply to an OTP that is truly only ever used once, even if its random bits are pseudo-randomly selected each time in one of extraordinarily many ways from a single source of truly random bits?

omatai
  • 131
  • 1

3 Answers3

3

Using public sources for key material is a well known concept. Book ciphers go way back.

But it is a mistake to think youre key is a largr OTP of random bits extracted from public source. The real key is the choice of images.

You and your partner will have to agree on a set of publicly available images to the basis for extracting bits. That is your key which you need to share somehow.

The possible number of images on the internet is significant and yet much less than two to the power of the number of random bits you plan on extracting. Furthermore you will probably not be able to select randomly from all images but rather be selecting from some image pool smaller than "the internet".

Adding an extra fixed permutation will add little extra security.

Meir Maor
  • 12,053
  • 1
  • 24
  • 55
0

The general idea in crypto is that the system is protected by the secrecy of the key, not the algoithn. Your proposed system requires that the algorithm for generating the key be kept secret.

There are simpler ways to do that, for example, given a seed value you could XOR the output of some selected DRBGs as the OTP. What’s secret then is the DRBGs used.

Swashbuckler
  • 2,126
  • 11
  • 8
-3

But on the surface it also sounds ridiculously impractical - how does one securely distribute the OTP?

This notion comes up frequently on this forum. Distribution is absolutely not ridiculously impractical. Key distribution is harder than other forms of cryptography, yes. But it's not insurmountable as the Wikipedia entry, history and your very existence post the Cuban Missile Crisis proves. The military do it with couriers and hardware fill devices full of key materials, diplomats do it with diplomatic pouches and spies did by just hiding a book full of key material on their person. Now they and you can simply transport a flash drive with enough material for billions of characters. A few years ago you could even listen to OPT messages being broadcast via public radio across the world.

Then there are more exotic key exchange mechanisms. Can a key exchange protocol exchange a one time pad instead of a key? suggests that it may be possible to simply generate/transmit the key between two parties using public key cryptography. I'm not convinced and the question remains open. And of course quantum key distribution networks do this as their raison d'être.

Authentication is also not an impediment to adoption. I don't know why people think that it is. Simply apply standard HMAC techniques to the message. You won't have perfect authentication security comparable to perfect secrecy of the OTP, but it will be at the same level as any other current HMAC technique. It will be a mathematically impossible to break message with currently impossible to break authentication.

And finally to the Mona Lisa. (I've never liked it). You may be able to eek out a few bits of entropy from various images here and there, but hardware random number generators are easy to buy and fairly simple to build. You can even use a webcam or camera phone and hash low light images. You can see the efficacy of this technique here. Or sit down in front of a Linux box and type:-

dd if=/dev/random bs=1 | xxd

Then do whatever you do with computers for the remainder of the day whilst watching true random numbers scroll down the terminal window. It's important you do things this way around as your interactions create the entropy that /dev/random then extracts. Redirect it as appropriate.

Paul Uszak
  • 15,905
  • 2
  • 32
  • 83