Difference between revisions of "Random number generation"

From ArchWiki
Jump to: navigation, search
(Add category.)
(merge (unchanged) from Securely wipe disk#Kernel built-in RNG)
Line 41: Line 41:
 
There are also [[Wikipedia:Cryptographically_secure_pseudorandom_number_generator|cryptographically secure pseudorandom number generator]]s
 
There are also [[Wikipedia:Cryptographically_secure_pseudorandom_number_generator|cryptographically secure pseudorandom number generator]]s
 
like [[Wikipedia:Yarrow_algorithm|Yarrow]] (FreeBSD/OS-X) or [[Wikipedia:Fortuna_(PRNG)|Fortuna]] (the intended successor of Yarrow).
 
like [[Wikipedia:Yarrow_algorithm|Yarrow]] (FreeBSD/OS-X) or [[Wikipedia:Fortuna_(PRNG)|Fortuna]] (the intended successor of Yarrow).
 +
 +
== Kernel built-in RNG ==
 +
{{Poor writing|Merged from [[Securely wipe disk]], will be integrated better into the article.}}
 +
The kernel build in RNG's [[random|/dev/{,u}random]] are highly recommended for producing reliable random data providing the same security level that is used for the creation of cryptographic keys.  The random number generator gathers environmental noise from device drivers and other sources into an entropy pool.
 +
 +
; /dev/random: uses an entropy pool of 4096 bits (512 Bytes) to generate random data and stops when the pool is exhausted until it get's (slowly) refilled. /dev/random is absolutely not designed for wiping entire HDD's, but rather to generate cryptographic keys (e.g. SSL/SSH).
 +
; /dev/urandom: reuses existing entropy pool data while the pool is replenished and although '''not''' suited for the most crucial cryptographic purposes, for example the generation of longterm keys, its quality should be sufficient for a paranoid disk wipe, [[#Preparations for block device encryption|preparing for block device encryption]], wiping LUKS keyslots, wiping single files and many other purposes.
 +
 +
One can compare the actual available entropy {{ic|/proc/sys/kernel/random/entropy_avail}} against {{ic|/proc/sys/kernel/random/poolsize}} to keep an eye on the entropy pool. More information on the kernel RNG is available via {{ic|man 4 random}}.
 +
 +
Apart from the applications discussed above there are others that depend on enough entropy being available, e.g. using the system as a wifi access point with encryption.
 +
 +
For much better performance to refill the entropy pool, one can consider using a pseudorandom number generator instead of the kernel, e.g. [[Frandom]].

Revision as of 11:19, 28 August 2013

The man random command will misdirect to the library function manpage random(3) while for information about the /dev/random device files you should run man 4 random to read random(4).

Entropy

Merge-arrows-2.pngThis article or section is a candidate for merging with Securely wipe disk#Kernel built-in RNG.Merge-arrows-2.png

Notes: What is specific to disk wiping should get merged there and deleted here. (Discuss in Talk:Random number generation#)

The Kernel built-in RNG /dev/random provides you the same quality random data you would use for keygeneration, but can be nearly impractical to use at least for wiping current HDD capacitys. What makes disk wiping take so long with is to wait for it to gather enough true entropy. In an entropy starved situation (e.g. remote server) this might never end while doing search operations on large directories or moving the mouse in X can slowly refill the entropy pool.

You can always compare /proc/sys/kernel/random/entropy_avail against /proc/sys/kernel/random/poolsize to keep an eye on your entropy pool.

The Kernels poolsize is 4096 bit. (512 Byte)

While Linux kernel 2.4 did have writable /proc-entries for controlling the entropy-poolsize in newer kernels only read_wakeup_threshold and write_wakeup_threshold are writable.

The pool size is now hardcoded in kernel line 275 of /drivers/char/random.c

/*
 * Configuration information
 */
#define INPUT_POOL_WORDS 128
#define OUTPUT_POOL_WORDS 32
#define SEC_XFER_SIZE 512
#[...]

where poolsize is 4096 = INPUT * OUTPUT

/dev/urandom

/dev/random uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This can make it impractical for overwriting large hard disks.

/dev/urandom in contrast will reuse entropy when low on it so you won't get stuck. Nevertheless it might still take a long time to bottle-feed the neverending surge of large drives with data.

The output may contain less entropy than the corresponding read from /dev/random. However it is still intended as a pseudorandom number generator suitable for most cryptographic purposes,

Warning: /dev/urandom is not recommended for the generation of long-term cryptographic keys.

Pseudorandom number generator

A Good Compromise between Performance and Security might be the use of a pseudorandom number generator (like Frandom).

There are also cryptographically secure pseudorandom number generators like Yarrow (FreeBSD/OS-X) or Fortuna (the intended successor of Yarrow).

Kernel built-in RNG

Tango-edit-clear.pngThis article or section needs language, wiki syntax or style improvements.Tango-edit-clear.png

Reason: Merged from Securely wipe disk, will be integrated better into the article. (Discuss in Talk:Random number generation#)

The kernel build in RNG's /dev/{,u}random are highly recommended for producing reliable random data providing the same security level that is used for the creation of cryptographic keys. The random number generator gathers environmental noise from device drivers and other sources into an entropy pool.

/dev/random
uses an entropy pool of 4096 bits (512 Bytes) to generate random data and stops when the pool is exhausted until it get's (slowly) refilled. /dev/random is absolutely not designed for wiping entire HDD's, but rather to generate cryptographic keys (e.g. SSL/SSH).
/dev/urandom
reuses existing entropy pool data while the pool is replenished and although not suited for the most crucial cryptographic purposes, for example the generation of longterm keys, its quality should be sufficient for a paranoid disk wipe, preparing for block device encryption, wiping LUKS keyslots, wiping single files and many other purposes.

One can compare the actual available entropy /proc/sys/kernel/random/entropy_avail against /proc/sys/kernel/random/poolsize to keep an eye on the entropy pool. More information on the kernel RNG is available via man 4 random.

Apart from the applications discussed above there are others that depend on enough entropy being available, e.g. using the system as a wifi access point with encryption.

For much better performance to refill the entropy pool, one can consider using a pseudorandom number generator instead of the kernel, e.g. Frandom.