Merge branch 'master' of github.com:BetterCrypto/Applied-Crypto-Hardening
authorsebix <szebi@gmx.at>
Tue, 24 Dec 2013 14:16:22 +0000 (15:16 +0100)
committersebix <szebi@gmx.at>
Tue, 24 Dec 2013 14:16:22 +0000 (15:16 +0100)
18 files changed:
src/disclaimer.tex
src/further_research.tex
src/links.tex
src/practical_settings/DBs.tex
src/practical_settings/im.tex
src/practical_settings/mailserver.tex
src/practical_settings/ssh.tex
src/practical_settings/vpn.tex
src/practical_settings/webserver.tex
src/theory/ECC.tex
src/theory/PKIs.tex
src/theory/RNGs.tex
src/theory/cipher_suites/architecture.tex
src/theory/cipher_suites/choosing.tex
src/theory/cipher_suites/recommended.tex
src/theory/keylengths.tex
src/theory/overview.tex
src/tools.tex

index db0ea23..7b28a25 100644 (file)
@@ -57,7 +57,7 @@ This guide can only describe what the authors currently
 after intensive cross checking with literature and experts. For a complete list
 of people who reviewed this paper, see the section \ref{section:Reviewers}.
 Even though, multiple specialists reviewed the guide, the authors can give
-\emph{no guarantee whatsover} that they made the right recommendations. Keep in
+\emph{no guarantee whatsoever} that they made the right recommendations. Keep in
 mind that tomorrow there might be new attacks on some ciphers and many of the
 recommendations in this guide might turn out to be wrong. Security is a
 process.
index 767dc54..763fb99 100644 (file)
@@ -34,7 +34,7 @@ The following is a list of services, software packages, hardware devices or prot
 \begin{itemize}
 \item RADIUS 
 \item Moxa , APC, und co... ICS . Ethernet to serial 
