Slashdot Mirror

← Back to Stories (view on slashdot.org)

Exploiting Network Captures For Truer Randomness

Posted by timothy on from the when-lorem-ipsum-doesn't-cut-it dept.

First time accepted submitter ronaldm writes "As a composer who uses computers for anything and everything from engraving to live performance projects, it's periodically of some concern that computers do exactly what they're supposed to do — what they're told. Introducing imperfections into music to make it sound more 'natural' is nothing new: yet it still troubles me that picking up random data from /dev/random to do this is well, cheating. It's not random. It bugs me. So, short of bringing in and using an atomic source, here's a way to embrace natural randomness — and bring your packet captures to life!"

10 of 189 comments (clear)

  1. Random by somersault · · Score: 4, Insightful

    The imperfections in music aren't perfectly random either, so what's the big deal?

    --
    which is totally what she said
    1. Re:Random by PopeRatzo · · Score: 4, Insightful

      The imperfections in music aren't perfectly random either, so what's the big deal?

      Most insightful comment on this story. Period.

      Even if we could get perfect randomness in our art, it wouldn't really matter because the humans who see it or hear it will just try to impose some order on that randomness. It's what we do.

      Instead of randomness, what I seek to add to my sounds in the music I make is complexity. That's what makes for a rich sound.

      For example, if you look at the harmonics in a struck piano string or plucked guitar or bowed violin, they appear at predictable places. Now look at the harmonics in a free reed instrument, such as a chromatic harmonica. All sorts of weird places, strange ratios. It's what gives the chromatic such a distinctive, heart-rending timbre. Listen to the album Affinity by Bill Evans and Toots Theilemans and you can see why Evans decided to record his masterwork with a "trivial" instrument like the chromatic harp. It's basically a shaped noise generator with pitch.

      Similarly, listen to the digital sound used in "Sky Saw" in Brian Eno's Another Green World album. A simple waveform made extremely complex using god knows what filthy circuitry and it feels like someone is sticking the motor from a pair of hair clippers up your butt (not that I would know what that feels like since I would never, ever do such a thing since I turned 40).

      It can be easy, or hard, using pseudo-random algorithms in MaxDSP but it's the complexity that makes the sound do it's business. Except when it's simple, like a flute which is basically a sine wave. Oh never mind. I hate thinking about this stuff. It's a waste of time and I left my days as a theorist behind me. I'll let the young guys like the lad in the article worry about how pure the randomness is in the sounds he uses. It'll keep him occupied until inspiration comes along.

      --
      You are welcome on my lawn.
  2. What the cluck? by YodasEvilTwin · · Score: 5, Insightful

    Network captures do not embody "natural randomness". Packets are produced by computers too, not by the entropy of the universe or something. This guy has toked a little too much ganja. They're probably not even as random as a regular pseudorandom number generator. The latter makes some guarantees with regards to what you'll get out and ensures that no basic patterns are present. Network captures don't have these features. Depending on the computer, the network, and so on the incoming packets may be quite deliberate and ordered.

  3. /dev/random by Anonymous Coward · · Score: 3, Informative

    This seems like a fairly lame variant of the environmental entropy gathering which *is* what /dev/random does...

  4. not nearly as "random" as /dev/random by Dahamma · · Score: 5, Informative

    /dev/random on most OS'ed these days uses an entropy pool generated from a bunch of different sources - timing of keystrokes, mouse movements, disk seeking - and yes, network information. Then it uses cryptographic hashes on those.

    Your implementation basically uses one of those entropy sources, and then doesn't even hash it...

    1. Re:not nearly as "random" as /dev/random by gman003 · · Score: 5, Insightful

      In brief:

      "The generation of random numbers is too important to be left to chance."

      Anyone trying to create a new random number generator with the intent of producing more random numbers, without an extensive and specialized education, is guaranteed to fail.

  5. Confusion... by Junta · · Score: 3, Insightful

    /dev/random is about as random as you'll get. I presume your issue is that the pool is exhausted for the given desire. /dev/urandom is your endless of supply of 'good-enough' random for something like this. If your criticism is that it isn't really 'random', it's no less random than your pcap stream. Besides, given the application 'true' randomness will not be distinguishable from good pseudo-random.

    If you wanted to be random and artistic, then maybe point a webcam at a fireplace or something as an entropy source.

    --
    XML is like violence. If it doesn't solve the problem, use more.
    1. Re:Confusion... by ronaldm · · Score: 3, Informative

      I'm going to reply to just the one poster, as explaining this to each /.'r would take rather a long time! :)

      First and foremost, Slashdot (as you know) unfortunately chooses the URL for your particular story. "Truer[sic] Randomness" is not in fact what I'm going out to somehow magically solve (with my absolute non-background in cryptography etc.). As to why they chose to enter the title of the story as such - I don't know. A bit of sensationalism, perhaps? In any case, I'd originally titled this "Musical Network Captures" - no more, no less!

      Why not use /dev/random? It's not random per se which is required - it's a pseudo-random source which can still be directly influenced by those in the immediate environment. For installation purposes, for example, it's a quick (unorthodox, convoluted, fucked-up, whatever-you-wanna-call it) way of generating an input that can be used to further modulate other inputs/sounds. For this, a stream of random numbers alone is not good enough. There's a million and one ways this could have been done - it just so happens that this is how I decided I'd go about doing it.

      Finally, I'm a bit overwhelmed by the whole Slashdot thing. As it's all worked out, it seems that on my first 'go' at adding something that I thought a couple of people would be interested in, it's seemed to hit the front page - and so at least, next time, I'll know to not be so trigger-happy when I'm 'submitting' something to here! Apologies for all of you who seem to have fallen out with one another and spent half your time bickering over nothing.

      --R

  6. Mod parent up by impaledsunset · · Score: 3, Interesting

    /dev/random is already gathering environmental entropy from hardware sources and (except if you're running it on a virtual machine), it should produce data with good entropy that's truly random and is not comping from a pseudo RNG algorithm.

    Now, of course, if you XOR it with the network data you might increase entropy, but if it happens that /dev/random already uses it, you're not gaining anything, or in fact make things worse.

    But, please, if you think that /dev/random isn't providing data that's random enough, suggestions and patches would be welcome. Even if they don't get accepted in the mainline kernel, you can still distribute them.

    Another issue: I'd encrypt the data from the network source or XOR it with a pseudo RNG, because otherwise you might be leaking sensitive data through your "random" numbers.

  7. Re:If I would by JabberWokky · · Score: 5, Informative

    Actually, many people would sell you the answer. And they don't have nobel-prices[sic].

    See http://en.wikipedia.org/wiki/Hardware_random_number_generator for an overview of the devices you're looking for.

    --
    "$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien