lordmax

"Hackers, game, and crypto developers will enjoy “Resurrections” immensely. The general audience might have a more tepid reaction, since one has to be a coder to really get all the references and insider humor."

Far better solution IMHO built after industry discussion of "lava wall" years ago: https://bit.ly/3naYEBP Of course, by now we got hardware rng RPi, TrueRNG, security enclave rng - largely a solved problem on most of practical systems. just setup right, seed right and use `/dev/urandom`

best of twitter so far: "This simulation is getting so wild"

brilliant!

Look from the inside in the middle: https://www.nytimes.com/2020/04/03/us/politics/coronavirus-b...

I prefer to surface key data from article right upfront. WP title felt constructed to create a sense of clickbaity drama

The amount of schadenfreude for jerks in power who treat their own citizens as second class humans and just jet away to UK/France for an actual medical industry is +1000 XP points. Few other squalid oil dictatorships come to mind next...

Brave is just out of this world when it comes to ad-garbage heavy sites, like pretty much most news sites these days. Even when Unicorn stumbles, loading same page in Brave cleans all the garbage out like magic, product is just so freaking good.

I had accepted in my heart for a while we live in a simulation. Then it all makes sense and it is outrageously funny.

use Unicorn Blocker - I dont see any at all with it

nice!

btw I have RPI3 too, thanks for mentioning. it would be fun project to figure out can we reach true source on that chip. but 1,5Mpbs? highly suspect. they don't have space nor clock speed to sample so many true events on that tiny chip. need to dig into the Broadcom spec to find out more!

Here is the problem: most of these stats are not what they pretend to be (unless exact circuit / spec is published). Look at low level details of building say avalanche noise source: http://holdenc.altervista.org/avalanche/ - bandwidth is mostly bound by voltage/frequency/sampling resolution - how often you can trigger entropy event and how many of them in parallel? True result for one AN circuit: 2000 bits/sec.

What a lot of these vendors do is have some physical phenomena on the chip that feeds hardware "whitener" (endless hashing) that responds without blocking to all requests. That's practically hardware version of “/dev/urandom" that is bound only by chip IO - but its completely disconnected from bandwidth of actual “true” entropy phenomena underneath. of course it is still good CSRNG, but its not “true” source. btw nice exception: TrueRNG team are pretty honest providing direct schema - hence the real entropy speed of 40kb/sec.

In short every single entry on that list should be independent inspected down to specs and schema of whitener. If they are not publishing chip spec with exact details I highly highly doubt the bandwidth of “true” entropy events are really approaching GBps - this is the speed of whitener, not of actual generator.

The key property for crypto randomness here is that these high energy particle events (be that cosmic rays, background radiation, etc) are not just random, but independent from thermal noise. They are few and far between but they affect each sample somewhere. One way or another all that entropy will get hashed, and having even few bits that are contributed by independent phenomena makes final hash extremely hard to attack.

