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.villem...@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
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
