On 15/04/2024 21.05, Steffen Nurpmeso wrote: > Rasmus Villemoes wrote in > <20240415125628.780178-6-rasmus.villem...@prevas.dk>: > |Instead of limiting the possible generated salts to 2^32 different > |ones, try to get some actual random bits and mix those in. Keep the > |old pseudo-random generation in place, so that even if > |open_read_close() fails or only returns a partial result, we're not > |doing any worse than previously. > | > |In fact, even with /dev/urandom being unavailable, this might still > |improve things a bit since whatever sort-of random content might be in > |the p buffer on entry is then mixed in. > > By that time i thought (completely unrelated with your work) that > the code from miscutils/seedrng.c which has a more broad view of > where to get random data from should possibly be generalized. > There are more than just one match for /dev/urandom, and they all > want some random bits.
Yeah, I know, I did go grepping for 'random' to see if bb already had some "gimme some random bytes" helper, and I've also sort-of followed the seedrng saga. But since there was no such helper, and just best-effort here is good enough for a significant improvement in the normal case, I just went with the oneliner open_read_close(), which is also used in generate_uuid() without checking the return value. If some common infrastructure for randomness should materialize, this can trivially be switched over. But I really didn't want to tie this series to creation of and bikeshedding over such infrastructure. Rasmus _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
