How can I generate cryptographic-quality 1/f noise, aka “pink noise”? 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.
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:


You're generating samples, so there's a Nyquist frequency, and no energy above it no matter what you do.
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:


http://tf.boulder.nist.gov/general/pdf/5.pdf
http://tf.boulder.nist.gov/general/pdf/190.pdf
http://tf.boulder.nist.gov/general/pdf/29.pdf
http://tf.boulder.nist.gov/general/pdf/2795.pdf


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.