Am Dienstag, 28. Juli 2020, 22:40:44 CEST schrieb Pavel Machek: Hi Pavel, > Hi! > > > The following patch set provides a different approach to /dev/random which > > is called Linux Random Number Generator (LRNG) to collect entropy within > > the Linux kernel. The main improvements compared to the existing > > /dev/random is to provide sufficient entropy during boot time as well as > > in virtual environments and when using SSDs. A secondary design goal is > > to limit the impact of the entropy collection on massive parallel systems > > and also allow the use accelerated cryptographic primitives. Also, all > > steps of the entropic data processing are testable. > > That sounds good.. maybe too good. Where does LRNG get the entropy? That is > the part that should be carefully documented.. > > Pavel The entire description of the LRNG is given in [1]. [1] section 2.1 outlines the general architecture specifying that there are currently 3 noise sources. Per default, the interrupt-based noise source is the main source. Section 2.4 outlines the details of the interrupt noise source handling. The key now is unlike the existing implementation that there is no separate block/ HID noise collection because they are "just" derivatives of the interrupt noise source which would imply that noise events are double credited with entropy. This allows for a massively higher valuation of the entropy rate that exists in interrupt events. To support the design, a large scale noise source analysis is performed in chapter 3 [1]. Specifically sections 3.2.3 and 3.2.4 provide quantitative statements which are further analyzed in subsequent sections. This includes reboot tests as well as runtime tests. [1] appendix C performs these measurements on other CPU architectures, including very small environments which could be expected to have too little entropy (specifically the first listed ARM system mentioned there and the MIPS system are older embedded devices that yet show sufficient entropy). Also, the entropy available in virtual environments is shown in appendix C. The tools perform the aforementioned measurements are provided with the enabling of CONFIG_LRNG_RAW_ENTROPY supported by [2]. This allows everybody to re-perform the analysis on the system of his choice. Also, the entire entropy assessment of the LRNG is supported by the entropy analysis of the existing implementation in [3]. Specifically section 6.1 shows that the existing implementation has much more entropy available in the interrupt events than it credits. Yet, due to the design of the existing implementation with the fast pool (for which we have no assessment how much entropy is lost by it) and the fact of double counting of entropy with HID/ block devices, the massive underestimation of existing entropy with the existing /dev/random implementation is warranted. Lastly, [4] performs the entropy assessment of the existing /dev/random implementation in virtualized environments showing that still sufficient entropy is available in interrupt events supporting the approach taken in the LRNG. Writing the assessment of [4] was the initial trigger point for me to start the LRNG implementation. The second noise source that, however, is credited much less entropy is documented in [5] including its entropy assessment. [1] https://chronox.de/lrng/doc/lrng.pdf [2] https://chronox.de/lrng/lrng-tests-20200415.tar.xz [3] https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/ LinuxRNG/LinuxRNG_EN.pdf?__blob=publicationFile [4] https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Studien/ ZufallinVMS/Randomness-in-VMs.pdf?__blob=publicationFile [5] https://chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf Ciao Stephan