[PATCH 5/5] crypt_make_salt(): try to use actual random bytes for salt generation
Steffen Nurpmeso
steffen at sdaoden.eu
Tue Apr 16 18:00:25 UTC 2024
Rasmus Villemoes wrote in
<ab5109e4-2653-4da2-93b5-cf532f7b22d8 at prevas.dk>:
|On 15/04/2024 21.05, Steffen Nurpmeso wrote:
|> Rasmus Villemoes wrote in
|> <20240415125628.780178-6-rasmus.villemoes at 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-cf532f7b22d8 at 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)
More information about the busybox
mailing list