-\item telnet (only sensible reocmmendation: \emph{DON't!!}
+\item telnet (only sensible reocmmendation: \emph{DON't!!})
 \item rsyslog 
 \item v6 spoofing (look at work by Ferndo Gont, Marc Heuse, et. al.)
 \item tinc
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 d8aca8b..0ed96ac 100644 (file)
@@ -7,7 +7,7 @@
 \item[Tested with Version:] not tested
 
 \item[References:] (German)
-{\small \url{www.telekom.com/static/-/155996/7/technische-sicherheitsanforderungen-si}}
+{\small \url{http://www.telekom.com/static/-/155996/7/technische-sicherheitsanforderungen-si}}
 
 Please read the following pages about SSL and ciphersuites:\\
 p. 129 -Req 396 and Req 397 \\
index a7f27a5..a2248df 100644 (file)
@@ -64,24 +64,24 @@ Newer versions of ejabberd now support specifying the cipher string in the confi
 
 \subsubsection{Chat privacy - Off-the-Record Messaging (OTR)}
 
-The OTR protocol works on top of the Jabber protocol(\footnote{\url{https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html}}).  
-It add to popular chat clients (Adium, Pidgin...) the following properties for chiffered chats:
+The OTR protocol works on top of the Jabber protocol\footnote{\url{https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html}}.  
+It adds to popular chat clients (Adium, Pidgin...) the following properties for encrypted chats:
 \begin{itemize}
-    \item Authentification
+    \item Authentication
     \item Integrity
     \item Confidentiality
-    \item Forward privacy
+    \item Forward secrecy
 \end{itemize}
 
-It bascially uses Diffie-Helleman, AES and SHA1. 
+It basically uses Diffie-Hellman, AES and SHA1. Communicating over an insecure instant messaging network, OTR can be used for end to end encryption.
 
-There are no specific configuration required but the protocol itself worth to be mentionned.
+There are no specific configurations required but the protocol itself is worth to be mentioned.
 
 \subsubsection{IRC}
 
 \todo{Quick draft -- to complete / review / validate}
 
-There are numerous implementations of IRC servers.  In this section, we choose {\it Charybdis} which serve as basis for {\it ircd-seven}\footnote{https://dev.freenode.net/redmine/projects/ircd-seven}, developped and used by freenode. Freenode is actually the biggest IRC network\footnote{http://irc.netsplit.de/networks/top10.php}.  {\it Charybdis} is being part of the {\it Debian} \& {\it Ubuntu} distributions.
+There are numerous implementations of IRC servers.  In this section, we choose {\it Charybdis} which serve as basis for {\it ircd-seven}\footnote{https://dev.freenode.net/redmine/projects/ircd-seven}, developed and used by freenode. Freenode is actually the biggest IRC network\footnote{http://irc.netsplit.de/networks/top10.php}.  {\it Charybdis} is being part of the {\it Debian} \& {\it Ubuntu} distributions.
 
 \begin{lstlisting}[breaklines]
 /* Extensions */
@@ -111,7 +111,11 @@ listen {
 
 \subsubsection{SILC}
 
-SILC is instant messaging protocol publicly released in 2000. SILC is a per-default secure chat protocol thanks to a generalized usage of symmetric encryption. Keys are generated by the server meaning that if compromised, communication could be compromised.
+SILC\footnote{\url{http://www.silcnet.org/} and
+\url{https://en.wikipedia.org/wiki/SILC_(protocol)}} is instant messaging
+protocol publicly released in 2000. SILC is a per-default secure chat protocol
+thanks to a generalized usage of symmetric encryption. Keys are generated by
+the server meaning that if compromised, communication could be compromised.
 
 The protocol is not really popular anymore.
 
index 8d2efa6..ea8e5e0 100644 (file)
@@ -68,7 +68,7 @@ mode, because the alternative is plain text transmission.
 
 \subsubsection{Additional info}
 
-Dovecot 2.0, 2.1: Almost as good as dovecot 2.2. Dovecot does not ignore unknow configuration parameters. Does not support
+Dovecot 2.0, 2.1: Almost as good as dovecot 2.2. Dovecot does not ignore unknown configuration parameters. Does not support
 ssl\_prefer\_server\_ciphers
 
 \subsubsection{Limitations}
@@ -264,7 +264,7 @@ and \verb|smtpd_tls_dh1024_param_file| options. The ``dh512''
 parameters are used for export ciphers, while the ``dh1024'' ones are
 used for all other ciphers.
 
-The ``bit lenght'' in those parameter names is just a name, so one
+The ``bit length'' in those parameter names is just a name, so one
 could use stronger parameter sets; it should be possible to e.g. use the
 IKE Group14 parameters (see section \ref{section:DH}) without much
 interoperability risk, but we have not tested this yet.
@@ -438,7 +438,7 @@ GnuTLS is different in only some respects to OpenSSL:
 
 \paragraph*{Exim string expansion}\mbox{}\\
 
-Note that most of the options accept expansion strings. This way you can eg. set cipher lists or STARTTLS advertisement conditionally. Please follow the link to the official Exim documentation to get more information.
+Note that most of the options accept expansion strings. This way you can e.g. set cipher lists or STARTTLS advertisement conditionally. Please follow the link to the official Exim documentation to get more information.
 
 \paragraph*{Limitations}\mbox{}\\
 
index 25bc3d0..c4e3d1b 100644 (file)
@@ -18,7 +18,7 @@
 \end{lstlisting}
 
 % XXX: curve25519-sha256@libssh.org only available upstream(!)
-Note: Older linux systems won't support SHA2. PuTTY (Windows) does not support
+Note: Older Linux systems won't support SHA2. PuTTY (Windows) does not support
 RIPE-MD160. Curve25519, AES-GCM and UMAC are only available upstream (OpenSSH
 6.1). DSA host keys have been removed on purpose, the DSS standard does not
 support for DSA keys stronger than 1024bit
@@ -49,7 +49,7 @@ ssh key-exchange group dh-group14-sha1
 line vty 0 4
  transport input ssh
 \end{lstlisting}
-Note: When the ASA is configured for SSH, by default both SSH versions 1 and 2 are allowed. In addition to that, only a group1 DH-key-exchange is used. This should be changed to allow only SSH version 2 and to use a key-exchnage with group14. The generated RSA key should be 2048 bit (the actual supported maximum). A non-cryptographic best practice is to reconfigure the lines to only allow SSH-logins.
+Note: When the ASA is configured for SSH, by default both SSH versions 1 and 2 are allowed. In addition to that, only a group1 DH-key-exchange is used. This should be changed to allow only SSH version 2 and to use a key-exchange with group14. The generated RSA key should be 2048 bit (the actual supported maximum). A non-cryptographic best practice is to reconfigure the lines to only allow SSH-logins.
 \subsubsection{References}
 \url{http://www.cisco.com/en/US/docs/security/asa/asa91/configuration/general/admin\_management.html }
 \subsubsection{How to test}
index eb2482c..71d529e 100644 (file)
@@ -25,7 +25,7 @@ If you need to use Pre-Shared Key authentication:
 \begin{enumerate}
 \item Choose a \textbf{random}, \textbf{long enough} PSK (see below)
 \item Use a \textbf{separate} PSK for any IPSEC connection
-\item Change the PSKs regularily
+\item Change the PSKs regularly
 \end{enumerate}
 
 The size of the PSK should not be shorter than the output size of
index a1616a0..c8e6222 100644 (file)
@@ -108,7 +108,7 @@ compression should by deactivated by default at compile-time (if not, it's
 active).
 
 Support for other SSL-libraries like GnuTLS will be available in the upcoming
-2.x branch, which is currently under developement.
+2.x branch, which is currently under development.
 
 \subsubsection{References} 
 \begin{itemize}
@@ -224,7 +224,7 @@ tested using https://www.ssllabs.com.
   \label{tab:MS_IIS_Client_Support}
 \end{table}
 
-Table~\ref{tab:MS_IIS_Client_Support} shows the algoriths from
+Table~\ref{tab:MS_IIS_Client_Support} shows the algorithms from
 strongest to weakest and why they need to be added in this order. For
 example insisting on SHA-2 algorithms (only first two lines) would
 eliminate all versions of Firefox, so the last line is needed to
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 e4e8bca..1415a57 100644 (file)
@@ -3,8 +3,8 @@
 This section defines some terms which will be used throughout this guide.
 
 
-A cipher suite is a standardised collection of key exchange algorithms, encryption 
-algorithms (ciphers) and Message authentication codes (MAC) algortihm that provides
+A cipher suite is a standardized collection of key exchange algorithms, encryption 
+algorithms (ciphers) and Message authentication codes (MAC) algorithm that provides
 authenticated encryption schemes. It consists of the following components:
 
 \begin{description}
index b31a23b..4b81de9 100644 (file)
@@ -62,7 +62,7 @@ the security (speaking in number of bits) as the RSA host key. \todo{TODO: refer
 \textbf{Elliptic Curves} (see section \ref{section:EllipticCurveCryptography})
 required by current TLS standards only consist of the so-called NIST-curves
 (\texttt{secp256r1} and \texttt{secp384r1}) which may be weak because the
-parameters that led to their generation weren't properly explained by the
+parameters that led to their generation were not properly explained by the
 authors\cite{DJBSC}. \\ Disabling support for Elliptic Curves leads to no
 ephemeral key exchange being available for the Windows platform. When you
 decide to use Elliptic Curves despite the uncertainty, make sure to at least
@@ -88,7 +88,7 @@ That way mutual trust can be established. Another mechanism providing client
 authentication is Secure Remote Password (SRP)\todo{reference}. All those
 mechanisms require special configuration.
 
-Other authentication mechanisms like Pre Shared Keys aren't used in SSL/TLS.
+Other authentication mechanisms like Pre Shared Keys are not used in SSL/TLS.
 Anonymous sessions will not be discussed in this paper.
 
 \texttt{!PSK:!aNULL}
@@ -97,7 +97,7 @@ Anonymous sessions will not be discussed in this paper.
 
 AES, CAMELLIA, SEED, ARIA(?), FORTEZZA(?)...
 
-Other ciphers like IDEA, RC2, RC4, 3DES or DES are weak and therefor not recommended:
+Other ciphers like IDEA, RC2, RC4, 3DES or DES are weak and therefore not recommended:
 \texttt{!DES:!3DES:!RC2:!RC4:!eNULL}
 
 \subsubsection{Message authentication}
index 50f9f60..0a7e66c 100644 (file)
@@ -69,7 +69,7 @@ Win 7 and Win 8.1 crypto stack, Opera 17, OpenSSL $\ge$ 1.0.1e, Safari 6 / iOS
 
 
 
-\subsubsection{Configuration B: Weaker ciphers, more compatability}
+\subsubsection{Configuration B: Weaker ciphers, more compatibility}
 
 In this section we propose a slightly weaker set of cipher suites.  For
 example, there are some known weaknesses for the SHA-1 hash function that is
@@ -155,7 +155,7 @@ Our recommended cipher strings are meant to be used via copy and paste and need
 \item AES256 and CAMELLIA256 count as very strong ciphers at the moment.
 \item AES128 and CAMELLIA128 count as strong ciphers at the moment
 \item DHE or ECDHE for forward secrecy
-\item RSA as this will fit most of todays setups
+\item RSA as this will fit most of today's setups
 \item AES256-SHA as a last resort (with this cipher at the end, even systems with
       legacy distributions of OpenSSL will work out of the box. Forward secrecy
       will not be available. On systems that do not support elliptic curves, that cipher
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 c16295b..21c87f1 100644 (file)
@@ -11,7 +11,7 @@ We start off by explaining the structure of cipher strings in section \ref{subse
 
 \vskip 0.5em
 We try to answer the questions by explaining issues with random number generators (section \ref{section:RNGs}), keylengths (section \ref{section:keylengths}), current issues in ECC (section \ref{section:EllipticCurveCryptography}), a note of warning on SHA-1 (section \ref{section:SHA}) and some comments on Diffie Hellman key exchanges (section \ref{section:DH}). All of this is important in understanding why certain choices were made for \textit{Cipher String A and B}. However, 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{subsection:compatibility}. 
-All these sections will allow a system administrator to balance his or her needs for strong encryption with useability and compatibility.
+All these sections will allow a system administrator to balance his or her needs for strong encryption with usability and compatibility.
 
 \vskip 0.5em
 
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}