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.

Signed-off-by: Rasmus Villemoes <rasmus.villem...@prevas.dk>
---
 libbb/pw_encrypt.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libbb/pw_encrypt.c b/libbb/pw_encrypt.c
index 3de31f711..cbb1f36f0 100644
--- a/libbb/pw_encrypt.c
+++ b/libbb/pw_encrypt.c
@@ -37,8 +37,10 @@ static int i64c(int i)
 int FAST_FUNC crypt_make_salt(char *p, int cnt)
 {
        unsigned x = getpid() + monotonic_us();
+       open_read_close("/dev/urandom", p, cnt);
        do {
-               *p++ = i64c(x);
+               *p = i64c(x + *p);
+               p++;
                x >>= 6;
        } while (--cnt);
        *p = '\0';
-- 
2.40.1.1.g1c60b9335d

_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Reply via email to