remove dangerously out-of-date Linux/haveged info
authorAaron Zauner <azet@azet.org>
Sat, 6 May 2017 14:47:48 +0000 (16:47 +0200)
committerAaron Zauner <azet@azet.org>
Sat, 6 May 2017 14:50:02 +0000 (16:50 +0200)
src/theory/RNGs.tex
src/tools.tex

index a8e194f..9c6989f 100644 (file)
@@ -58,61 +58,6 @@ 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~\cite{HDWH12}.
 
-\subsection{Linux}
-\label{subsec:RNG-linux}
-
-%\todo{Other architectures, BSD, Windows?}
-
-On Linux there are two devices that return random bytes when read; the
-\verb+/dev/random+ can block until sufficient entropy has been collected
-while \verb+/dev/urandom+ will not block and return whatever (possibly
-insufficient) entropy has been collected so far.
-
-Unfortunately most crypto implementations are using \verb+/dev/urandom+
-and can produce predictable random numbers if not enough entropy has
-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
-keeping entropy across reboots by storing output of /dev/random into a
-file before shutdown and re-injecting the contents during the boot
-process. On the other hand this can be used for running a secondary
-entropy collector to inject entropy into the kernel entropy pool.
-
-On Linux you can check how much entropy is available with the command:
-\begin{lstlisting}
-$ cat /proc/sys/kernel/random/entropy_avail
-\end{lstlisting}
-
-%% specifics for libraries
-%% Openssl uses /dev/urandom. See the paper: https://factorable.net/weakkeys12.conference.pdf (section 5.2)
-%% What about other libs? 
-%% What about other OSes? 
-
-
-\subsection{Recommendations}
-
-To avoid situations where a newly deployed server doesn't have enough
-entropy it is recommended to generate keys (e.g. for SSL or SSH) on
-a system with a sufficient amount of entropy available and transfer the generated keys
-to the server.  This is especially advisable for small embedded devices
-or virtual machines.
-
-For embedded devices and virtual machines deploying additional userspace
-software that generates entropy and feeds this to kernel entropy pool
-(e.g. by writing to \verb+/dev/random+ on Linux) is recommended. Note
-that only a process with root rights can update the entropy counters in the
-kernel; non-root or user processes can still feed entropy to the pool but
-cannot update the counters~\cite{Wikipedia:/dev/random}.
-
-For Linux the \verb+haveged+
-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~\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
 keys: For DSA, if there is ever insufficient entropy at the time keys
index f7efef4..2923249 100644 (file)
@@ -47,7 +47,6 @@ Command line tools
 %% NOTE: should we merge that with chapter 6.6??
 \begin{itemize*}
   \item \href{http://www.fourmilab.ch/random/}{ENT} is a pseudo random number generator sequence tester.
-  \item \href{http://www.issihosts.com/haveged/}{HaveGE} is a tool which increases the Entropy of the Linux random number generator devices. It is based on the HAVEGE algorithm. \url{http://dl.acm.org/citation.cfm?id=945516}
   \item \href{http://www.phy.duke.edu/~rgb/General/dieharder.php}{Dieharder} a random number generator testing tool.
   \item \href{http://www.cacert.at/random/}{CAcert Random} another random number generator testing service.
 \end{itemize*}