\documentstyle[12pt]{article}
\begin{document}
\bibliographystyle{plain}
\title{P1363: Appendix E\\Cryptographic Random Numbers}
\author{V1.0}
\date{November 11, 1995}
\maketitle
\section{Introduction}
Although the term is appropriate and is used in the field, the phrase
``random numbers'' can be misleading. To many people, it suggests random
number generator functions in the math libraries which come with one's
compiler. Such generator functions are insecure and to be avoided for
cryptographic purposes.
What one needs for cryptography is values which can not be guessed by an
adversary any more easily than by trying all possibilities [that is,
``brute force'']. There are several ways to acquire or generate such
values, but none of them is guaranteed. Therefore, selection of a random
number source is a matter of art and assumptions, as indicated below and in
the RFC on randomness by Eastlake, Crocker and Schiller\cite{RFC1750}.
\section{Need for random bits}
One needs random bits (or values) for several cryptographic purposes, but
the two most common are the generation of cryptographic keys (or passwords)
and the blinding of values in certain protocols.
\section{Criterion for a random source}
There are several definitions of randomness used by cryptographers, but
in general there is only one criterion for a random source -- that any
adversary with full knowledge of your software and hardware, the
money to build a matching computer and run tests with it, the ability to
plant bugs in your site, etc., must not know anything about the bits you
are to use next even if he knows all the bits you have used so far.
\section{Random Sources}
Random sources can be classified as either {\em true-random} or {\em
pseudo-random}. The latter are algorithms which immitate the former.
However, the concept of randomness is as much philosophical as physical or
mathematical and is far from resolved.
True-random sources can be considered unconditionally unguessable, even by
an adversary with infinite computing resources, while pseudo-random sources
are good only against computationally limited adversaries.
\subsection{True Random Sources}
The process to obtain true-random bits typically involves the following
steps.
\subsubsection{Harvest bits}
One first gathers some bits unknown to and unguessable by the adversary.
These must come from some I/O device\footnote{The alternative is for them
to be generated by program -- but we have assumed that the adversary knows
all our software and can therefore run the same program.}. Those
bits are not necessarily all independent. That is, one might be able to
predict some one harvested bit with probability greater than 1/2, given all
the others. The adversary might even know entire subsequences of the bits.
What is important is that the harvested bits contain information (entropy)
which is unavailable to the adversary.
\subsubsection{Determine entropy}
The second step is then to determine how many unguessable bits were thus
harvested. That is, one needs to know how many of the harvested bits are
independent and unguessable\footnote{With a proper hash function, it is not
necessary to know which of the bits are independent.}. This number of bits
is usually referred to as {\em entropy} and is defined below in detail.
\subsubsection{Reduce to independent bits}
As a third step, one can compute a hash of the harvested bits to reduce
them to independent, random bits. The hash function for this stage of
operation needs to have each output bit functionally dependent on all input
bits and functionally independent of all other output bits. Barring formal
analysis, we assume that the hash functions which are claimed to be
cryptographically strong (MD5 and SHA) have this characteristic.
The output of this third step is a set of independent, unguessable bits.
These can be used with confidence wherever random bits are called for,
subject of course to the assumptions involved in the three steps above.
\subsection{Pseudo-random Sources}
In some cases, one needs more random bits than the available sources of
entropy can provide. In such cases, one resorts to pseudo-random number
(bit) generators (PRNGs). A PRNG is a function which takes a certain
amount of true randomness (called the {\em seed} of the PRNG) and generates
a stream of bits which can be used as if they were true-random, assuming
the adversary is computationally limited and that the seed is large enough
to thwart brute force attacks by that adversary.
A cryptographically strong PRNG\footnote{as opposed to merely statistically
random sources like the C rand() function} is an algorithm for which it has
been proved that an opponent who knows the algorithm and all of its output
bits up to a certain point but not its seed, can not guess the next output
bit with any higher probability than \(\frac{1}{2}+\epsilon\) where
$\epsilon$ usually decreases exponentially with some security parameter,
$s$ (typically the length of the PRNG seed).
As with any computational complexity argument, such proofs are based on
assumptions (such as $P \neq NP$). A number of reasonable, strong PRNGs
are discussed in the literature. See the bibliography of this appendix as
well as \cite{RFC1750} for some of these references.
\section{Determination of bits of entropy}
\subsection{Mathematical Definitions}
For our purposes, entropy is the information delivered within a stream of
bits. It is defined as:
\[ H = - \sum_x p_x \log_2( p_x ) \]
where $x$ is a possible value in a stream of values (e.g., in this example,
a contiguous set of bits of some fixed size -- a byte, a word, 100 bytes,
...) and $p_x$ is its probability of occurrence (from an infinite
population of $x$ values, not just a finite sample). Typically, as the
values $x$ over which entropy is computed increase in size, the entropy
increases but not as rapidly as the size.
What we care about is entropy bits (unguessable bits) per bit of source.
So, let us also define an entropy rate, $J$, as
\[ J = \frac {H} {|x|} \]
where $|x|$ is the size of the symbol $x$ in bits. We can also define what
might be called the {\em absolute entropy}, $E$, as
\[ E = \min_{1 \leq |x| < \infty} J \]
the guaranteed minimum entropy (unguessability) per bit of source, no
matter what symbol size the adversary chooses.
This definition of $E$ relies heavily on having an infinite number of
infinite length sequences to analyze. For example, any periodic sequence
of bits will result in $E=0$ since when $|x|$ equals the period of the
sequence all the values (except for a set of measure 0) are the same and so
$H=0$. This means that any PRNG output will result in $E=0$ since a PRNG
is a finite state machine (FSM) and therefore forced to produce periodic
output. That finite period might be very long -- longer than any computer
could compute. Therefore, $E$ can not be computed,
numerically, from every actual sequence.
\subsection{Attempts to Compute $E$}
One is forced to compute an approximation of $E$ from actual bit strings.
Some people use the best available compression algorithm and hope that the
compression ratio approximates $E$, since if there were a perfect
compression algorithm, its output would have $E=1$ by definition. Others
define statistical tests\cite{Maurer91}, to be applied to an output bit
string from a hardware generator (such as a noisy resistor)
believed to have limited computational ability to fool the test.
If it were possible to compute an actual absolute entropy from a sample
string, the value would be the same no matter what the representation of
the sample string. That is, there are transformations of a string which
preserve all the string's information -- e.g., a Fourier transform,
Hadamard transform, difference operation
\[ y_i = x_i - x_{i-1} \]
etc. -- and the number of absolutely unguessable bits in a bit string must
be invariant under such transformations. One can therefore evaluate the
quality of some approximation of $E$ by performing the algorithm over
several transformations of the same string and comparing their results.
However one chooses to compute an approximation for $E$, one must further
reduce $E$ to reflect the fraction of these entropy bits which an
adversary might have acquired by guessing or measurement or bugging or
creating some bias in the generator process. For example, if one uses
a system date and time as a source of bits, then one can expect the
adversary to know the date and probably the hour and maybe the minute of
the value chosen -- leaving only a few low order bits as possibly hidden
from the adversary. If one uses room sounds between 14KHz and 19KHz as the
source, an adversary could inject sounds in that frequency range through
the room's windows and therefore bias the result. If one uses a
mouse-drawn signature as an entropy source, those elements of the track
which actually follow the person's signature are guessable by the
adversary, so only the noisy deviations from that track count as entropy.
If one uses disk head air turbulence\cite{DavisIhFe94} as a random source,
poorly designed system or application code could degrade the actual entropy
signal (e.g., through very coarse time measurements) and add significant
predictable noise to the air turbulence entropy (e.g., through interference
with disk completion interrupts by a non-random but random-looking system
interrupt), masking the real entropy and making it necessary to reduce $E$.
Once $E$ is computed to the designer's or user's satisfaction, with
whatever allowance one prefers for the possibility of bugging or creation
of bias, $E$ becomes the fraction of bits one can use of the source
stream. Specifically, if one is using a hash function to distill
independent bits from the source stream and that function produces
$K$ bits of output from each operation, one needs to feed the function
with $\frac{K}{E}$ bits of input from the source.
\section{Sources of Unguessable Values}
Almost any input source is a source of entropy. Some are better than
others in unguessability and in being hidden from an adversary. Each has
its own rate of entropy. Some possible sources at the time of this writing
are:
\begin{itemize}
\item {\bf radioactive source}, emitting particles to an absorbing
counter. There are radioactive monitors available which have RS232 output.
\item {\bf quantum effects in a semiconductor} (e.g.,
a noisy diode). Some of the popular hardware random bit sources use noisy
diodes or noisy resistors. These can be very cost effective.
\item {\bf photon polarization detection $45^o$ out of phase} -- a
source of quantum uncertainty which currently requires a laboratory
workbench.
\item {\bf unplugged microphone}. On some machines, an A-D converter with
an unplugged microphone yields electronic noise at a moderate rate.
\item {\bf air turbulence within a sealed disk drive, dedicated to this task}
\cite{DavisIhFe94}. This mechanism shows promise, if one dedicates a drive
to that task and has special system level software to harvest the entropy.
If this is attempted without a dedicated drive or special system software,
it becomes the measurement of I/O completion times for a disk in normal
use, which is mentioned below.
\item {\bf stereo microphones, subtracted}. In a noisy room with moving
sound sources, the difference between stereo microphones whose
amplification is normalized to minimize that difference signal, is
extremely difficult for an adversary to reconstruct, especially from a
single microphone in the same room.
\item {\bf microphone}. A normal mono microphone, in a room known not to
be bugged, will pick up a certain amount of usable entropy.
\item {\bf video camera}. A normal video camera can obtain entropy,
at a fairly low rate, if allowed to see unusual scenes (a person making
funny faces, unusual objects, ...) -- in a room with no video bugs.
\item {\bf timing between keystrokes} -- in which a user is asked to type
nonsense and the key stroke values are used along with the measured time
between strokes. Note that these times are quantized by system operations
and time resolution, so that $E$ must be computed for each particular
system.
\item {\bf mouse strokes and timing} -- e.g., if a user is asked to
use a mouse (or, even better, joystick) to sign his own name. This is
probably the most efficient of the human-driven sources of entropy.
\item {\bf /dev/random} -- a UNIX device
available under some systems which gathers entropy from system tables and
events not available to any user, so that if the adversary happens to be
running a process on your machine, the source entropy is still secret.
Note that the system programmer will have made some estimate of $E$ which
might not be correct, so that one might need to gather many /dev/random
bits and hash them down.
\end{itemize}
The examples below are used frequently as sources of entropy, but can have
serious flaws in that they are observable, predictable or subject to
influence by a determined adversary, especially if one is using a
time-shared computer. That makes the determination of
$E$ for these sources especially difficult.
\begin{itemize}
\item {\bf network statistics}
\item {\bf process statistics}
\item {\bf I/O completion timing and statistics}
\end{itemize}
The following are almost worthless as sources of entropy, but they tend to
be used by some because they are convenient.
\begin{itemize}
\item {\bf TV or radio broadcasts} -- the effective entropy of which
comes from any electrical noise which is local to the point of reception,
since the bulk of the signal is available to the adversary
\item {\bf published information on a CD or tape or in newspapers,
magazines or library books} -- likely to be worthless as entropy
since the adversary must be assumed to have access to the same publications.
\item {\bf system date and time} -- extremely low entropy
\item {\bf process runtime} -- probably worthless because a process
will make the call to fetch this runtime at the same runtime every time.
\item {\bf multiple, free-running ring oscillators} -- a hardware
version of an elementary PRNG, yielding a periodic sequence which might
look random locally while still being predictable.
\end{itemize}
\section{Expansion of source bits}
If one chooses not to use a proven cryptographically strong PRNG for
expansion of a true-random seed, there are techniques which are believed
good enough for PRNG use. Mistakes in these assumptions can lead to a
catastrophic reduction in security and any designer following this path
should be careful\footnote{One must be especially careful not to use a seed
too small or use too few true-random bits to form the seed.}.
These techniques amount to a one-way function masking some easily
predictable (weak) operation. That weak operation could be as simple as
counting or as complex as a long-period bit generator\cite{Marsaglia91}.
There are some commonly used function combinations:
\begin{itemize}
\item {\bf a cryptographically strong hash function (such as MD5 or SHA)}
computed over a true-random seed value concatenated with a counter which is
incremented for each operation. [For example, one could have 256 bits of
true-random seed and a 64-bit counter, all hashed by SHA for each 160 bits
(or fewer) of output, with the counter incremented by 1 for each output
batch.]
\item {\bf a strong encryption algorithm, using a true-random key} encrypting
a stream generated by a long-period bit generator which had been seeded by
a true-random value. [For example, one could have a
Marsaglia\cite{Marsaglia91} chain addition generator feeding 3-key
triple-DES in CBC mode.]
\item {\bf encryption of a counter with a true-random key} -- a simpler
version of the option above. One must be careful to use CBC mode and/or to
use only a fraction of the output block otherwise the output stream would
be recognizably non-random within on the order of the square root of the
counter period.
\item {\bf signature of a unique value.} This method, employed in TIS MOSS,
works for the generation of a session key which is to be transmitted
encrypted in a given public key. One assumes that the adversary does not
have access to the corresponding private key -- otherwise there is no
possibility of security. Therefore, one can take a value unique to that
private key (perhaps the date and time) and sign it with that private key,
yielding bits most of which are independent of each other and unknown to
the adversary. Those bits can be hashed down to form the session key.
\end{itemize}
\section{Assumptions}
Unfortunately, at our present level of knowledge, random number sources are
a matter of art more than science. We know that we can have adequate
random numbers if certain assumptions hold, but we don't know if those
assumptions can hold. Specifically, we can have true random numbers if:
\begin{itemize}
\item we are able to compute a lower bound on the absolute entropy of a source;
\item we are able to know an upper bound on the fraction of absolute entropy
known to or guessable by an adversary;
\item we have a hash function each of whose output bits is functionally
dependent on all input bits and functionally independent of all other
output bits
\end{itemize}
and we can have pseudo-random numbers if:
\begin{itemize}
\item we are able to obtain a full seed worth of true random numbers;
\item we have a one-way hash function or an unbreakable encryption function.
\end{itemize}
\section{Advice}
Stepping back from academic reasoning, there are some things to avoid and
some things which are definitely good to do.
\subsection{Things to avoid}
\begin{itemize}
\item {\bf Chaos equations} -- a great deal of hype confuses what looks
complex (therefore ``random'') to a human for something truly random.
\item {\bf math library ranno generators} -- these were never designed
to be cryptographically strong
\item {\bf Linear-congruential PRNGs} -- the simplest and possibly worst of the
math library PRNG algorithms
\item {\bf Chain addition} -- another simple and easily broken
statistical PRNG
\item {\bf CD ROMs, audio CDs or tapes}. Recorded material has a large
volume of bits and that volume is sometimes confused for randomness.
However, the number of bits it takes to index into all the published
recordings in the world (therefore the ``seed'' for this PRNG) is small
enough for an adversary to guess by brute force testing.
\item {\bf USENET News feed}. Again, high volume is confused with
randomness, by some. USENET is delivered everywhere and entropy delivered
to the adversary is useless.
\item {\bf E-mail} -- a potential source, if the e-mail is so well encrypted
that the adversary can not have seen it, but one doesn't know what the
adversary has seen. Otherwise, it is as useless as a USENET feed, since
the adversary can be assumed to have wiretaps in place. If any English
text is used as an entropy source, Shannon's estimate of 1 bit of entropy
per character should be a maximum limit for $E$.
\end{itemize}
\subsection{Things to do}
\begin{itemize}
\item {\bf Test for degeneration of the entropy source}. Devices fail.
If a source of entropy fails but is used to feed a cryptographically strong
function, the output of that function would not immediately signal a
problem to the normal user but could still provide an entry for the
cryptanalyst. One needs to test the raw entropy source
directly\cite{Maurer91} before it is hashed.
\item {\bf Mix different sources, if unsure about what the adversary might
tap}. If the adversary is assumed possibly to have tapped one or more
sources of entropy, but his having tapped any entropy source is assumed an
independent probabilistic event, one can reduce the probability that a tap
is successful by using multiple, independent sources of entropy, driving
each through its own harvesting and then hashing all the harvest results
together. The probability of adversary success is then the product of the
individual probabilities of tapping.
\item {\bf Feed all bits to the initial hash function rather than
try to throw away known bits}. If one's hash function meets the criteria
specified for reduction to independent random bits, then there is no reason
to use any other method for discarding dependent bits.
\end{itemize}
\nocite{ImpagliazzoLeLu89,BethDa90,BlumBlSh83,BlumBlSh86,BlumMi84,Boyar89}
\nocite{ChorGo85a,ChorGo88,DavisIhFe94,FairfieldMoCo85,Kaliski87,Kaliski88}
\nocite{Lagarias90,Levin85,Luby92,Maurer91,MaurerMa90a,MicaliSc88,ReifTy88}
\nocite{SanthaVa86,Shamir81,Shamir82a,Vazirani85,VaziraniVa84,VaziraniVa85}
\bibliography{crypto}
\end{document}