More work on BiBTeX
authorRalf Schlatterbeck <rsc@runtux.com>
Thu, 12 Dec 2013 14:38:08 +0000 (15:38 +0100)
committerRalf Schlatterbeck <rsc@runtux.com>
Thu, 12 Dec 2013 14:38:08 +0000 (15:38 +0100)
In particular remove duplicate entries from security.bib and
all-rfcs.bib and added all-rfcs to the list of search bibtex files.
Also add all missing wikipedia entries from text and add entries with
multiple citations where one of them was a wikipedia entry.

src/ECC.tex
src/PKIs.tex
src/abstract.tex
src/bib.tex
src/disclaimer.tex
src/links.tex
src/security.bib
src/ssllibs.tex

index 2ebd986..e3b5aa0 100644 (file)
@@ -5,10 +5,7 @@ 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.
-\footnote{\url{http://www.mccurley.org/papers/dlog.pdf}} 
-\footnote{\url{http://en.wikipedia.org/wiki/Discrete\_logarithm}}
-\footnote{\url{http://mathworld.wolfram.com/EllipticCurve.html}}.
+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 
@@ -29,10 +26,7 @@ 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
-\footnote{\url{http://cr.yp.to/talks/2013.09.16/slides-djb-20130916-a4.pdf}}
-\footnote{\url{https://www.schneier.com/blog/archives/2013/09/the\_nsa\_is\_brea.html\#c1675929}}
-\footnote{\url{http://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters}}.
+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
index 4efe3c9..c149879 100644 (file)
@@ -27,6 +27,5 @@ A good background on PKIs can be found in
   Discussion about OCSP and CRLs. TD: Useful Firefox plugins: CipherFox, Conspiracy, Perspectives.}
 
 
-%``Certification
-%Policy''\footnote{\url{http://en.wikipedia.org/wiki/Certificate_Policy}}
+%``Certificate Policy''\cite{Wikipedia:Certificate_Policy}
 %(CA)
index adb107a..7e76064 100644 (file)
@@ -9,8 +9,7 @@ This guide is specifically written for these system administrators.
 
 \vskip 0.5em
 
-As Schneier
-noted\footnote{\url{https://www.schneier.com/blog/archives/2013/09/the\_nsa\_is\_brea.html}},
+As Schneier noted\cite{Sch13},
 it seems that intelligence agencies and adversaries on the Internet are not
 breaking so much the mathematics of encryption per se, but rather use software
 and hardware weaknesses, subvert standardization processes, plant backdoors,
index 073b7b6..bfc8ac2 100644 (file)
@@ -1 +1 @@
-\bibliography{security}
+\bibliography{security,all-rfcs}
index 008f373..45c4068 100644 (file)
@@ -1,6 +1,12 @@
 \section{Disclaimer}
 \label{section:disclaimer}
-This guide specifically does not address physical security, protecting software and hardware against exploits, basic IT security housekeeping, anti-tempest\footnote{\url{https://en.wikipedia.org/wiki/Tempest\_(codename)}} attack techniques, protecting against side-channel attacks, downgrade attacks, jamming the encrypted channel or other similar attacks which are typically employed to circumvent strong encryption. The authors can not overstate the importance of these other techniques.
+This guide specifically does not address physical security, protecting
+software and hardware against exploits, basic IT security housekeeping,
+anti-tempest\cite{Wikipedia:Tempest} attack techniques, protecting
+against side-channel attacks, downgrade attacks, jamming the encrypted
+channel or other similar attacks which are typically employed to
+circumvent strong encryption. The authors can not overstate the
+importance of these other techniques.
 
 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 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 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.
 
index 6855e18..42d3e56 100644 (file)
@@ -19,6 +19,6 @@
 \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 ECC-enabled GnuPG per RFC6637 \url{https://code.google.com/p/gnupg-ecc}
+\item Diffie-Hellman Groups standardised 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}
 \end{itemize}
index baaa9e5..e3f2260 100644 (file)
@@ -1,9 +1,27 @@
+@string {J_AM =
+    {\hyperref{http://stackexchange.com/}{}{}{Proceedings}
+     \hyperref{http://stackexchange.com/}{}{}{of}
+     \hyperref{http://stackexchange.com/}{}{}{Symposia}
+     \hyperref{http://stackexchange.com/}{}{}{in}
+     \hyperref{http://stackexchange.com/}{}{}{Applied}
+     \hyperref{http://stackexchange.com/}{}{}{Mathematics}}
+}
 @string {I_PolarSSL =
     {\hyperref{http://polarssl.org/}{}{}{PolarSSL}}
 }
+@string {I_Stackexchange =
+    {\hyperref{http://stackexchange.com/}{}{}{Stackexchange}
+     \hyperref{http://stackexchange.com/}{}{}{Q\&A}
+     \hyperref{http://stackexchange.com/}{}{}{Site}}
+}
 @string {I_Wikipedia =
     {\hyperref{http://wikipedia.org/}{}{}{Wikipedia}}
 }
+@string {I_Wolfram =
+    {\hyperref{http://mathworld.wolfram.com/}{}{}{Wolfram} 
+     \hyperref{http://mathworld.wolfram.com/}{}{}{Research} 
+     \hyperref{http://mathworld.wolfram.com/}{}{}{Mathworld}}
+}
 @string {J_TOMACS =
     {\hyperref{http://tomacs.acm.org/}{}{}{ACM}
      \hyperref{http://tomacs.acm.org/}{}{}{Transactions}
   publisher={Chapman \& Hall/CRC}
 }
 
-@misc{rfc3526,
-  author="T. Kivinen and M. Kojo",
-  title="{More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)}",
-  series="Request for Comments",
-  number="3526",
-  howpublished="RFC 3526 (Proposed Standard)",
-  publisher="IETF",
-  organization="Internet Engineering Task Force",
-  year=2003,
-  month=may,
-    url="http://www.ietf.org/rfc/rfc3526.txt",
-}
-
 @techreport{DJBSC,
    key       = {DJB},
    title     = {SafeCurves: choosing safe curves for elliptic-curve cryptography},
 
 @techreport{Wikipedia:ExportCipher,
    key       = {Wikipedia:ExportCipher},
-   title     = {Export of cryptography in the United States},
+   title     = {Export of cryptography in the {U}nited {S}tates},
    institution = I_Wikipedia,
    year      = {2013},
    month     = Dec,
    url       = {http://en.wikipedia.org/wiki/Export_of_cryptography_in_the_United_States},
    note      = {Accessed 2013-12-09},
 }
+
+@techreport{Wikipedia:Tempest,
+   key       = {Wikipedia:Tempest},
+   title     = {Tempest (codename)},
+   institution = I_Wikipedia,
+   year      = {2013},
+   month     = Dec,
+   type      = {Wikipedia},
+   url       = {https://en.wikipedia.org/wiki/Tempest_(codename)},
+   note      = {Accessed 2013-12-12},
+}
+
+@techreport{Wikipedia:Discrete,
+   key       = {Wikipedia:Discrete},
+   title     = {Discrete logarithm},
+   institution = I_Wikipedia,
+   year      = {2013},
+   month     = Dec,
+   type      = {Wikipedia},
+   url       = {https://en.wikipedia.org/wiki/Discrete_logarithm},
+   note      = {Accessed 2013-12-12},
+}
+
+@techreport{Wikipedia:Certificate,
+   key       = {Wikipedia:Certificate},
+   title     = {Certificate Policy},
+   institution = I_Wikipedia,
+   year      = {2013},
+   month     = Dec,
+   type      = {Wikipedia},
+   url       = {https://en.wikipedia.org/wiki/Certificate_Policy},
+   note      = {Accessed 2013-12-12},
+}
+
+@techreport{Sch13,
+   author    = {Bruce Schneier},
+   title     = {The {NSA} Is Breaking Most Encryption on the Internet},
+   year      = {2013},
+   month     = Sep,
+   type      = {Blog: Schneier on Security},
+   url       = {https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html},
+}
+
+@techreport{Sch13b,
+   author    = {Bruce Schneier},
+   title     = {The {NSA} Is Breaking Most Encryption on the Internet},
+   year      = {2013},
+   month     = Sep,
+   type      = {Answer to Blog Comment},
+   url       = {https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html\#c1675929},
+}
+
+@techreport{BL13,
+   author    = {D. J. Bernstein and Tanja Lange},
+   title     = {Security dangers of the {NIST} curves},
+   year      = {2013},
+   month     = Sep,
+   type      = {Presentation slides},
+   url       = {http://cr.yp.to/talks/2013.09.16/slides-djb-20130916-a4.pdf},
+}
+
+@techreport{W13,
+   author    = {D. W.},
+   title     = {Should we trust the {NIST}-recommended {ECC} parameters?},
+   year      = {2013},
+   month     = Sep,
+   type      = {Stackexchange Question},
+   institution = I_Stackexchange,
+   url       = {http://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters},
+}
+
+@inproceedings{McC90,
+   author    = {Kevin S. McCurley},
+   title     = {The Discrete Logarithm Problem},
+   booktitle = {Cryptology and Computational Number Theory, } # J_AM,
+   year      = {1990},
+   volume    = {42},
+   pages     = {49-74},
+   url       = {http://www.mccurley.org/papers/dlog.pdf},
+}
+
+@techreport{WR13,
+   key       = {Wolfram Research, Mathworld},
+   title     = {Elliptic Curve},
+   year      = {2013},
+   month     = Dec,
+   type      = {Math Dictionary Entry},
+   institution = I_Wolfram,
+   url       = {http://mathworld.wolfram.com/EllipticCurve.html},
+   note      = {Accessed 2013-12-12},
+}
+
index 5b638c6..a561309 100644 (file)
@@ -24,7 +24,8 @@ systems) you might need to change the cipher string. The hex code for a cipher
 string however is common to all versions and and library implementations:
 \texttt{TLS\_RSA\_CAMELLIA\_256\_CBC\_SHA1} in GnuTLS is equivalent to
 \texttt{CAMELLIA256-SHA} in OpenSSL and \texttt{TLS\_RSA\_WITH\_CAMELLIA\_256\_CBC\_SHA}
-in the IANA standard with the hex code \texttt{0x00,0x84} as specified in RFC5932.
+in the IANA standard with the hex code \texttt{0x00,0x84} as specified
+in RFC5932\cite{rfc5932}.
 
 In any way, as a sysadmin you are required to check what the SSL libraries on
 your systems support on how you may get the most security out of your systems.