Start with BiBTeX (RNG section converted)

[ach-master.git] / src / RNGs.tex

diff --git a/src/RNGs.tex b/src/RNGs.tex
index b2d0a38..a873b46 100644 (file)
--- a/src/RNGs.tex
+++ b/src/RNGs.tex
@@ -35,20 +35,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\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}
 
@@ -59,8 +56,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\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
@@ -82,17 +78,15 @@ 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 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
@@ -101,5 +95,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\footnote{\url{https://factorable.net/weakkeys12.extended.pdf}}.
+signatures but not to the compromise of the secret key\cite{HDWH12}.