Here's a "random" post I made about adding 's ChaCha cipher implementation to condition the TRNG inside Precursor's FPGA. For those familiar with Linux, a TRNG's raw output is to /dev/random as a cipher-conditioner's output is to /dev/urandom.
bunniestudios.com/blog/?p=6126
Conversation
That doesn't sound right. Both Linux devices are conditioned, the difference is just that urandom doesn't block waiting for entropy. I assume your conditioner doesn't freewheel without input entropy, right? If so its output would be like /dev/random.
1
2
You can set a policy on how often entropy needs to be re-seeded into the conditioner. In practice, because the CPU runs relatively slowly on Precursor, and because there is a FIFO that feeds the conditioner, any practical policy never blocks.
1
1
That's just like running Linux with a decent hardware RNG, then /dev/random doesn't block either :)
2
1
Only ever blocks once in early boot for init now (if at all) and the kernel actively generates entropy rather than simply blocking. Same thing as getrandom with or without GRND_RANDOM which is now a no-op.
Only difference with /dev/urandom now is that unlike getrandom or /dev/random it prints a warning to the kernel log and doesn't block when the CSPRNG isn't initialized yet.
Even with the obsolete broken API design throttling output based on input, it was still a software CSPRNG.
Oh, did that finally get merged? Good riddance.
1
Yes, since Linux 5.6:
twitter.com/DanielMicay/st
Linux 5.4 added active seeding of the CSPRNG when it blocks.
/dev/random and getrandom are both completely sensible APIs now. Ideally, they would change /dev/urandom to do the same thing as /dev/random and getrandom though.
Quote Tweet
Linux 5.6 removed the cargo cult blocking CSPRNG.
/dev/random now works the same way as getrandom. It only blocks until CSPRNG is initialized after booting.
GRND_RANDOM flag for getrandom doesn't do anything anymore.
/dev/urandom still doesn't wait for CSPRNG initialization.
Show this thread
3