Considering all sources that contribute noise to sensors (thermal, light photons count, high energy particles, shot/RTS noise, and i'm probably missing a few), all with unique distributions and characteristics makes each sample readout very hard to predict.

DJB retort on this is now stuff of crypto hall of fame: https://gist.github.com/tarcieri/6347417#file-gistfile1-txt

> --- Cryptographers are certainly not responsible for this superstitious nonsense. Think about this for a moment: whoever wrote the /dev/random manual page seems to simultaneously believe that

   (1) we can't figure out how to deterministically expand one 256-bit
       /dev/random output into an endless stream of unpredictable keys
       (this is what we need from urandom), but

   (2) we _can_ figure out how to use a single key to safely encrypt
       many messages (this is what we need from SSL, PGP, etc.).

For a cryptographer this doesn't even pass the laugh test. --- <

worth mentioning (that sort of main premise of the article that gets a little bit unnoticed in all the methodology discussion): all existing HWRNG are relatively low bandwidth - because they are bound by physical process, rather then endless spinning up of /dev/urandom. They all have to wait for physics to produce each bit, and existing chips don't have that much "physics" in them.

The main novelty factor of "camera noise HRNG" is that we effectively leveraging 12M micro HRNGs in parallel - thats where that firehose of entropy is coming from.

I checked on that a while back as well. As far as i can find out SE HRNG is not exposed to user at all. It used internally in quite complicated process of secure booting and unlocking iOS device (there is an interesting presentation floating around with all details of reverse engineering of that process, and amount of security designed by Apple into their own hardware-to-hardware protocols is on very respectable level of insane). I think its likely SE HRNG is included in seeding /dev/urandom on iOS, so it is one of the most secure CSPRNGs around.

Do you have any references of existing code or research that deals with correlation issues? We considered few home grown ideas (like measuring correlation level in each sample and then compacting a sample by that % before quantizing) but all of them were pretty computationally heavy...

the preference for "blocking" /dev/random is one of these crypto-urban myths that is almost dispelled by now: https://www.2uo.de/myths-about-urandom/

you are completely correct - as I mentioned in the end this would be easier extractor: "Want to relax IID assumptions and avoid careful setup of a non-correlated quantizer? Easy — use any good universal hash function. The only new requirement is that the universal hash will require a one-time seed. We can make an easy assumption that the iPhone local state of /dev/urandom is totally independent from thermal noise camera is seeing, and simply pick that seed from everybody's favorite CSPRNG."

The main reason we went with VN instead of SHA or universal hash is just was more fun thing to build/experiment with. SHA is like flamethrower that will deal with anything you throw at it. VN is far more brittle and you see all mistakes in scenery or generation. Of course then you hash the output anyway before use!

my motivation from a while back was it would be so useful to have something that you can dump few megs of independent entropy into your /dev/urandom right before generating BTC/ssh keys. TrueRNG stick is also good, but just 40kb/sec (i have TrueRNG on cron job reseeding every hour anyway)

you are quite correct about this - "lens closed" mode has least amount of entropy by our measure. However its clearly proportional to intensity of light hitting the sensor (and beside natural photon variance of light itself, the shot noise in sensor increases with more light). So in what we call "optimal" conditions - enough light to generate noise, not enough to oversaturated there is plenty of natural entropy coming from the sensor.

That would be correct! However we getting values from raw camera video buffer before any compression takes place.

Matthew, there is my personal collection of entropy sources for your reference. That stuff is addictive!

- True quantum source: http://whitewoodsecurity.com/products/entropy-engine/

- Atmospheric noise: https://www.random.org/randomness/

- Avalanche Effect Generators http://holdenc.altervista.org/avalanche/ http://ubld.it/truerng_v3

- Great deck about overall entropy engineering https://www.blackhat.com/docs/us-15/materials/us-15-Potter-U...

And of course "lave wall" we mentioned just takes the cake: https://sploid.gizmodo.com/one-of-the-secrets-guarding-the-s...

Tech spec: http://bit.ly/nacl_relay_spec

Zax 2.0 updates: https://github.com/vault12/zax#-version-20-updates

Sandbox: https://zax-test.vault12.com

the article was mostly shared by Russian's themselves. I think they wanted for somebody to get this message out for them in light of recent events.

There is a massive amount of secondary evidence, all of which points in the same direction. Here is few research resources, unfortunately they are all in russian; perhaps google translate will recover enough meaning for it to be useful:

http://www.solonin.org/article_sbityiy-boing-medlenno-i-po http://www.echo.msk.ru/programs/code/1362312-echo/ http://gordonua.com/publications/Belkovskiy-Vse-plany-Putina... http://www.youtube.com/watch?v=MiZ43EunqvM http://www.youtube.com/watch?v=ludDRApl7nU

3 hours is upper bound and extremely friendly one to allow for all but hopelessly incompetent candidates. I did the test in less than 90 min. First 27 questions should take a competent hacker less than 20 min; rest of the time is for last 3 coding assignments.