Am Mittwoch, 7. Oktober 2020, 06:24:09 CEST schrieb Eric Biggers: Hi Eric, > > Note that having multiple RNG implementations would cause fragmentation, > more maintenance burden, etc. So IMO, that should be a last resort. > Instead we should try to find an implementation that works for everyone. > I.e., at least to me, Nicolai's patchset seems more on the right track than > Stephan's patchset... Thank you for sharing your considerations. If you say that only one implementation should be there, I am wondering why not considering an implementation that as significant advantages over the existing implementation as outlined in my cover letter to patch v35. In the default configuration, it compiles no code at all that has any bearing on government standards. Yet it has a more cryptographic sound approach to handle entropy. In addition is meant to be extensible allowing each user to pick and chose what he wants. Yet, users who do not want these extensions should not suffer from it (neither performance-wise, nor should they suffer from an unnecessary complex code that builds all options into one C file). And speaking of fragmentation, if it is not *possible* to allow users to pick what they want and need (and yes, in some parts of the world or for some users these government standards are simply a necessity), we surely invite fragmentation. In the LRNG, I tried to have all operations critical to entropy compression and random number generation modularized so that the a can be replaced or extended if needed without fragmentation. PS: The reason why I started the LRNG was not government standards, but the result of performing two studies. The one study was about entropy in virtualized environment which showed that we have significant entropy in virtual environments and yet the existing /dev/random implementation thinks there is much less available. Another study I maintain for years also shows that the entire entropy collection and heuristic on bare metal systems is also in need of advancements. Initially I provided patches to the existing /dev/ random implementation, but basically all were silently ignored. Ciao Stephan