From: Janne Johansson Subject: Re: Low Entropy at boot To: Sylvain Cc: tech@openbsd.org Date: Thu, 22 Aug 2024 08:34:50 +0200 Den ons 21 aug. 2024 kl 21:23 skrev Sylvain : > This is not an algorithm, it is really three programs running concurrently and using > unmitigated memory access in a clever way that allow imperfections in hardware to > be observed all the way into the software layer. > > I hope it can be useful. I don't think it is, at least not for that purpose. Apart from Theos correct comments on this being far too late in the game for stirring the kernel entropy pool, the program in itself has some issues. First of all, the comment below makes it slightly uncomfortable to know there should be a better list but we are to test this with "worse" constants? > //replace with large prime numbers between (2^63 > 2^64) for best results > int C4_hash_algo(volatile uint64_t * in, volatile uint64_t * out) { > uint64_t primes[128] = {2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, > 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97, 101, 103, 107, Secondly, and perhaps more importantly, it is dog slow. I tried it on a dual-core octeon (2x1GHz) and this is how top looks like while it runs: load averages: 2.91, 1.00, 0.38 edgepro.inet6.se 08:14:43 48 processes: 46 idle, 2 on processor up 8 days 18:00:32 CPU0 states: 99.0% user, 0.0% nice, 0.8% sys, 0.2% spin, 0.0% intr, 0.0% idle CPU1 states: 98.2% user, 0.0% nice, 1.8% sys, 0.0% spin, 0.0% intr, 0.0% idle Memory: Real: 286M/1480M act/tot Free: 6623M Cache: 1005M Swap: 0K/211M PID USERNAME PRI NICE SIZE RES STATE WAIT TIME CPU COMMAND 51096 jj 10 0 4448K 2320K onproc/1 nanoslp 2:51 191.94% thr-rng 72981 jj 2 0 5632K 6272K sleep/0 kqread 0:01 0.15% tmux It eats more or less both cores, and it takes the program ages to produce 32k of entropy $ ./thr-rng |dd of=/tmp/junk bs=4k count=8 32768 bytes transferred in 83.059 secs (394 bytes/sec) ..so there is no way I would wait long enough for this program to create 1M of entropy so one could feed it to DieHarder or some other entropy test suite just to validate how good or bad this is. With that in mind, even for userspace I think I will stick to the octrng0-assisted kernel entropy pool, which can give me these speeds instead: $ dd if=/dev/random of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 16.199 secs (66284451 bytes/sec) -- May the most significant bit of your life be positive.