The expression security = usability-1 can be interpreted in many ways. Either things become far too complicated, so that regular users just don't want to be bothered with them or the amount of energy it takes to complete a security-related task is just insane.
To wipe a 1TB (1024GB) disk with random data or prep a disk for encryption, it takes a little more than 4 days (97 hours) when utilizing /dev/urandom. Who would want to wait 4 days for a supporting task like this to finish? Just considering the energy it takes, to keep the whole system up and running, only to write random data to a disk, clearly demands higher random data bitrates without sacrificing quality. Hardware-RNG's are good alternative but not always available, so you might want to give /dev/frandom a try.
/dev/frandom is a kernel module that claims to offer 10 times or more output bitrate than /dev/urandom - without a decrease of random data quality. The best way to verify this claim, is to try it out and test yourself. Just download, untar, compile and insmod the module, it usually works out-of-the-box.
make
insmod ./frandom.ko
In case of missing device nodes, create them manually:
mknod /dev/frandom c 235 11 chmod 444 /dev/frandom mknod /dev/erandom c 235 12 chmod 444 /dev/erandom
# Copyright 1999-2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
inherit eutils autotools
DESCRIPTION="
DieHarder This is the current snapshot of the dieharder random number
tester. It encapsulates all of the Gnu Scientific Library random num-
ber generators as well as /dev/random and /dev/urandom in a single har-
ness that can time them and subject them to various tests for random-
ness. These tests are variously drawn from George Marsaglia's 'Diehard
battery of random number tests', the NIST Statistical Test Suite, and
include a few useful e.g. binning or spectral tests that I've found
doing research into random number tests or tests that I myself have
made up or that are improvements on tests from other sources.
The primary point of this tester is to make it easy to time and test
(pseudo)random number generators OR hardware or other generators.
Three examples are provided of wrapping a random number generator and
inserting it so that it is can be called via the GSL interface. An
interface is planned that would allow random numbers to be read in from
a file, allowing the tool to be used with any generator (wrappable or
not) that can generate a table of random numbers.
Another important motivation for writing dieharder is to have the
entire test code and documentation be fully Gnu Public Licensed and
hence openly available for adaptation, testing, modification, including
the addition of new tests. The primary objections I have towards
diehard and sts are not that they are or are not adequate and complete;
it is that the code is obscure and not explicitly published for reuse.
It is my hope that by providing this tool in autodocumenting source, it
makes it easy to add new tests, critique older tests, and improve the
suite in general."
HOMEPAGE="http://www.phy.duke.edu/~rgb/General/dieharder.php"
SRC_URI="http://www.phy.duke.edu/~rgb/General/dieharder/${P}.tgz"
LICENSE="GPL-2" #GPL-2-Beverage
SLOT="0"
KEYWORDS="~x86 ~amd64"
IUSE=""
DEPEND="sci-libs/gsl"
RDEPEND="${DEPEND}"
src_unpack() {
unpack ${A}
cd "${S}"
eautoreconf
}
src_compile() {
econf || die "Error: econf failed!"
emake -j1 || die "Error: emake failed!"
}
src_install() {
emake install DESTDIR="${D}" || die "Install failed"
dodoc NEWS README* NOTES
docinto "dieharder"
dodoc dieharder/README dieharder/NOTES
docinto "libdieharder"
dodoc libdieharder/README libdieharder/NOTES
}
cat /dev/urandom | dieharder -a -g 200
# Run Details # Random number generator tested: stdin_input_raw # Samples per test pvalue = 100000 (test default is 100000) # P-values in final KS test = 100 (test default is 100) #================================================================== # Histogram of p-values ################################################################## # Counting histogram bins, binscale = 0.100000 # 20| | | | | | | | | | | # | | | | | | | | | | | # 18| | | | | | | | | | | # | | | | | | | | | | | # 16| | | | | | | | | | | # | | | | | | | | | | | # 14| | |****| | | | | | | | # | | |****| | |****| | | | | # 12| | |****| | |****| | | | | # | | |****| | |****| | | | | # 10|****| |****|****|****|****| | |****| | # |****|****|****|****|****|****|****|****|****| | # 8|****|****|****|****|****|****|****|****|****| | # |****|****|****|****|****|****|****|****|****| | # 6|****|****|****|****|****|****|****|****|****|****| # |****|****|****|****|****|****|****|****|****|****| # 4|****|****|****|****|****|****|****|****|****|****| # |****|****|****|****|****|****|****|****|****|****| # 2|****|****|****|****|****|****|****|****|****|****| # |****|****|****|****|****|****|****|****|****|****| # |-------------------------------------------------- # | 0.1| 0.2| 0.3| 0.4| 0.5| 0.6| 0.7| 0.8| 0.9| 1.0| #================================================================== # Results Kuiper KS: p = 0.97927058 Assessment: PASSED at > 5% for RGB Permutations Test real 1m7.539s user 0m13.536s sys 0m51.354s
cat /dev/frandom | dieharder -a -g 200
# Run Details # Random number generator tested: stdin_input_raw # Samples per test pvalue = 100000 (test default is 100000) # P-values in final KS test = 100 (test default is 100) #================================================================== # Histogram of p-values ################################################################## # Counting histogram bins, binscale = 0.100000 # 20| | | | | | | | | | | # | | | | | | | | | | | # 18| | | | | | | | | | | # | | | | | | | | | | | # 16| | | | | | | | | | | # | | | | | | | | | | | # 14| | | | | | | | | | | # | | | | | | | | | | | # 12| | | | |****| | | | | | # | | |****| |****|****| | |****|****| # 10|****|****|****| |****|****| | |****|****| # |****|****|****| |****|****| |****|****|****| # 8|****|****|****| |****|****|****|****|****|****| # |****|****|****|****|****|****|****|****|****|****| # 6|****|****|****|****|****|****|****|****|****|****| # |****|****|****|****|****|****|****|****|****|****| # 4|****|****|****|****|****|****|****|****|****|****| # |****|****|****|****|****|****|****|****|****|****| # 2|****|****|****|****|****|****|****|****|****|****| # |****|****|****|****|****|****|****|****|****|****| # |-------------------------------------------------- # | 0.1| 0.2| 0.3| 0.4| 0.5| 0.6| 0.7| 0.8| 0.9| 1.0| #================================================================== # Results Kuiper KS: p = 0.99947994 Assessment: PASSED at > 5% for RGB Bit Distribution Test real 0m15.707s user 0m13.545s sys 0m1.947s
Given a good kernel entropy source (try rng-tools), /dev/frandom delivered indeed 10 times the bitrate /dev/urandom could offer. The dd to fill the disk with random data leveled at about 3 Megabytes/s random data. Although a Hardware-RNG still would be preferable, /dev/frandom can fill a gap when high random data bitrates are needed. Compared to /dev/urandom, the f in /dev/frandom deserves the attributes fast and furious.