unify cite commands to ~\cite{foo}.
[ach-master.git] / src / theory / RNGs.tex
index 9c0ac20..25f80c6 100644 (file)
@@ -46,17 +46,17 @@ Embedded devices lack some entropy sources other devices have, e.g.:
 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\cite{Eng11,POL11}.
+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\cite{HDWH12}.
+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\cite{HDWH12}.
+leading to predictable session keys~\cite{HDWH12}.
 
 \subsection{Linux}
 
@@ -69,7 +69,7 @@ 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}.
+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
@@ -97,14 +97,14 @@ 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}.
+cannot update the counters~\cite{Wikipedia:/dev/random}.
 
 For Linux the \verb+haveged+
-implementation\cite{HAV13a} based on the HAVEGE\cite{SS03}
+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
+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
@@ -114,4 +114,4 @@ are used for signing this may lead to repeated ephemeral keys. An
 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\cite{HDWH12}.
+signatures but not to the compromise of the secret key~\cite{HDWH12}.