[PATCH 3/5] crypt_make_salt(): simplify and improve

[Rasmus Villemoes]

The use of a PRNG here is useless. No matter what, the generated salt
string is completely determined by the initial value of x.

In fact, since we only look at bits 16-27 and it's a LCG with a
power-of-2 modulus (so the high bits never affect lower bits), only
2^28 different salts can be produced.

So instead of pretending to generate a random string, just
base64-encode the bits we actually have, and make sure all of them are
used. That way we can produce 2^32 instead of 2^28 different salts,
and it also becomes more transparent (due to the trailing '.'
characters from when x hits 0) that the salt generation is not
particularly thorough.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes at prevas.dk>
---
 libbb/pw_encrypt.c | 15 ++++-----------
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/libbb/pw_encrypt.c b/libbb/pw_encrypt.c
index 458792faa..9ac75b281 100644
--- a/libbb/pw_encrypt.c
+++ b/libbb/pw_encrypt.c
@@ -37,18 +37,11 @@ static int i64c(int i)
 int FAST_FUNC crypt_make_salt(char *p, int cnt)
 {
 	unsigned x = getpid() + monotonic_us();
+	/* Odd calling convention... */
+	cnt *= 2;
 	do {
-		/* x = (x*1664525 + 1013904223) % 2^32 generator is lame
-		 * (low-order bit is not "random", etc...),
-		 * but for our purposes it is good enough */
-		x = x*1664525 + 1013904223;
-		/* BTW, Park and Miller's "minimal standard generator" is
-		 * x = x*16807 % ((2^31)-1)
-		 * It has no problem with visibly alternating lowest bit
-		 * but is also weak in cryptographic sense + needs div,
-		 * which needs more code (and slower) on many CPUs */
-		*p++ = i64c(x >> 16);
-		*p++ = i64c(x >> 22);
+		*p++ = i64c(x);
+		x >>= 6;
 	} while (--cnt);
 	*p = '\0';
 	return x;
-- 
2.40.1.1.g1c60b9335d