Ok hypothetical scenario. Lets say I want to generate a lot of key material quickly for a one-time pad. This key material will be divided up and used for many different messages in the future.

  1. I select 50-100+ songs out of a custom playlist of all my music. The music has been converted to basic Waveform Audio File Format (.wav). The music could be a mix of rock, pop, classical, techno etc just whatever I selected.

  2. I extract every song's raw music data out into one big file and remove null bytes. Now I have a single big file with all of the song data in it.

  3. I randomize all of the song data so all the song data is blended together into an unintelligible sequence of bits. The user can provide some input using their mouse/keyboard which will provide some entropy into the randomizing function.

  4. I loop through all the data in the file, taking every ~7th byte (or bit) and put it into another file which is now my new key material. This step could be altered so the user can provide a variable sample rate, e.g. they can change it to every 10th byte or 100th byte.

Now... is that file of key material sufficiently random for one-time pad use?

What about if I changed out music songs and use 10+ full length movies or TV shows instead?

  • 1
    $\begingroup$ The question in the title (is there enough entropy for a key?) does not match, at all, the first question in the body (can the output be used as OTP?); to the second I'd give a relatively clear no: if "extract every song's music data" was to 16-bit PCM format, then the MSByte of every sample is extremely biased. $\endgroup$ – fgrieu Nov 29 '12 at 11:00
  • 1
    $\begingroup$ Please do not deface your question - this is considered vandalism, just like when you did this editing someone else's post. If you want this question to be not anymore associated with your name, you can flag it ... the community managers (or maybe we moderators, but I'm not sure) can do this. We could also delete the question, but I think it is a fine question which is on-topic here, and has a good answer. $\endgroup$ – Paŭlo Ebermann Aug 25 '13 at 10:36

The bits are not independent from each other, at least within an individual song, so the pad is not truly random, thus this is not a one-time-pad. Perhaps a hash-based approach would fix this, but...

... there are a limited number of songs available, a simple attack would then be to enumerate every song (in the same format you describe) and try to decrypt a portion of the ciphertext (e.g. try bits 0 to 10, then try bits 1 to 11, etc... until you get something meaningful). Therefore the ciphertext can be broken by brute force, it is then not a one-time-pad by definition.

You'll notice your initial permutation had no effect on the efficiency of this attack. But even if it did, you must use some source of randomness to shuffle your song list, right? If you used a PRNG, someone could break that, and deduce the permutation you used. That's another dangerous "moving part". And if you had a true randomness source, then why not use it to create the pad in the first place?

Also, presumably you don't want to destroy your music after you've made it into a "one-time-pad", so your pad would also exist in its more explicit form on your hard drive -> big security risk (it considerably simplifies the attack above, as we now know exactly which songs to try to decrypt the ciphertext with).

Bits are bits, and entropy is entropy. It doesn't matter whether the data represents music or TV shows - those are human concepts whereas theoretical cryptography is intrinsically an abstract science.

  • 2
    $\begingroup$ @zuallauz 620 million is nothing in cryptography. And as I highlighted in my answer, the order of your song combination is irrelevant, as they are being concatenated - I can try and figure the position of each one, one after the other. I agree it wouldn't be easy (in human terms) but it is not a one-time-pad. It's just an overly complex and fragile cryptosystem (really hard to analyze, too). As for your second point, the content of songs are not random (as much as you would like them to be), so you cannot apply the equiprobable plaintext argument. $\endgroup$ – Thomas Nov 29 '12 at 4:43
  • 2
    $\begingroup$ @zuallauz: Please have a look at Kerkhoffs's principle for the assumption that the attacker knows the algorithm. $\endgroup$ – Paŭlo Ebermann Nov 29 '12 at 18:22
  • 1
    $\begingroup$ @zuallauz Then at this point, explain why not just use the entropy generated by the user to directly create the pad, instead of going through "tv/movie data"? $\endgroup$ – Thomas Nov 30 '12 at 2:13
  • 2
    $\begingroup$ @zuallauz "If the whole entropy is generated by the user, e.g. by moving my mouse around, tapping on the keyboard, pulling in data from /dev/random and even plugging in a random number generator dongle, how long would it take to make 200MB of usable random key material?" A very long time, but that is the price of unconditional security. Using existing data cannot by definition be considered an appropriate source of entropy (and especially not for a one-time-pad), no matter how ludicrously large this existing data is. It is the very definition of entropy. $\endgroup$ – Thomas Nov 30 '12 at 2:39
  • 1
    $\begingroup$ @zuallauz If your key is not cryptographically random, it is not a one-time pad. By definition. Full stop. Additionally, your PCM files will likely contain plenty of sequences of null bytes, which will leave segments of your data completely and obviously unencrypted (which will leak further information about the structure of the keys themselves). You are infinitely better off using less, but cryptographically random, key material and well-established symmetric encryption ciphers than using weak key material with a one-time pad. $\endgroup$ – Stephen Touset Nov 30 '12 at 20:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.