move things into the theory/ subdir
authorAaron Kaplan <aaron@lo-res.org>
Mon, 23 Dec 2013 19:44:08 +0000 (20:44 +0100)
committerAaron Kaplan <aaron@lo-res.org>
Mon, 23 Dec 2013 19:44:08 +0000 (20:44 +0100)
20 files changed:
src/DH.tex [deleted file]
src/ECC.tex [deleted file]
src/PKIs.tex [deleted file]
src/RNGs.tex [deleted file]
src/SHA.tex [deleted file]
src/checkpoint_1.png [deleted file]
src/checkpoint_2.png [deleted file]
src/checkpoint_3.png [deleted file]
src/checkpoint_4.png [deleted file]
src/img/keylengths_com.png [new file with mode: 0644]
src/keylengths.tex [deleted file]
src/keylengths_com.png [deleted file]
src/practical_settings/vpn.tex
src/theory.tex
src/theory/DH.tex [new file with mode: 0644]
src/theory/ECC.tex [new file with mode: 0644]
src/theory/SHA.tex [new file with mode: 0644]
src/theory/cipher_suites.tex
src/theory/keylengths.tex [new file with mode: 0644]
src/theory/overview.tex

diff --git a/src/DH.tex b/src/DH.tex
deleted file mode 100644 (file)
index 4a869a5..0000000
+++ /dev/null
@@ -1,12 +0,0 @@
-\section{A note on Diffie Hellman Key Exchanges}
-\label{section:DH}
-
-A common question is which Diffie Hellman (DH) Parameters  should be used for Diffie Hellman key exchanges\footnote{\url{http://crypto.stackexchange.com/questions/1963/how-large-should-a-diffie-hellman-p-be}}. We follow the recommendations in ECRYPT II, chapter 16.\cite{ii2011ecrypt}
-
-Where configurable, we recommend using the Diffie Hellman groups
-defined for IKE, specifically groups 14-18 (for MODP, \cite{rfc3526})
-and 19-21 (for elliptic curve DH, \cite{rfc5903}). These groups have
-been checked by many eyes and can be assumed to be secure.
-
-For convenience, we provide these parameters as PEM files. \todo{put
-  them on the server and insert URL here}.
diff --git a/src/ECC.tex b/src/ECC.tex
deleted file mode 100644 (file)
index 9d245c3..0000000
+++ /dev/null
@@ -1,51 +0,0 @@
-\section{A note on Elliptic Curve Cryptography}
-\label{section:EllipticCurveCryptography}
-
-%\epigraph{``Mathematics is the queen of the sciences and number theory is the queen of mathematics.''}{-- Carl Friedrich Gauss}
-
-\epigraph{``Everyone knows what a curve is, until he has studied enough mathematics to become confused through the countless number of possible exceptions.''}{-- Felix Klein }
-
-Elliptic Curve Cryptogaphy (simply called ECC from now on) is a branch of 
-cryptography that emerged in the mid-1980ties.
-The security of the RSA algorithm is based on the assumption that factoring 
-large primes is infeasible. Likewise the security of ECC, DH and DSA is 
-based on the discrete logrithm problem\cite{Wikipedia:Discrete,McC90,WR13}.
-Finding the discrete logarithm of an elliptic curve from its public base
-point is thought to be infeasible. This is known as the Elliptic Curve Discrete 
-Logarithm Problem (ECDLP). ECC and the underlying mathematical foundation are not easy 
-to understand - luckily there have been some great introductions on the topic lately
-\footnote{\url{http://arstechnica.com/security/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography}}
-\footnote{\url{https://www.imperialviolet.org/2010/12/04/ecc.html}}
-\footnote{\url{http://www.isg.rhul.ac.uk/~sdg/ecc.html}}.
-
-ECC provides for much stronger security with less computonally expensive
-operations in comparison to traditional PKI algorithms (See the Section \ref{section:keylengths}).
-
-
-The security of ECC relies on the elliptic curves and curve points chosen
-as parameters for the algorithm in question. Well before the NSA-leak scandal
-there has been a lot of discussion regarding these parameters and their 
-potential subversion. A part of the discussion involved recommended sets 
-of curves and curve points chosen by different standardization bodies such 
-as the National Institute of Standards and Technology (NIST) 
-\footnote{\url{http://www.nist.gov}}. Which were later widely implemented 
-in most common crypto libraries. Those parameters came under question 
-repeatedly from cryptographers\cite{BL13,Sch13b,W13}.
-At the time of writing there is ongoing research as to the security of 
-various ECC parameters\cite{DJBSC}.
-Most software configured to rely on ECC (be it client or server) is
-not able to promote or black-list certain curves. It is the hope of
-the authors that such functionality will be deployed widely soon.
-The authors of this paper include configurations and recommendations
-with and without ECC - the reader may choose to adopt those settings
-as he finds best suited to his environment. The authors will not make
-this decision for the reader.
-
-
-\textbf{A word of warning:} One should get familiar with ECC, different curves and
-parameters if one chooses to adopt ECC configurations. Since there is much 
-discussion on the security of ECC, flawed settings might very well compromise the 
-security of the entire system!
-
-%% mention different attacks on ECC besides flawed parameters!
-
diff --git a/src/PKIs.tex b/src/PKIs.tex
deleted file mode 100644 (file)
index a5b87ac..0000000
+++ /dev/null
@@ -1,155 +0,0 @@
-\section{Public Key Infrastructures}
-\label{section:PKIs}
-
-Public-Key Infrastructures aim to provide a way to simplify the verification of
-a certificate's trustworthiness.  For this, certificate authorities (CAs) are
-used to create a signature chain from the root CA down to the server (or client).
-Accepting a CA as a generally-trusted mediator solves the trust-scaling problem
-at the cost of introducing an actor that magically is more trustworthy.
-
-The first part of this section addresses how to obtain a certificate.  The
-second part offers recommendations on how to improve the security of your
-PKI.
-
-\subsection{Certificate Authorities}
-\label{sec:cas}
-In order to get a certificate, you can find an external CA willing to issue
-a certificate for you, run your own CA, or use self-signed certificates.
-As always, there are advantages and disadvantages for every one of these
-options; a balance of security versus usability needs to be found.
-
-\subsubsection{Certificates From an External Certificate Authority}
-\label{sec:signcertfromca}
-
-There is a fairly large number of commercial CAs that will issue
-certificates for money.  Some of the most ubiquitous commercial CAs are
-Verisign, GoDaddy, and Teletrust.  However, there are also CAs that offer
-certificates for free.  The most notable examples are StartSSL, which is a
-company that offers some types of certificates for free, and CAcert, which
-is a non-profit volunteer-based organisation that does not charge at all
-for issuing certificates.  Finally, in the research and education field, a
-number of CAs exist that are generally well-known and well-accepted within
-the higher-education community.
-
-When requesting a certificate from a CA, it is vital that you generate the
-key pair yourself.  In particular, the private key should never be known to
-the CA.  If a CA offers to generate the key pair for you, you should not
-trust that CA.
-
-Generating a key pair and a certificate request can be done with a number
-of tools.  On Unixoid systems, it is likely that the OpenSSL suite is
-available to you.  In this case, you can generate a private key and a
-corresponding certificate request as follows:
-
-\begin{lstlisting}[breaklines]
-% openssl req -new -nodes -keyout <servername>.key -out <servername>.csr -newkey rsa:<keysize>
-Country Name (2 letter code) [AU]:DE
-State or Province Name (full name) [Some-State]:Bavaria
-Locality Name (eg, city) []:Munich
-Organization Name (eg, company) [Internet Widgits Pty Ltd]:Example
-Organizational Unit Name (eg, section) []:Example Section
-Common Name (e.g. server FQDN or YOUR name) []:example.com
-Email Address []:admin@example.com
-
-Please enter the following 'extra' attributes
-to be sent with your certificate request
-A challenge password []:
-An optional company name []:
-\end{lstlisting}
-
-\subsubsection{Setting Up Your Own Certificate Authority}
-\label{sec:setupownca}
-In some situations it is advisable to run your own certificate authority.
-Whether this is a good idea depends on the exact circumstances.  Generally
-speaking, the more centralized the control of the systems in your
-environment, the fewer pains you will have to go through to deploy your own
-CA.  On the other hand, running your own CA maximizes the trust level that
-you can achieve because it minimizes external trust dependencies.
-
-Again using OpenSSL as an example, you can set up your own CA with the
-following commands on a Debian system:
-
-\begin{lstlisting}
-% cd /usr/lib/ssl/misc
-% sudo ./CA.pl -newca
-\end{lstlisting}
-
-Answer the questions according to your setup. Now that you have configured your basic settings and 
-issued a new root certificate, you can issue new certificates as follows:
-
-\begin{lstlisting}
-% cd /usr/lib/ssl/misc
-% sudo ./CA.pl -newreq
-\end{lstlisting}
-
-\subsubsection{Creating a Self-Signed Certificate}
-\label{sec:pki:selfsignedcert}
-If the desired trust level is very high and the number of systems involved
-is limited, the easiest way to set up a secure environment may be to use
-self-signed certificates.  A self-signed certificate is not issued by any
-CA at all, but is signed by the entity that it is issued to.  Thus, the
-organizational overhead of running a CA is eliminated at the expense of
-having to establish all trust relationships between entities manually.
-
-With OpenSSL, a self-signed certificate may be created with this command:
-
-\begin{lstlisting}
-% openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095
-\end{lstlisting}
-
-The resulting certificate will by default not be trusted by anyone at all,
-so in order to be useful, the certificate will have to be made known a
-priori to all parties that may encounter it.
-
-
-\subsection{Hardening PKI}
-\label{sec:hardeningpki}
-In recent years several CAs were compromised by attackers in order to
-get ahold of trusted certificates for malicious activities. In 2011 
-the Dutch CA Diginotar was hacked and all certificates were
-revoked~\cite{diginotar-hack}. Recently Google found certificates
-issued to them, which were not used by the
-company~\cite{googlecahack}. The concept of PKIs heavily depends on the
-security of CAs.  If they get compromised the whole PKI system will
-fail. Some CAs tend to incorrectly issue certificates that were designated
-to do a different job than what they were intended to by the CA~\cite{gocode}.
-
-Therefore several security enhancements were introduced by different
-organisations and vendors~\cite{tschofenig-webpki}. Currently two
-methods are used, DANE~\cite{rfc6698} and Certificate
-Pinning~\cite{draft-ietf-websec-key-pinning}. Google recently proposed
-a new system to detect malicous CAs and certificates  called Certificate 
-Transparency~\cite{certtransparency}.
-
-% \subsubsection{DANE}
-% \label{sec:dane}
-
-% \subsubsection{Certificate Pinning}
-% \label{sec:certpinning}
-
-
-
-% This section deals with settings related to trusting CAs. However,
-% our main recommendations for PKIs is: if you are able to run your
-% own PKI and disable any other CA, do so. This makes sense most in
-% environments where any machine-to-machine communication system
-% compatibility with external entities is not an issue.
-%% azet: this needs discussion! self-signed certificates simply do not
-%% work in practices for real-world scenarios - i.e. websites that
-%% actually serve a lot of people
-
-% A good background on PKIs can be found in
-% \footnote{\url{https://developer.mozilla.org/en/docs/Introduction_to_Public-Key_Cryptography}}
-% \footnote{\url{http://cacr.uwaterloo.ca/hac/about/chap8.pdf}}
-% \footnote{\url{http://www.verisign.com.au/repository/tutorial/cryptography/intro1.shtml}}
-% .
-
-% \todo{ts: Background and Configuration (EMET) of Certificate Pinning,
-%   TLSA integration, When to use self-signed certificates, how to get
-%   certificates from public CA authorities (CACert, StartSSL),
-%   Best-practices how to create a CA and how to generate private
-%   keys/CSRs, Discussion about OCSP and CRLs. TD: Useful Firefox
-%   plugins: CipherFox, Conspiracy, Perspectives.}
-
-
-% ``Certificate Policy''\cite{Wikipedia:Certificate_Policy} (CA)
diff --git a/src/RNGs.tex b/src/RNGs.tex
deleted file mode 100644 (file)
index 3b791f2..0000000
+++ /dev/null
@@ -1,104 +0,0 @@
-\section{Random Number Generators}
-\label{section:RNGs}
-
-% This section was authored by Ralf Schlatterbeck (Ralf Schlatterbeck <rsc@runtux.com>)
-
-A good source of random numbers is essential for many crypto
-operations. The key feature of a good random number generator is the
-non-predictability of the generated numbers. This means that hardware
-support for generating entropy is essential.
-
-\todo{Other architectures, BSD, Windows?}
-
-Hardware random number generators in operating systems or standalone
-components collect entropy from various random events mostly by using
-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.
-
-\subsection{When random number generators fail}
-
-Random number generators can fail -- returning predictable non-random
-numbers -- if not enough entropy is available when random numbers should
-be generated.
-
-This typically occurs for embedded devices and virtual machines.
-Embedded devices lack some entropy sources other devices have, e.g.:
-
-\begin{itemize}
-\item No persistent clock, so boot-time is not contributing to the
-    initial RNG state
-\item No hard-disk: No entropy from hard-disk timing, no way to store
-    entropy between reboots
-\end{itemize}
-
-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}.
-
-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}.
-
-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}.
-
-\subsection{Linux}
-
-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.
-
-%% 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 hasn't enough
-entropy it is recommended to generate keys (e.g. for SSL or SSH) on
-a system with enough 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 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\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
-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}.
diff --git a/src/SHA.tex b/src/SHA.tex
deleted file mode 100644 (file)
index fb88353..0000000
+++ /dev/null
@@ -1,21 +0,0 @@
-\section{A note on SHA-1}
-\label{section:SHA}
-
-
-In the last years several weaknesses have been shown for SHA-1. In
-particular, collisions on SHA-1 can be found using $2^{63}$ operations, and
-recent results even indicate a lower complexity. Therefore,
-ECRYPT II and NIST recommend against using SHA-1 for generating digital
-signatures and for other applications that require collision resistance.
-The use of SHA-1 in message authentication, e.g. HMAC, is not
-immediately threatened.
-
-We recommend using SHA-2 whenever available. Since SHA-2 is not
-supported by older versions of TLS, SHA-1 can be used for message
-authentication if a higher compatibility with a more diverse set of
-clients is needed.
-
-
-Our configurations A and B reflect this. While configuration A does not include
-SHA-1, configuration B does and thus is more compatible with a wider range of
-clients.
diff --git a/src/checkpoint_1.png b/src/checkpoint_1.png
deleted file mode 100644 (file)
index 88f5266..0000000
Binary files a/src/checkpoint_1.png and /dev/null differ
diff --git a/src/checkpoint_2.png b/src/checkpoint_2.png
deleted file mode 100644 (file)
index 0323e29..0000000
Binary files a/src/checkpoint_2.png and /dev/null differ
diff --git a/src/checkpoint_3.png b/src/checkpoint_3.png
deleted file mode 100644 (file)
index e6bbe0a..0000000
Binary files a/src/checkpoint_3.png and /dev/null differ
diff --git a/src/checkpoint_4.png b/src/checkpoint_4.png
deleted file mode 100644 (file)
index b5d2a24..0000000
Binary files a/src/checkpoint_4.png and /dev/null differ
diff --git a/src/img/keylengths_com.png b/src/img/keylengths_com.png
new file mode 100644 (file)
index 0000000..202e5db
Binary files /dev/null and b/src/img/keylengths_com.png differ
diff --git a/src/keylengths.tex b/src/keylengths.tex
deleted file mode 100644 (file)
index 23b7607..0000000
+++ /dev/null
@@ -1,73 +0,0 @@
-\section{Keylengths}
-\label{section:keylengths}
-
-
-\epigraph{``On the choice between AES256 and AES128: I would never consider
-using AES256, just like I don't wear a helmet when I sit inside my car. It's
-too much bother for the epsilon improvement in security.''}{-- Vincent Rijmen
-in a personal mail exchange Dec 2013}
-
-Recommendations on keylengths need to be adapted regularly. Since this document
-first of all is static and second of all, does not consider itself to be
-authoritative on keylengths, we would rather refer to existing publications and
-websites.  Recommending a safe key length is a hit-and-miss issue.
-
-Furthermore, when chosing an encryption algorithm and keylength, the
-designer/sysadmin always needs to consider the value of the information and how
-long it must be protected.  In other words: consider the number of years the
-data needs to stay confidential.
-
-
-The ECRYPT II publication (\cite{ii2011ecrypt}) gives a fascinating overview of
-strenghts of symmetric keys in chapter 5 and chapter 7. Summarizing ECRYPT II, we
-recommend 128 bit of key strenght for symmetric keys. In ECRYPT II, this is
-considered safe for security level 7, long term protection.
-
-In the same ECRYPT II publication you can find a practical comparison of key size
-equivalence between symmetric key sizes and RSA, discrete log (DLOG) and EC
-keylengths. ECRYPT II arrives at the interesting conclusion that for an
-equivalence of 128 bit symmetric size, you will need to use an 3248 bit RSA
-key. See chapter 7 of \cite{ii2011ecrypt}, page 30.
-
-
-There are a couple of other studies comparing keylengths and their respective
-strengths.  The website \url{http://www.keylength.com/} compares these papers
-and offers a good overview of approximations for key lengths based on
-recommendations by different standardization bodies and academic publications.
-Figure \ref{fig:keylengths.com} shows a typical comparison of keylengths on
-this web site.
-
-\begin{figure}[h]
-  \centering
-  \includegraphics[width=0.65\textwidth]{keylengths_com.png}
-  \caption{Screenshot of \url{http://www.keylength.com} for 128 bit symmetric key size equivalents}
-  \label{fig:keylengths.com}
-\end{figure}
-
-
-\paragraph{Summary}
-\begin{itemize}
-
-\item For traditional asymmetric public-key cryptography we consider any key
-length below 2048 bits to be deprecated at the time of this writing (for long
-term protection).  
-
-\item For elliptic curve cryptography we consider key lengths below 256 bits to
-be inadequate for long term protection.  
-
-\item For symmetric algorithms we consider anything below 128 bits to be
-inadequate for long term protection.
-
-\end{itemize}
-
-\paragraph{Special remark on 3DES} \mbox{} \\
-We want to note that 3DES theoretically has 168 bits of security, however based
-on the NIST Special Publication 800-57
-\footnote{\url{http://csrc.nist.gov/publications/PubsSPs.html\#800-57-part1},
-pages 63 and 64}, it is clear that 3DES can only be considered to provide for
-80 bits / 112 bits security.
-
-
-
-
-
diff --git a/src/keylengths_com.png b/src/keylengths_com.png
deleted file mode 100644 (file)
index 202e5db..0000000
Binary files a/src/keylengths_com.png and /dev/null differ
index f2a5b95..1142852 100644 (file)
@@ -167,7 +167,7 @@ Communities can be found in the ``IPSEC VPN'' tab of SmartDashboard.
 
 \begin{figure}[p]
   \centering
-  \includegraphics[width=0.592\textwidth]{checkpoint_1.png}
+  \includegraphics[width=0.592\textwidth]{img/checkpoint_1.png}
   \caption{VPN Community encryption properties}
   \label{fig:checkpoint_1}
 \end{figure}
@@ -179,7 +179,7 @@ Phase 1 and 2 (figure \ref{fig:checkpoint_2}).
 
 \begin{figure}[p]
   \centering
-  \includegraphics[width=0.411\textwidth]{checkpoint_2.png}
+  \includegraphics[width=0.411\textwidth]{img/checkpoint_2.png}
   \caption{Custom Encryption Suite Properties}
   \label{fig:checkpoint_2}
 \end{figure}
@@ -190,7 +190,7 @@ found under ``Advanced Settings'' / ``Advanced VPN Properties''
 
 \begin{figure}[p]
   \centering
-  \includegraphics[width=0.589\textwidth]{checkpoint_3.png}
+  \includegraphics[width=0.589\textwidth]{img/checkpoint_3.png}
   \caption{Advanced VPN Properties}
   \label{fig:checkpoint_3}
 \end{figure}
@@ -205,7 +205,7 @@ button, you can configure sets of algorithms that all gateways support
 
 \begin{figure}[p]
   \centering
-  \includegraphics[width=0.474\textwidth]{checkpoint_4.png}
+  \includegraphics[width=0.474\textwidth]{img/checkpoint_4.png}
   \caption{Remote Access Encryption Properties}
   \label{fig:checkpoint_4}
 \end{figure}
index 48333bd..2a7e9bc 100644 (file)
@@ -1,8 +1,8 @@
 \input{theory/overview}
 \input{theory/cipher_suites}
-\input{ECC}
-\input{SHA}
-\input{DH}
-\input{keylengths}
-\input{RNGs}
-\input{PKIs}
+\input{theory/ECC}
+\input{theory/SHA}
+\input{theory/DH}
+\input{theory/keylengths}
+\input{theory/RNGs}
+\input{theory/PKIs}
diff --git a/src/theory/DH.tex b/src/theory/DH.tex
new file mode 100644 (file)
index 0000000..4a869a5
--- /dev/null
@@ -0,0 +1,12 @@
+\section{A note on Diffie Hellman Key Exchanges}
+\label{section:DH}
+
+A common question is which Diffie Hellman (DH) Parameters  should be used for Diffie Hellman key exchanges\footnote{\url{http://crypto.stackexchange.com/questions/1963/how-large-should-a-diffie-hellman-p-be}}. We follow the recommendations in ECRYPT II, chapter 16.\cite{ii2011ecrypt}
+
+Where configurable, we recommend using the Diffie Hellman groups
+defined for IKE, specifically groups 14-18 (for MODP, \cite{rfc3526})
+and 19-21 (for elliptic curve DH, \cite{rfc5903}). These groups have
+been checked by many eyes and can be assumed to be secure.
+
+For convenience, we provide these parameters as PEM files. \todo{put
+  them on the server and insert URL here}.
diff --git a/src/theory/ECC.tex b/src/theory/ECC.tex
new file mode 100644 (file)
index 0000000..9d245c3
--- /dev/null
@@ -0,0 +1,51 @@
+\section{A note on Elliptic Curve Cryptography}
+\label{section:EllipticCurveCryptography}
+
+%\epigraph{``Mathematics is the queen of the sciences and number theory is the queen of mathematics.''}{-- Carl Friedrich Gauss}
+
+\epigraph{``Everyone knows what a curve is, until he has studied enough mathematics to become confused through the countless number of possible exceptions.''}{-- Felix Klein }
+
+Elliptic Curve Cryptogaphy (simply called ECC from now on) is a branch of 
+cryptography that emerged in the mid-1980ties.
+The security of the RSA algorithm is based on the assumption that factoring 
+large primes is infeasible. Likewise the security of ECC, DH and DSA is 
+based on the discrete logrithm problem\cite{Wikipedia:Discrete,McC90,WR13}.
+Finding the discrete logarithm of an elliptic curve from its public base
+point is thought to be infeasible. This is known as the Elliptic Curve Discrete 
+Logarithm Problem (ECDLP). ECC and the underlying mathematical foundation are not easy 
+to understand - luckily there have been some great introductions on the topic lately
+\footnote{\url{http://arstechnica.com/security/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography}}
+\footnote{\url{https://www.imperialviolet.org/2010/12/04/ecc.html}}
+\footnote{\url{http://www.isg.rhul.ac.uk/~sdg/ecc.html}}.
+
+ECC provides for much stronger security with less computonally expensive
+operations in comparison to traditional PKI algorithms (See the Section \ref{section:keylengths}).
+
+
+The security of ECC relies on the elliptic curves and curve points chosen
+as parameters for the algorithm in question. Well before the NSA-leak scandal
+there has been a lot of discussion regarding these parameters and their 
+potential subversion. A part of the discussion involved recommended sets 
+of curves and curve points chosen by different standardization bodies such 
+as the National Institute of Standards and Technology (NIST) 
+\footnote{\url{http://www.nist.gov}}. Which were later widely implemented 
+in most common crypto libraries. Those parameters came under question 
+repeatedly from cryptographers\cite{BL13,Sch13b,W13}.
+At the time of writing there is ongoing research as to the security of 
+various ECC parameters\cite{DJBSC}.
+Most software configured to rely on ECC (be it client or server) is
+not able to promote or black-list certain curves. It is the hope of
+the authors that such functionality will be deployed widely soon.
+The authors of this paper include configurations and recommendations
+with and without ECC - the reader may choose to adopt those settings
+as he finds best suited to his environment. The authors will not make
+this decision for the reader.
+
+
+\textbf{A word of warning:} One should get familiar with ECC, different curves and
+parameters if one chooses to adopt ECC configurations. Since there is much 
+discussion on the security of ECC, flawed settings might very well compromise the 
+security of the entire system!
+
+%% mention different attacks on ECC besides flawed parameters!
+
diff --git a/src/theory/SHA.tex b/src/theory/SHA.tex
new file mode 100644 (file)
index 0000000..fb88353
--- /dev/null
@@ -0,0 +1,21 @@
+\section{A note on SHA-1}
+\label{section:SHA}
+
+
+In the last years several weaknesses have been shown for SHA-1. In
+particular, collisions on SHA-1 can be found using $2^{63}$ operations, and
+recent results even indicate a lower complexity. Therefore,
+ECRYPT II and NIST recommend against using SHA-1 for generating digital
+signatures and for other applications that require collision resistance.
+The use of SHA-1 in message authentication, e.g. HMAC, is not
+immediately threatened.
+
+We recommend using SHA-2 whenever available. Since SHA-2 is not
+supported by older versions of TLS, SHA-1 can be used for message
+authentication if a higher compatibility with a more diverse set of
+clients is needed.
+
+
+Our configurations A and B reflect this. While configuration A does not include
+SHA-1, configuration B does and thus is more compatible with a wider range of
+clients.
index a03e33f..22494be 100644 (file)
@@ -6,29 +6,29 @@
 
 \subsection{Architectural overview }
 \label{subsection:architecture}
-\input{"./cipher_suites/architecture.tex"}
+\input{"./theory/cipher_suites/architecture.tex"}
 
 
 \subsection{Forward Secrecy}
 \label{subsection:PFS}
-\input{"./cipher_suites/forward.tex"}
+\input{"./theory/cipher_suites/forward.tex"}
 
 
 \subsection{Recommended cipher suites}
 \label{section:recommendedciphers}
-\input{"./cipher_suites/recommended.tex"}
+\input{"./theory/cipher_suites/recommended.tex"}
 
 
 %\subsection{Known insecure and weak cipher suites}
-%\input{"./cipher_suites/insecure.tex"}
+%\input{"./theory/cipher_suites/insecure.tex"}
 
 
 \subsection{Compatibility}
 \label{subsection:compatibility}
-\input{"./cipher_suites/compatibility.tex"}
+\input{"./theory/cipher_suites/compatibility.tex"}
 
 
 \subsection{Choosing your own cipher suites}
 \label{section:ChoosingYourOwnCipherSuites}
-\input{"./cipher_suites/choosing.tex"}
+\input{"./theory/cipher_suites/choosing.tex"}
 
diff --git a/src/theory/keylengths.tex b/src/theory/keylengths.tex
new file mode 100644 (file)
index 0000000..7e844c8
--- /dev/null
@@ -0,0 +1,73 @@
+\section{Keylengths}
+\label{section:keylengths}
+
+
+\epigraph{``On the choice between AES256 and AES128: I would never consider
+using AES256, just like I don't wear a helmet when I sit inside my car. It's
+too much bother for the epsilon improvement in security.''}{-- Vincent Rijmen
+in a personal mail exchange Dec 2013}
+
+Recommendations on keylengths need to be adapted regularly. Since this document
+first of all is static and second of all, does not consider itself to be
+authoritative on keylengths, we would rather refer to existing publications and
+websites.  Recommending a safe key length is a hit-and-miss issue.
+
+Furthermore, when chosing an encryption algorithm and keylength, the
+designer/sysadmin always needs to consider the value of the information and how
+long it must be protected.  In other words: consider the number of years the
+data needs to stay confidential.
+
+
+The ECRYPT II publication (\cite{ii2011ecrypt}) gives a fascinating overview of
+strenghts of symmetric keys in chapter 5 and chapter 7. Summarizing ECRYPT II, we
+recommend 128 bit of key strenght for symmetric keys. In ECRYPT II, this is
+considered safe for security level 7, long term protection.
+
+In the same ECRYPT II publication you can find a practical comparison of key size
+equivalence between symmetric key sizes and RSA, discrete log (DLOG) and EC
+keylengths. ECRYPT II arrives at the interesting conclusion that for an
+equivalence of 128 bit symmetric size, you will need to use an 3248 bit RSA
+key. See chapter 7 of \cite{ii2011ecrypt}, page 30.
+
+
+There are a couple of other studies comparing keylengths and their respective
+strengths.  The website \url{http://www.keylength.com/} compares these papers
+and offers a good overview of approximations for key lengths based on
+recommendations by different standardization bodies and academic publications.
+Figure \ref{fig:keylengths.com} shows a typical comparison of keylengths on
+this web site.
+
+\begin{figure}[h]
+  \centering
+  \includegraphics[width=0.65\textwidth]{img/keylengths_com.png}
+  \caption{Screenshot of \url{http://www.keylength.com} for 128 bit symmetric key size equivalents}
+  \label{fig:keylengths.com}
+\end{figure}
+
+
+\paragraph{Summary}
+\begin{itemize}
+
+\item For traditional asymmetric public-key cryptography we consider any key
+length below 2048 bits to be deprecated at the time of this writing (for long
+term protection).  
+
+\item For elliptic curve cryptography we consider key lengths below 256 bits to
+be inadequate for long term protection.  
+
+\item For symmetric algorithms we consider anything below 128 bits to be
+inadequate for long term protection.
+
+\end{itemize}
+
+\paragraph{Special remark on 3DES} \mbox{} \\
+We want to note that 3DES theoretically has 168 bits of security, however based
+on the NIST Special Publication 800-57
+\footnote{\url{http://csrc.nist.gov/publications/PubsSPs.html\#800-57-part1},
+pages 63 and 64}, it is clear that 3DES can only be considered to provide for
+80 bits / 112 bits security.
+
+
+
+
+
index 058605c..c5440d5 100644 (file)
@@ -7,7 +7,7 @@
 This chapter provides the necessary background information on why chapter \ref{chapter:PracticalSettings} recommended \textit{cipher string B}.
 
 \vskip 0.5em
-We start off by explaining the structure of cipher strings in section \ref (Architecture) and define some terms. Next we present \textit{Cipher String A} and \textit{Cipher String B} in sections \ref XXX and \ref YYY.
+We start off by explaining the structure of cipher strings in section \ref{subsection:architecture} (architecture) and define Perfect Forward Secrecy (PFS) in \ref{subsection:PFS}. Next we present \textit{Cipher String A} and \textit{Cipher String B} in section \ref{section:recommendedciphers}.
 
 \vskip 0.5em
 After that, the following sections deal with Random number generators, keylengths, current issues in ECC, a note of warning on SHA-1 and some comments on Diffie Hellman key exchanges. All of this is important in understanding why certain choices were made for \textit{Cipher String A and B}. For most system administrators, the question of compatibility is one of the most pressing ones. Having the freedom to be compatible with any client (even running on outdated operating systems) of course, reduces the security of our cipher strings. We address these topics in section \ref{XXX}.