Discussion
Having actually read Linux's implementation of /dev/{u,}random, rather than read about it, I'll synopsize:
It Blake2s hashes entropy as it arrives, possibly with Half-SipHash when it wants to avoid grabbing locks.
ChaCha20 extrapolates additional randomness from that hash. Whilst an atomic counter decides when to mix in more of that entropy & when /dev/random should unblock.
They used other techniques in the past, but cryptographers today vouch for this.
1/3?
How'd I incorporate this into my hypothetical string-centric computer? Given it'd be vital for the intended use of internet-communication!
Our CPU's microkernel-mainloop in its firmware would invoke it for all external-interrupts feeding in the time. So I'd include Blake2s in that firmware.
It'd run in its "Arithmetic Core" coprocessor, a bare bones 16bit processor I designed. In a special mode for managing globals whilst the computers on (or even, for the clock, when its off).
2/3?
I count (out of curiosity) that Blake2s would require half a KiB of add, compare, bitshift, bitwise, memory, & branching operations. Mostly due to implementing a 32bit hash function on a 16bit machine. On the flipside the code would compress into ROM well!
This would be with including an auto-increment mode on the read-pointer. And I haven't proposed yet adding a couple modes for "alternate" registers & memory-access.
3/3!
Install bonfire.cafe
Get the full app experience
