Ok my last mail, promised. Jason A. Donenfeld wrote in <cahmme9plfbpuayh+95wwwd4yjwduu7zjxq+gck3blgvdg5h...@mail.gmail.com>: .. |This reads as complete gibberish to me, sorry. Please stop with this \ |nonsense.
Like i said i think (in private?) i had only read the "Documentation and Analysis of the Linux Random Number Generator - Last updated: April 2020"[1] of the German Federal Office for Information Security. That has been a while. [1] https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/LinuxRNG/LinuxRNG_EN.pdf;jsessionid=80F4C63112E0E69603C67B4D454D07C2.internet482?__blob=publicationFile&v=1 |Denys - you see, this is what happens when you open the floodgates and |start trying to pick away at security properties in the service of 100 |bytes or something: you pretty quickly veer off into madness. So again You could temporary lock while /dev/u?random is written to via dd(1), maybe (if not done like this already) enforce reseed of "upper layers" (shall there be some) thereafter, so then all consumers were ensured to get the shiny hot new stuff only. (Like a mostly_read_only please_sync_on_reseed_lock.) I mean even super-async-systemd-startup has to sync on some important goals in the end. That is only me of course. A nice Sunday i wish, Ciao. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
