Example usage
authorTobias Pape <tobias@netshed.de>
Fri, 17 Jan 2014 10:30:09 +0000 (11:30 +0100)
committerTobias Pape <tobias@netshed.de>
Sun, 6 Apr 2014 18:52:22 +0000 (20:52 +0200)
src/common/names.tex [new file with mode: 0644]
src/practical_settings/ssh.tex
src/practical_settings/vpn.tex
src/theory/cipher_suites/choosing.tex
src/theory/overview.tex

diff --git a/src/common/names.tex b/src/common/names.tex
new file mode 100644 (file)
index 0000000..d49bc71
--- /dev/null
@@ -0,0 +1,40 @@
+%%%
+%%% names.tex
+%%% All acronyms and names to be defined as used in the text
+%%%
+
+% Terms to index
+\doindex{Linux}
+\doindex{Diffie--Hellman}
+\doindex{elliptic curve}
+% Acronyms
+\newacronym{API}{api}{%
+  application programming interface}
+\newacronym{DH}{dh\alsoidx{Diffie--Hellman}}{%
+  Diffie--Hellman key exchange}
+\newacronym{DSA}{dsa}{%
+  Digital Signature Algorithm}
+\newacronym{ECC}{ecc\alsoidx{elliptic curve}}{%
+  elliptic curve cryptography}
+\newacronym{ECDH}{ecdh\alsoidx{Diffie--Hellman}\alsoidx{elliptic curve}}{%
+  elliptic curve Diffie--Hellman}
+\newacronym{ECDSA}{ecdsa}{...}
+\newacronym{EDH}{edh}{...}
+\newacronym{EECDH}{eecdh\alsoidx{Diffie--Hellman}\alsoidx{elliptic curve}}{%
+  elliptic curve ephemeral Diffie--Hellman}
+\newacronym{PFS}{pfs}{%
+  perfect forward secrecy}
+\newacronym{RSA}{rsa}{}
+
+% Glossary entries
+\newglossaryentry{firewall}{%
+  name=firewall,
+  description={technological barrier designed to prevent unauthorized or
+    unwanted communications between computer networks or hosts[duckduckgo]}
+}
+
+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "../applied-crypto-hardening"
+%%% End: 
index 978fbc4..2b08a2d 100644 (file)
@@ -21,7 +21,7 @@ settings}
 \configfile{6.0/sshd_config}{9-13,27-28,44-44,64-66}{Important OpenSSH 6.0 security
 settings}
 
-\textbf{Note:} Older Linux systems won't support SHA2. PuTTY (Windows) does not support
+\textbf{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.6p1). DSA host keys have been removed on purpose, the DSS standard does not
 support for DSA keys stronger than 1024bit
index f59e7af..75ff1ff 100644 (file)
@@ -113,9 +113,12 @@ label=tab:IPSEC_ph2_params,
 \end{itemize*}
 
 
-%---------------------------------------------------------------------- 
+%----------------------------------------------------------------------
 \subsection{Check Point FireWall-1}
 
+% Attention, only example...
+Checkpoint firewall is a \gls{firewall} that ....
+
 \subsubsection{Tested with Versions}
 \begin{itemize*}
   \item R77 (should work with any currently supported version)
index f136709..73d1b1d 100644 (file)
@@ -24,9 +24,9 @@ support of these low-security algorithms is disabled by setting
 
 \subsubsection{Key Exchange}
 
-Many algorithms allow secure key exchange.  Those are RSA, DH, EDH, ECDSA,
-ECDH, EECDH amongst others. During the key exchange, keys used for authentication
-and symmetric encryption are exchanged. For RSA, DSA and ECDSA those keys are derived
+Many algorithms allow secure key exchange.  Those are \ac{RSA}, \ac{DH}, \ac{EDH}, \ac{ECDSA},
+\ac{ECDH}, \ac{EECDH} amongst others. During the key exchange, keys used for authentication
+and symmetric encryption are exchanged. For \ac{RSA}, \ac{DSA} and \ac{ECDSA} those keys are derived
 from the server's public key.
 
 \todo{explain this section}
index 8dbe4e7..eafa00e 100644 (file)
@@ -6,7 +6,7 @@
 
 This chapter provides the necessary background information on why chapter \ref{chapter:PracticalSettings} recommended \textit{cipher string B}.
 
-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}. This concludes the section on cipher strings. In theory, the reader should now be able to construct his or her own cipher string. However, the question why certain settings were chosen still remains. To answer this part, we need to look at recommended keylengths, problems in specific algorithms and hash functions and other cryptographic parameters. As mentioned initially in section \ref{section:relatedPublications}, the ENISA~\cite{ENISA2013}, ECRYPT 2~\cite{ii2011ecrypt} and BSI~\cite{TR02102} reports go much more into these topics and should be consulted in addition.
+We start off by explaining the structure of cipher strings in section \ref{subsection:architecture} (architecture) and define \ac{PFS} in \ref{subsection:PFS}. Next we present \textit{Cipher String A} and \textit{Cipher String B} in section \ref{section:recommendedciphers}. This concludes the section on cipher strings. In theory, the reader should now be able to construct his or her own cipher string. However, the question why certain settings were chosen still remains. To answer this part, we need to look at recommended keylengths, problems in specific algorithms and hash functions and other cryptographic parameters. As mentioned initially in section \ref{section:relatedPublications}, the ENISA~\cite{ENISA2013}, ECRYPT 2~\cite{ii2011ecrypt} and BSI~\cite{TR02102} reports go much more into these topics and should be consulted in addition.
 
 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 usability and compatibility.