added paragraph on missing functionality to choose between curves in software
authorAaron Zauner <azet@azet.org>
Thu, 14 Nov 2013 00:34:05 +0000 (01:34 +0100)
committerAaron Zauner <azet@azet.org>
Thu, 14 Nov 2013 00:34:05 +0000 (01:34 +0100)
src/ECC.tex

index e0dda98..953e720 100644 (file)
@@ -25,14 +25,18 @@ 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}}. 
-Those parameters came under question repeatedly from the cryptographers
+\footnote{\url{http://www.nist.gov}}. Wich were later widley implemented 
+in most common crypto libraries. Those parameters came under question 
+repeatedly from the 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}}.
 At the time of writing there is ongoing research as to the security of 
 various ECC parameters
-\footnote{\url{http://safecurves.cr.yp.to}}.
+\footnote{\url{http://safecurves.cr.yp.to}}. 
+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 widely be deployed 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