linux-kernel - [PATCH v4 0/3] random: Account for entropy loss due to overwrites

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-next>] [day] [month] [year] [list]

Date:	Mon,  9 Sep 2013 00:54:46 -0700
From:	"H. Peter Anvin" <hpa@...ux.intel.com>
To:	"Ted Ts'o" <tytso@....edu>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	DJ Johnston <dj.johnston@...el.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jiri Kosina <jkosina@...e.cz>,
	"H. Peter Anvin" <hpa@...or.com>,
	"H. Peter Anvin" <hpa@...ux.intel.com>
Subject: [PATCH v4 0/3] random: Account for entropy loss due to overwrites

From: "H. Peter Anvin" <hpa@...ux.intel.com>

[ Resending due to fumble-fingering vger.kernel.org. Sorry about that. ]

Version 4: my attempt at rebasing this patchset on top of 3.11, with
its changes to use cmpxchg.  I believe my adaptions are correct, but I
have not had the time to test them extensively.

When we write entropy into a non-empty pool, we currently don't
account at all for the fact that we will probabilistically overwrite
some of the entropy in that pool.  This means that unless the pool is
fully empty, we are currently *guaranteed* to overestimate the amount
of entropy in the pool!

This version of the patchset avoids manually duplicating information
by using a macro.  This removes *all* dynamic computation of derived
pool information and replaces them with static information: on just
about every architecture accessing pointer+offset is no more expensive
than just plain pointer, and this lets us get the information we
actually need from the start.

This version of the patchset adds handling of fractional bits, so that
we can continue to add a single bit of entropy without it being
rounded down to zero.  This version has 3 bits of fraction, which
means that with a 4096-bit input pool the multiply still cannot
overflow 32 bits; if we want to add the capability of crediting
fractional bits of entropy, which may be useful in itself, then we
probably need more bits of fraction and would have to use a 64-bit
multiply and shift.
--
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/