Hardware random number generators in operating systems or standalone
components collect entropy from various random events mostly by using
-the (low bit of the) time an event occurs as a entropy source. The
+the (low bits of the) time an event occurs as an entropy source. The
entropy is merged into an entropy pool and in some implementations there
is some bookkeeping about the number of random bits available.
Virtual machines emulate some hardware components so that the
generated entropy is over-estimated. The most critical component that
has been shown to return wrong results in an emulated environment is the
-timing
-source\footnote{\url{http://jakob.engbloms.se/archives/1374},\url{https://polarssl.org/tech-updates/security-advisories/polarssl-security-advisory-2011-02}}.
+timing source\cite{Eng11,POL11}.
Typically the most vulnerable time where low-entropy situations occur is
shortly after a reboot. Unfortunately many operating system installers
-create cryptographic keys shortly after a
-reboot\footnote{\url{https://factorable.net/weakkeys12.extended.pdf}}.
+create cryptographic keys shortly after a reboot\cite{HDWH12}.
Another problem is that OpenSSL seeds its internal random generator only
seldomly from the hardware random number generator of the operating
system. This can lead to situations where a daemon that is started at a
time when entropy is low keeps this low-entropy situation for hours
-leading to predictable session
-keys\footnote{\url{https://factorable.net/weakkeys12.extended.pdf}}.
+leading to predictable session keys\cite{HDWH12}.
\subsection{Linux}
Unfortunately most crypto implementations are using \verb+/dev/urandom+
and can produce predictable random numbers if not enough entropy has
-been
-collected\footnote{\url{https://factorable.net/weakkeys12.extended.pdf}}.
+been collected\cite{HDWH12}.
Linux supports the injection of additional entropy into the entropy pool
via the device \verb+/dev/random+. On the one hand this is used for
(e.g. by writing to \verb+/dev/random+ on Linux) is recommended. Note
that only a process run as root can update the entropy counters in the
kernel, each non-root user-process can feed entropy to the pool but
-cannot update the
-counters\footnote{\url{https://en.wikipedia.org/wiki/dev/random}}.
+cannot update the counters\cite{Wikipedia:/dev/random}.
For Linux the \verb+haveged+
-implementation\footnote{\url{http://www.issihosts.com/haveged/}} based on the
-HAVEGE\footnote{\url{http://www.irisa.fr/caps/projects/hipsor/scripts/down.php?id=13781296\&ext=.pdf}}
+implementation\cite{HAV13a} based on the HAVEGE\cite{SS03}
strong random number generator currently looks like the best choice. It
can feed its generated entropy into the kernel entropy pool and recently
has grown a mechanism to monitor the quality of generated random
-numbers\footnote{\url{http://www.issihosts.com/haveged/ais31.html}}. The
-memory footprint may be too high for small embedded devices, though.
+numbers\cite{HAV13b}. The memory footprint may be too high for small
+embedded devices, though.
For systems where -- during the lifetime of the keys -- it is expected
that low-entropy situations occur, RSA keys should be preferred over DSA
attacker who can guess an ephemeral private key used in such a signature
can compromise the DSA secret key.
For RSA this can lead to discovery of encrypted plaintext or forged
-signatures but not to the compromise of the secret
-key\footnote{\url{https://factorable.net/weakkeys12.extended.pdf}}.
+signatures but not to the compromise of the secret key\cite{HDWH12}.
git.bettercrypto.org / ach-master.git / blobdiff