I don’t think there’s a fragile time window. We’re distrusting RDRAND already. Kernel will block
/dev/random until ready and of sufficient quality. Any new entropy gathering daemons could block booting until systemd
sysinit.target or something even earlier is done.
If we added extra entropy and credited it, the process will be faster but less secure. I don’t think we should make the process faster at the expense for higher risks. That would be possible but would require this solution to generate traction and peer review.
If we added extra entropy and credited it,
- in best case: entropy quality increases
- in worst case: we waste CPU cycles, increase lines of Whonix source code, waste time and accomplish no entropy quality increase but also no entropy quality degradation.
- Main goal: improve entropy quality
- Improving boot time (credit entropy): non-goal
- Not worsening boot time so that nobody wants to use Whonix anymore: goal
- Price to pay: slightly increased boot time / system load
Yes, additionally but not as a replacement. If I remember right, somewhere you wrote “our best bet is to make use of as many entropy sources as we can”? I very much agree with that still.
twuewand is truerand based. twuewand could be replaced with a different implementation based on truerand but better performance.
timer_entropyd by Van Heusden though is not truerand based. At least I cannot find any reference trivially to that in the source code.
clrngd fork is by Van Heusden is truerand based.
In conclusion: 1 implementation based on truerand and other entropy sources based on other devices (preferably) or other algorithms.