Rasmus Villemoes wrote in <ab5109e4-2653-4da2-93b5-cf532f7b2...@prevas.dk>: |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.
Understandable. |Rasmus | --End of <ab5109e4-2653-4da2-93b5-cf532f7b2...@prevas.dk> --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