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.