typos
authorAaron Kaplan <aaron@lo-res.org>
Tue, 24 Dec 2013 12:42:12 +0000 (13:42 +0100)
committerAaron Kaplan <aaron@lo-res.org>
Tue, 24 Dec 2013 12:42:12 +0000 (13:42 +0100)
src/links.tex
src/theory/ECC.tex
src/theory/PKIs.tex
src/theory/RNGs.tex
src/theory/keylengths.tex
src/tools.tex

index db07040..cdffa0c 100644 (file)
@@ -11,7 +11,7 @@
 \item Duraconf, A collection of hardened configuration files for SSL/TLS services (Jacob Appelbaum's github): \url{https://github.com/ioerror/duraconf}
 \item Attacks on SSL a comprehensive study of BEAST, CRIME, TIME, BREACH, LUCKY 13 \& RC4 Biases: \url{https://www.isecpartners.com/media/106031/ssl_attacks_survey.pdf}
 \item EFF How to deploy HTTPS correctly: \url{https://www.eff.org/https-everywhere/deploying-https}
-\item Bruce Almighty: Schneier preaches security to Linux faithful (on not recommending to use Blowfish anymore in favour of Twofish): \url{https://www.computerworld.com.au/article/46254/bruce_almighty_schneier_preaches_security_linux_faithful/?pp=3}
+\item Bruce Almighty: Schneier preaches security to Linux faithful (on not recommending to use Blowfish anymore in favor of Twofish): \url{https://www.computerworld.com.au/article/46254/bruce_almighty_schneier_preaches_security_linux_faithful/?pp=3}
 \item Implement FIPS 183-3 for DSA keys (1024bit constraint): \url{https://bugzilla.mindrot.org/show_bug.cgi?id=1647}
 \item Elliptic Curve Cryptography in Practice: \url{http://eprint.iacr.org/2013/734.pdf}
 \item Factoring as a Service: \url{http://crypto.2013.rump.cr.yp.to/981774ce07e51813fd4466612a78601b.pdf}
@@ -19,7 +19,7 @@
 \item SSL and the Future of Authenticity, Moxie Marlinspike - Black Hat USA 2011: \url{http://www.youtube.com/watch?v=Z7Wl2FW2TcA}
 \item ENISA - Algorithms, Key Sizes and Parameters Report (Oct.'13) \url{http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report}
 \item Diffie-Hellman Groups \url{http://ibm.co/18lslZf}
-\item Diffie-Hellman Groups standardised in RFC3526\cite{rfc3526} \url{http://datatracker.ietf.org/doc/rfc3526/}
+\item Diffie-Hellman Groups standardized in RFC3526\cite{rfc3526} \url{http://datatracker.ietf.org/doc/rfc3526/}
 \item ECC-enabled GnuPG per RFC6637\cite{rfc6637} \url{https://code.google.com/p/gnupg-ecc}
 \item TLS Security (Survey + Lucky13 + RC4 Attack) by Kenny Paterson \url{https://www.cosic.esat.kuleuven.be/ecc2013/files/kenny.pdf}
 \item Ensuring High-Quality Randomness in Cryptographic Key Generation \url{http://arxiv.org/abs/1309.7366v1}
index 9d245c3..b688500 100644 (file)
@@ -3,49 +3,50 @@
 
 %\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
+\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 Cryptography (simply called ECC from now on) is a branch of
+cryptography that emerged in the mid-1980s.  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 logarithm
+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!
+ECC provides for much stronger security with less computationally 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!
 
index a5b87ac..e0cbbc9 100644 (file)
@@ -26,7 +26,7 @@ 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
+is a non-profit volunteer-based organization 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.
@@ -36,10 +36,10 @@ 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:
+Generating a key pair and a certificate request can be done with a number of
+tools.  On Unix-like 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>
@@ -104,21 +104,21 @@ 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
+
+In recent years several CAs were compromised by attackers in order to get a
+hold 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}.
+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
+organizations 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 
+a new system to detect malicious CAs and certificates  called Certificate 
 Transparency~\cite{certtransparency}.
 
 % \subsubsection{DANE}
index a713044..14c351a 100644 (file)
@@ -86,7 +86,7 @@ entropy collector to inject entropy into the kernel entropy pool.
 
 \subsection{Recommendations}
 
-To avoid situations where a newly deployed server hasn't enough
+To avoid situations where a newly deployed server has not 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
index 7e844c8..406080c 100644 (file)
@@ -12,15 +12,15 @@ 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
+Furthermore, when choosing 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
+strengths of symmetric keys in chapter 5 and chapter 7. Summarizing ECRYPT II, we
+recommend 128 bit of key strength 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
index 3d3f6db..a993417 100644 (file)
@@ -4,7 +4,7 @@ This section lists tools for checking the security settings.
 
 \subsection{SSL \& TLS}
 
-Serverchecks via the web
+Server checks via the web
 \begin{itemize}
 \item \href{http://ssllabs.com}{ssllabs.com} offers a great way to check your webserver for misconfigurations. See \url{https://www.ssllabs.com/ssltest/}. Furthermore, ssllabs.com has a good best practices tutorial, which focuses on avoiding the most common mistakes in SSL.
 \item SSL Server certificate installation issues \url{http://www.sslshopper.com/ssl-checker.html}
@@ -16,7 +16,7 @@ Serverchecks via the web
 \item \url{http://tls.secg.org} is a tool for testing interoperability of HTTPS implementations for ECC cipher suites.
 \end{itemize}
 
-Browserchecks
+Browser checks
 \begin{itemize}
 \item Check your browser's SSL capabilities: \url{https://cc.dcsec.uni-hannover.de/} and \url{https://www.ssllabs.com/ssltest/viewMyClient.html}.
 \end{itemize}