linux-kernel - [PATCH 07/14] random: exploit any extra entropy too when reseeding

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131215020121.GG27191@athena.dialup.mit.edu>
Date:	Sat, 14 Dec 2013 21:01:21 -0500
From:	Greg Price <price@....EDU>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	linux-kernel@...r.kernel.org
Subject: [PATCH 07/14] random: exploit any extra entropy too when reseeding

When extracting from the input pool to feed one of the output
pools, extracting more bytes can't hurt the reseed, and it can
help if there happens to be more entropy than we estimated.  We
deliberately try to be conservative in our estimates -- for
example, mixing in the cycle counter on each event but estimating
based on the low-resolution clock -- so this situation is likely.

For example, the authors of http://eprint.iacr.org/2012/251.pdf
found in a multi-week run on a desktop that the actual entropy
from add_input_randomness was much higher than our estimates,
at 9.69 bits min-entropy per event from the cycle counters alone
vs. 1.85 bits estimated.

The only reason to hold back is that we have to debit the input
pool's entropy estimate for every byte we extract, which may delay
us the next time we want to extract from the input pool.  But if
we're already leaving the pool practically empty, this isn't much
of a cost.  So go ahead and suck up two full extractions, 160 bits.
If we have even more than that and didn't know it, this should
still be a good solid seed.

We just have to make sure not to give ourselves credit for more
entropy than our sober estimates allow.  The credit_bits output
parameter takes care of that.

Signed-off-by: Greg Price <price@....edu>
---
 drivers/char/random.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index c11281551..c2428ecb2 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1001,6 +1001,13 @@ retry:
 		ibytes = 0;
 	if (credit_bits != NULL)
 		*credit_bits = ibytes * 8;
+	if (dest != NULL && ibytes && ibytes == have_bytes) {
+		/* When a reseed drains the pool, we might as well
+		 * suck up any underestimated entropy as well as what
+		 * we estimate is there. */
+		WARN_ON(credit_bits == NULL);
+		ibytes = max_t(size_t, ibytes, 2*EXTRACT_SIZE);
+	}
 	entropy_count = max_t(int, 0,
 			      entropy_count - (ibytes << (ENTROPY_SHIFT + 3)));
 	if (cmpxchg(&r->entropy_count, orig, entropy_count) != orig)
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/