* Test all settings
+* Test with more clients and other OSes than OSX / iPhone!!
* document (cite) EVERYTHING! Why we chose certain values. Referneces, references, references. Otherwise it does not count!
Srsly!!
* .bib file is completely wrong. Make good citations/references.
updated, solid, well researched and thought-through guide for configuring SSL,
PGP, SSH and other cryptographic tools in the post-PRISM age. Since the NSA
leaks in the summer of 2013, many system administrators and IT security
-officers felt the need to update their encryption settings.
+officers see the need to update their encryption settings.
However, as Schneier
noted\footnote{\url{https://www.schneier.com/blog/archives/2013/09/the\_nsa\_is\_brea.html}},
next to using other means such as ``kinetic-decryption'' (breaking in, stealing
keys) or planting backdoors and rigging random number generators, etc.
-This following whitepaper can only address one aspect of securing our
+This whitepaper can only address one aspect of securing our
information systems: getting the crypto settings right. Other attacks, as the
above mentioned, require different protection schemes which are not covered in
this whitepaper.
\section{Disclaimer}
-This guide can only describe what the authors currently \emph{believe} to be the best settings based on their personal experience. This guide was cross checked by multiple people. For a complete list, see the appendix section "reviewers". Even though, multiple specialists reviewed the guide, the authors can give \emph{no guarantee} whatsover that they made the right recommendations. After all, tomorrow there might be a new attack on some ciphers and much of the recommendations in this guide will turn out to be wrong.
+This guide can only describe what the authors currently \emph{believe} to be the best settings based on their personal experience. This guide was cross checked by multiple people. For a complete list, see the appendix 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 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.
%% should we keep that sentence?
%% The authors do not know XXX FIXME XXX list things we don't know which affect the guide? XXX
\section{Keylengths}
+Recommendations on keylengths need to be adapted regularly. Since this document is static, we will rather refer to
+existing publications and websites. Recommending the right key length is a hit-and-miss issue.
+
+\url{http://www.keylength.com/} offers a good overview of safe keylengths, based on an analysis of multiple papers on the subject.
+
+In general, for asymmetric cryptography, any key length below 2048 bits is deprectated at the time of this writing.
+
%% NOTE XXXX FILL ME XXX
\section{Methods}
Since many years, NIST\footnote{\url{http://www.nist.gov/}} is the most
-prominent standardisation institute industry would consult for recommendations
-in the field of cryptography. However, the NSA leaks of 2013 showed that even
-certain NIST recommendations were
+prominent standardisation which institute industry would consult for
+recommendations in the field of cryptography. However, the NSA leaks of 2013
+showed that even certain NIST recommendations were
subverted\footnote{\url{http://www.scientificamerican.com/article.cfm?id=nsa-nist-encryption-scandal}}
by the NSA. As a consequence, NIST initiated a review process of their
standardisation
efforts\footnote{\url{http://csrc.nist.gov/groups/ST/crypto-review/index.html}}.
-However, for the purposes of this document and at the time of this writing, we
+For the purposes of this document and at the time of this writing, we
can not blindly trust NIST's recommendations on cipher and cipher suite
settings at this very moment.
Public peer-review / ``multiple eyes'' checking our recommendation is the best
strategy we can imagine at the moment.
-
C.O.S.H.E.R. = completely open source, headers, engineering and research!
\item symmetric cryptography
\end{itemize}
-The most common crypto software implementations support both modes of cryptography.
+The most common crypto software implementations support both modes cryptosystems.
\subsection{Typical cryptography libraries, frameworks and tools}
Most Server software (Webservers, Mail servers, etc.) can be configured to prefer certain cipher suites over others.
We followed the recommendations by Ivan Ristic's SSL/TLS Deployment Best Practices\footnote{\url{https://www.ssllabs.com/projects/best-practices/index.html}} document (see section 2.2 "Use Secure Protocols") and arrived at a list of recommended cipher suites for SSL enabled servers.
-The results of following his adivce is a categorisation of cipher suites.
+Following Ivan Ristic's adivce we arrived at a categorisation of cipher suites.
\begin{center}
\begin{tabular}{| l | l | l | l | l|}
\end{tabular}
\end{center}
-A remark on the ``consider'' section: the BSI (Bundesamt f\"ur Sicherheit in der Informationstechnik, Germany) recommends in its technical report TR-02102-2\footnote{\url{https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2_pdf.html}} to \textbf{avoid} non-ephemeral\footnote{ephemeral keys are session keys which are destroyed upon termination of the encrypted session. In TLS/SSL, they are realized by the DHE cipher suites. } keys for any communication which might contain personal or sensitive data. In this document, we follow BSI's advice and therefore only keep cipher suites containing (EC)DH\textbf{E} variants. System administrators, who can not use forward secrecy can still use the cipher suites in the consider section. We however, do not recommend them in this document.
+A remark on the ``consider'' section: the BSI (Federal office for information security, Germany) recommends in its technical report TR-02102-2\footnote{\url{https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2_pdf.html}} to \textbf{avoid} non-ephemeral\footnote{ephemeral keys are session keys which are destroyed upon termination of the encrypted session. In TLS/SSL, they are realized by the DHE cipher suites. } keys for any communication which might contain personal or sensitive data. In this document, we follow BSI's advice and therefore only keep cipher suites containing (EC)DH\textbf{E} (ephemeral) variants. System administrators, who can not use forward secrecy can still use the cipher suites in the ``consider'' section. We however, do not recommend them in this document.
%% NOTE: s/forward secrecy/perfect forward secrecy???
-Note that the entries marked as "special" are cipher suites which are not common to all clients (webbrowsers etc).
+Note that the entries marked as ``special'' are cipher suites which are not common to all clients (webbrowsers etc).
-\subsubsection{Client recommendations}
+\subsubsection{Tested clients}
Next we tested the cipher suites above on the following clients:
+%% NOTE: we need to test with more systems!!
\begin{itemize}
\item Chrome 30.0.1599.101 Mac OS X 10.9
\item Safari 7.0 Mac OS X 10.9
\end{table}
\end{center}
-Note: the tables \ref{table:prefOrderOpenSSLNames} and \ref{table:prefOrderCipherSuites} contains Eliptic curve key exchanges. There are currently strong doubts\footnote{\url{http://safecurves.cr.yp.to/rigid.html}} concerning ECC.
+Note: the tables \ref{table:prefOrderOpenSSLNames} and \ref{table:prefOrderCipherSuites} contain Eliptic curve key exchanges. There are currently strong doubts\footnote{\url{http://safecurves.cr.yp.to/rigid.html}} concerning ECC.
If unsure, remove the cipher suites starting with ECDHE in the table above.
We would like to express our thanks to the following reviewers (in alphabetical order):
+Horenbeck, Maarten;
+Lenzhofer, Stefan;
Schreck, Thomas;
\subsection{RNGs}
+%% NOTE: should we merge that with chapter 6.6??
\begin{itemize}
\item \href{http://www.fourmilab.ch/random/}{ENT} is a pseudo random number generator sequence tester.
\item \href{http://www.issihosts.com/haveged/}{HaveGE} is a tool which increases the Entropy of the Linux random number generator devices. It is based on the HAVEGE algorithm. \url{http://dl.acm.org/citation.cfm?id=945516}
git.bettercrypto.org / ach-master.git / commitdiff