2
$\begingroup$

Can anyone suggest how I'd generate cryptographic quality 1/f noise: aka 'pink noise', where the PSD follows 1/f.

I'd be happy to derive the pink noise from white noise (e.g. /dev/urandom), but I don't want to filter it in a way that would compromise the quality of the noise. All the references to 1/f noise I can find are from the audio/dsp world where they tend to use very crude approximations to convert white noise to 1/f noise which would introduce unwanted patterns.

$\endgroup$
3
  • 2
    $\begingroup$ You question isnt well specifiedDefine unwanted pattern. Is the noise quantized? How? and what's the relevance to cryptography? $\endgroup$ – kodlu Apr 10 '16 at 20:23
  • $\begingroup$ A question of curiosity: If you already have a white noise, for what purposes of cryptography do you want to derive from it a pink noise? $\endgroup$ – Mok-Kong Shen Apr 12 '16 at 9:19
  • $\begingroup$ Please don’t get my comment wrong – but just in case you’re really focused on having direct access to pink noise for crypt-related or simple randomness purposes, you could always go build your own out of a pink noise generation circuit or two. Wrapping up such a pink noise generator is a fun hobby project that definitely won’t steal too much time. (And if all fails, you could simply go buy a pink noise generator… they’re not that expensive and available almost everywhere where you can buy decent electronic audio equipment.) $\endgroup$ – e-sushi Jun 13 '16 at 23:03
3
$\begingroup$

The problem with answering this question as posed is that one would need to have a definition of "cryptographic quality" that applies to 1/f noise. You'd need to talk about something like how many data points an intelligent adversary would need to observe to be able to distinguish your pseudorandom 1/f noise generator from truly random 1/f noise.

I suspect there isn't such a thing—in cryptography people normally want to transform non-white noises into white, not the other way around! If you're designing, say, a stream cipher, it'd be catastrophic if keystream bytes are closely correlated to their neighbors!

But to me it doesn't sound like your question is fundamentally cryptographic, but rather statistical, in that you'd be happy with an insecure solution as long as it passed certain statistical tests (that you don't define):

All the references to 1/f noise I can find are from the audio/dsp world where they tend to use very crude approximations to convert white noise to 1/f noise which would introduce unwanted patterns.

Without describing the patterns that you're seeing, it's hard to say anything. But from previous experience, the challenges I've seen with simulating 1/f noise on a computer are:

  1. You're generating samples, so there's a Nyquist frequency, and no energy above it no matter what you do.
  2. 1/f noise has progressively greater energy the lower down you look in the frequency spectrum. Audio guys have the advantage that humans can't hear below 20Hz, so they come up with algorithms that have a lower frequency cutoff.

I've had decent success with the randomized algorithm from this page (the randomized but unweighted version), as long as the number of octaves fits the application. But I can tell that the upper octave in that algorithm is consistently a bit whiter than it should be.

Other than that I think the best I can do is suggest that you look at publications from the time and frequency field instead of audio/DSP. For example, the NIST Time and Frequency Division has a lot of freely-available publications, some of which may be relevant:

You should have better luck with the time and frequency literature because they don't have a 20Hz cutoff escape hatch like the audio people do.

$\endgroup$

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.