Commit 1ff0f1e3 authored by Benoit Viguier's avatar Benoit Viguier
Browse files

done

parent f31d2302
......@@ -2,8 +2,8 @@
\begin{abstract}
By using the Coq formal proof assistant, we first extend
the formalization of elliptic curves of Bartzia and Strub \cite{DBLP:conf/itp/BartziaS14} to support
Montgomery curves. Then with the Verified Software Toolchain \cite{2012-Appel}
the formalization of elliptic curves of Bartzia and Strub to support
Montgomery curves. Then with the Verified Software Toolchain
we prove the soundness and correctness of TweetNaCl's Curve25519 implementation.
\end{abstract}
\section{Introduction}
TweetNaCl\cite{BGJ+15} is a compact reimplementation of the
NaCl\cite{BLS12} library. It does not aim for high speed
application and has been optimized for source code compactness.
It maintains some degree of readability in order to be easily auditable.
NaCl\cite{BLS12} high security cryptographic library.
It does not aim for high speed application and has been optimized for source
code compactness (100 tweets). It maintains some degree of readability in order
to be easily auditable.
This library makes use of Curve25519\cite{Ber06}, a function over a \F{p}-restricted
$x$-coordinate computing a scalar multiplication on $E(\F{p^2})$, where $p$ is
the prime number $\p$ and $E$ is the elliptic curve $y^2 = x^3 + 486662 x^2 + x$.
This function is used by a wide variety of applications \cite{this-that-use-curve25519}
This function is used by a wide variety of applications\cite{this-that-use-curve25519}
to establish a shared secret over an insecure channel.
Implementing cryptographic primitives without any bugs is difficult.
While tests provides with code coverage,
they still don't cover 100\% of the possible input values.
In order to get formal guaranties a software meets its specifications,
two methodologies exist.
The first one is by synthesizing a formal specification and
generating machine code by refinment. This approach is being used in the
B-method\cite{Abrial:1996:BAP:236705}, HACL*\cite{zinzindohoue2017hacl} and F* \cite{DBLP:journals/corr/BhargavanDFHPRR17}
with Kremlin, or with Coq \cite{CpdtJFR}.
This gives you a software correct by construction. However it cannot be applied
to an existing piece of software. In such case we need to write the specifications
and then verify the correctness of the implementation.
While tests provides with code coverage, they still don't cover 100\% of the
possible input values. In order to get formal guaranties a software meets its
specifications, two methodologies exist.
The first one is by synthesizing a formal specification and generating machine
code by refinment in order to get a software correct by construction.
This approach is being used in e.g. the B-method\cite{Abrial:1996:BAP:236705},
F* \cite{DBLP:journals/corr/BhargavanDFHPRR17}, or with Coq \cite{CpdtJFR}.
However this first method cannot be applied to an existing piece of software.
In such case we need to write the specifications and then verify the correctness
of the implementation.
\subsection{Our Formal Approach}
Verifying an existing cryptographic library, we use the second approach.
Our method can be seen as a static analysis over the input values coupled
with the formal proof that the code of the algorithm matches its specification.
Similar approaches have been used to prove the correctness of OpenSSL HMAC
\cite{Beringer2015VerifiedCA} and SHA-256 \cite{2015-Appel}.
Coq is a formal system that allows to machine-check our proofs.
We use Coq\cite{coq-faq}, a formal system that allows us to machine-check our proofs.
A famous example of its use is the proof of the Four Color Theorem \cite{gonthier2008formal}.
The Compcert\cite{Leroy-backend} compiler and the Verifiable Software Toolchain
(VST)\cite{2012-Appel} are build on top of it.
Our approach is as follow, we use the \textit{clightgen} tool from Compcert to
generate the \textit{semantic version} (Clight\cite{Blazy-Leroy-Clight-09}) of
the TweetNaCl C code.
Using the Separation logic\cite{1969-Hoare,Reynolds02separationlogic}
with with the Verifiable Software Toolchain we show that the semantics of the
program satisfies a functionnal specification in Coq.
We extend the work of Bartzia and Strub \cite{DBLP:conf/itp/BartziaS14} to
support Montgomery curves.
With this formalization, we prove the correctness of a generic Montgomery ladder
and show that our specification is an instance of it.
\todo[inline]{Add where the software is available}
The CompCert, a C compiler\cite{Leroy-backend} proven correct and sound is being build on top of it.
To prove its correctness, CompCert uses multiple intermediate languages. The first step of CompCert is done by the parser \textit{clightgen}.
It takes as input C code and generates its Clight\cite{Blazy-Leroy-Clight-09} translation.
Using this intermediate representation Clight, we use the Verifiable Software Toolchain
(VST)\cite{2012-Appel}, a framework which uses Separation logic\cite{1969-Hoare,Reynolds02separationlogic}
and shows that the semantics of the program satisfies a functionnal specification in Coq.
VST steps through each line of Clight using a strongest post-condition strategy.
We write a specification of the crypto scalar multiplication of TweetNaCl and using
VST we prove that the code matches our definitions.
Bartzia and Strub wrote a formal library for elliptic curves\cite{DBLP:conf/itp/BartziaS14}.
We extend it to support Montgomery curves. With this formalization, we prove the
correctness of a generic Montgomery ladder and show that our specification is an instance of it.
\subsection{Related Works}
Similar approaches have been used to prove the correctness of OpenSSL HMAC
\cite{Beringer2015VerifiedCA} and SHA-256 \cite{2015-Appel}. Compared to their work
our approaches makes a complete link between the C implementation and the formal
mathematical definition of the group theory behind elliptic curves.
Using the synthesis approach, Zinzindohou{\'{e}} et al. wrote an verified extensible
library of elliptic curves\cite{Zinzindohoue2016AVE}. This served as ground work for the
cryptographic library HACL*\cite{zinzindohoue2017hacl} used in the NSS suite from Mozilla.
Coq does not only allows verification but also synthesis.
Using correct-by-construction finite field arithmetic\cite{Philipoom2018CorrectbyconstructionFF}
one can synthesize\cite{Erbsen2016SystematicSO} certified elliptic curve
implementations\cite{Erbsen2017CraftingCE}. These implementation are now being used in BoringSSL\cite{fiat-crypto}.
Curve25519 implementations has already been under the scrutiny \cite{Chen2014VerifyingCS}.
However in this paper we provide a proofs of correctness and soundness of a C program up to
the theory of elliptic curves.
\subsection{Organization of this paper and reproducibility}
To maximize reusability of our results we placed the code of our formal proofs
presented in this paper into the public domain. They are available at XXXXXXX
with instructions of how to compile and verify our proofs.
Section \ref{sec2-implem} gives the necessary background on Curve25519
implementation in TweetNaCl and provides the specifications we later prove correct.
Section \ref{sec3-maths} describes our extension of the formal library by Bartzia and Strub.
Section \ref{sec4-refl} makes the link between the mathematical model and the C implementation.
In this section we also describe some of the techniques we used to speed up some of the proofs.
Section \ref{sec5-vst} provides with attention points a VST user should be careful
of in order to avoid unnecessary work.
% Five years ago:
% \url{https://www.imperialviolet.org/2014/09/11/moveprovers.html}
......
\section{Curve25519 implementation}
\section{Curve25519 Implementation}
\label{sec2-implem}
In this section we present in detail the algorithm computing the crypto scalar multiplication.
We then discuss which proofs are required.
......@@ -77,8 +78,8 @@ sv car25519(gf o)
At the end of the Montgomery ladder, \texttt{inv25519} computes the inverse over \Zfield.
It uses Fermat's little theorem by the exponentiation to
$2^{255}-21$ with the Square-and-multiply algorithm. It takes
advantage of the shape of the number by not doing the multiplications only twice.
$2^{255}-21$ with the Square-and-multiply algorithm.
% It takes advantage of the shape of the number by not doing the multiplications only twice.
The last step of \texttt{crypto\_scalarmult} is the packing of the limbs: an array of 32 bytes.
It first performs 3 carry propagations in order to guarantee
......@@ -212,7 +213,7 @@ This garantees us the correctness of the implementation.
\label{tk:ProofStructure}
\end{figure}
\subsection{Correctness specification}
\subsection{Correctness Specification}
We show the soundness of TweetNaCl by proving the following specification matches a pure Coq function.
This defines the equivalence between the Clight representation and a Coq definition of the ladder.
......
\section{Mathematical Model}
\label{sec3-maths}
In this section we first present the work of Bartzia and Strub \cite{DBLP:conf/itp/BartziaS14} (\ref{Weierstrass}).
We extend it to support Montgomery curves (\ref{montgomery}) with homogeneous coordinates (\ref{projective}) and prove the correctness of the ladder (\ref{ladder}).
......@@ -22,7 +23,7 @@ solutions $(x,y)$ of $E$ augmented by a distinguished point $\Oinf$ (called poin
$$E(\K) = \{(x,y) \in \K \times \K | E(x,y)\} \cup \{\Oinf\}$$
\end{definition}
\subsubsection{Weierstra{\ss} curves}
\subsubsection{Weierstra{\ss} Curves}
\label{Weierstrass}
This equation $E(x,y)$ can be reduced into its Weierstra{\ss} form.
......@@ -84,7 +85,7 @@ Definition addec (p1 p2 : ec) : ec :=
EC p1 p2 (addO p1 p2)
\end{lstlisting}
\subsubsection{Montgomery curves}
\subsubsection{Montgomery Curves}
\label{montgomery}
Computation over elliptic curves are hard. Speedups can be obtained by using
homogeneous coordinates and other forms than the Weierstra{\ss} form. We consider
......@@ -161,7 +162,7 @@ Definition ec_of_mc p :=
Lemma ec_of_mc_bij : bijective ec_of_mc.
\end{lstlisting}
\subsubsection{Projective coordinates}
\subsubsection{Projective Coordinates}
\label{projective}
Points on a projective plane are represented with a triple $(X:Y:Z)$. Any points except $(0:0:0)$ defines a point on a projective plane. A scalar multiple of a point defines the same point, \ie
for all $\alpha \neq 0$, $(X:Y:Z)$ and $(\alpha X:\alpha Y:\alpha Z)$ defines the same point. For $Z\neq 0$, the projective point $(X:Y:Z)$ corresponds to the point $(X/Z,Y/Z)$ on the Euclidian plane, likewise the point $(X,Y)$ on the Euclidian plane corresponds to $(X:Y:1)$ on the projective plane.
......@@ -406,12 +407,6 @@ $$\forall x \in \K,\ x^2 \neq a^2-4$$
As Curve25519 is defined over the field $\K = \F{p^2}$, there exists $x$ such that $x^2 = a^2-4$.
We first study Curve25519 and one of the quadratic twist Twist25519, first defined over \F{p}.
% In order to differentiate curves on $\F{p}$ and $\F{p^2}$, we pose $\B = \F{p}$ (as Base field) and $\E = \F{p^2}$ (as Extension field).
% We consider the following notation:
% $M_{a,b,\B}$ as opposed to $M_{a,b,\E}$
\subsubsection{Curves and Twists}
We define $\F{p}$ as the numbers between $0$ and $p = \p$.
......
\section{Representation and Reflections}
\label{sec4-refl}
In this section we describe techniques used to prove the equivalence between the
Clight description of TweetNaCl and Coq functions producing similar behaviors.
\subsection{Number representation and C implementation}
\subsection{Number Representation and C Implementation}
As described in Section \ref{sec:impl}, numbers in \TNaCle{gf} are represented
in base $2^{16}$ and we use a direct mapping to represent that array as a list
......@@ -287,7 +288,7 @@ Corollary Inv25519_Zpow_GF :
(pow (Z16.lst g) (2^255-21)) :GF.
\end{Coq}
\subsection{Packing and other applications of reflection}
\subsection{Packing and other Applications of Reflection}
We prove the functional correctness of \Coqe{Inv25519} with reflections.
This technique can also be used where proofs requires some computing or a small and
......
\section{VST and the Trust of the proof}
\section{Trust in the proof and VST}
\label{sec5-vst}
Any formal system relies on a trusted base. In this section we describe our
chain of trust bringing up to light some tripping points a user may encounter
......@@ -60,35 +61,50 @@ o[i] = aux1 + aux2;
\subsection{Using the Verifiable Software Toolchain}
Proving a few lines of code with VST requires to have a good knowledge of what
each line of code will do when executed. A user will want to specify a pure Coq
implementations which will be close to a 1:1 mapping with the C implementation.
This will simplify the proof and help with stepping throught the program.
We call this step a Low level specification. A user will then have an easier
The Verifiable Software Toolchain uses a strongest postcondition strategy.
The user must first write a formal specification of the function he wants to verify in Coq.
This should be as close as possible to the C implementation behavior.
This will simplify the proof and help with stepping throught the CLight version of the software.
With the range of inputes defined, VST steps mechanically through each instruction
and ask the user to verify auxiliary goals such as array bound access, or absence of overflows/underflows.
We call this specification a low level specification. A user will then have an easier
time to prove that his low level specification matches a simpler higher level one.
In order to further speed-up the verification process, it should be know that
in order to prove \VSTe{crypto_scalarmult}, a user only need the specification
of e.g. \VSTe{M}. This provide with multiple advantages: the verification by the
kernel can be done in parallel and multiple users can work on proving different
functions at the same time. For the sake of completeness we proved all intermediate
functions.
In order to further speed-up the verification process, it has to be know that to
prove \VSTe{crypto_scalarmult}, a user only need the specification of e.g. \VSTe{M}.
This provide with multiple advantages: the verification by the Coq kernel can be done
in parallel and multiple users can work on proving different functions at the same time.
For the sake of completeness we proved all intermediate functions.
Memory aliasing is the next point a user should pay attention to. The way VST
deals with the separation logic is similar to a consumer producer problem.
A naive specification of \texttt{M(o,a,b)} will assume three distinct memory share.
A simple specification of \texttt{M(o,a,b)} will assume three distinct memory share.
When called with three memory share (\texttt{o, a, b}), the three of them will be consumed.
However when \texttt{M(o,a,a)} is called (squaring), the first two memory shares (\texttt{o, a})
are consumed and VST will expect a third memory share where the last \texttt{a} is pointing at.
This forces the user to define multiple specifications for a single function.
Example of such cases are summarized in Fig \ref{tk:MemSame}.
However assuming this naive specification when \texttt{M(o,a,a)} is called (squaring),
the first two memory shares (\texttt{o, a}) are consumed and VST will expect a third
memory share where the last \texttt{a} is pointing at which does not \textit{exist} anymore.
Examples of such cases are summarized in Fig \ref{tk:MemSame}.
\begin{figure}[h]
\include{tikz/memory_same_sh}
\caption{Aliasing and Separation Logic}
\label{tk:MemSame}
\end{figure}
\subsection{Verifiying \texttt{for} loops: head and tail recursion}
This forces the user to either define multiple specifications for a single function
or specify in his specification which aliasing version is being used.
For our specifications of functions with 3 arguments, named here after \texttt{o, a, b},
we define an additional parameter $k$ with values in
$\{0,1,2,3\}$:
\begin{itemize}
\item if $k=0$ then \texttt{o} and \texttt{a} are aliased.
\item if $k=1$ then \texttt{o} and \texttt{b} are aliased.
\item if $k=2$ then \texttt{a} and \texttt{b} are aliased.
\item else there is no aliasing.
\end{itemize}
This solution allows us to make cases analysis over possible aliasing.
\subsection{Verifiying \texttt{for} loops}
Final state of \texttt{for} loops are usually computed by simple recursive functions.
However we must define invariants which are true for each iterations.
......@@ -141,6 +157,22 @@ Lemma Tail_Head_equiv :
rec_fn n s = rec_fn_rev n s.
\end{Coq}
Using this formalization, we prove that the 255 steps of the montgomery ladder in C provide the same computations are the one defined in Algorithm \ref{montgomery-double-add}.
\todo[inline]{How many lines of specification ?}
\todo[inline]{How many lines of proofs ?}
\todo[inline]{How long did it take ?}
\subsection{Time and Space Complexity}
Our work can be split into multiple parts. Bellow we provide a approximation of
the lines of codes and thus an idea of the size of the proofs required to
complete this work.
\begin{itemize}
\item The proof that the Montgomery ladder over a generic field $\K$ respects
the elliptic curve theory and then it's specialization for $\F{p^2}$.
This represent 4218 lines of code for 0.75 man-year.
\item The multiple level definitions of the ladder and operations over lists,
their proof of correctness and soundness and additionally that the match with
the generic Montgomery ladder. This count for 22967 lines of code for about 1.5 man-year.
\item The proof that our specification matches the Clight translation with VST.
This count for 6934 lines of code for about 0.75 man-year.
\end{itemize}
While the proof with VST took slightly less time, having to provide proof that every
intermediate computations slows down the process significantly. However it is
necessary in order to garantee our the absences of overflows and underflows.
......@@ -10,6 +10,7 @@ depend:
clean:
@echo cleaning...
@rm -fr latex.out 2> /dev/null || true
@rm *.pdf 2> /dev/null || true
@rm *.aux 2> /dev/null || true
@rm *.bbl 2> /dev/null || true
......
......@@ -72,7 +72,7 @@
urlpublisher = {http://dx.doi.org/10.1007/s10817-009-9148-3}
}
@inproceedings{ BGJ+15,
@inproceedings{BGJ+15,
author = {Daniel J. Bernstein and Bernard van Gastel and Wesley Janssen and Tanja Lange and Peter Schwabe and Sjaak Smetsers},
title = {{TweetNaCl}: A crypto library in 100 tweets},
booktitle = {Progress in Cryptology -- {LATINCRYPT 2014}},
......@@ -85,7 +85,7 @@
note = {Document ID: c74b5bbf605ba02ad8d9e49f04aca9a2, \url{http://cryptojedi.org/papers/\#tweetnacl}},
}
@inproceedings{ BLS12,
@inproceedings{BLS12,
author = {Daniel J. Bernstein and Tanja Lange and Peter Schwabe},
title = {The security impact of a new cryptographic library},
booktitle = {Progress in Cryptology -- {LATINCRYPT 2012}},
......@@ -109,8 +109,8 @@
volume = {7226},
year = {2012},
pages = {2},
note = {\url{https://doi.org/10.1007/978-3-642-28891-3_2}},
url = {https://doi.org/10.1007/978-3-642-28891-3_2},
note = {\url{https://doi.org/10.1007/978-3-642-28891-3_2}},
doi = {10.1007/978-3-642-28891-3_2},
}
......@@ -127,8 +127,8 @@
pages = {7:1--7:31},
articleno = {7},
numpages = {31},
note = {\url{http://doi.acm.org/10.1145/2701415}},
url = {http://doi.acm.org/10.1145/2701415},
note = {\url{http://doi.acm.org/10.1145/2701415}},
doi = {10.1145/2701415},
acmid = {2701415},
publisher = {ACM},
......@@ -141,14 +141,6 @@
}
@misc{LHT16,
author = {Adam Langley and Michael Hamburg and Sean Turner},
title = {{RFC} 7748: Elliptic Curves for Security},
year = {2016},
note = {\url{https://www.rfc-editor.org/rfc/rfc7748.txt}},
}
@inproceedings{Ber06,
author = {Daniel J. Bernstein},
title = {Curve25519: new {D}iffie-{H}ellman speed records},
......@@ -207,6 +199,7 @@
publisher = {Cambridge University Press},
address = {New York, NY, USA},
}
note = {\url{https://books.google.nl/books?id=T_ShHENlqBAC&lpg=PR4&pg=PP1#v=onepage&q&f=false}}
@article{DBLP:journals/corr/BhargavanDFHPRR17,
author = {Karthikeyan Bhargavan and
......@@ -228,92 +221,107 @@
year = {2017},
publisher = {ACM},
url = {http://arxiv.org/abs/1703.00053},
note = {\url{http://arxiv.org/abs/1703.00053}},
eprint = {1703.00053},
timestamp = {Mon, 13 Aug 2018 16:46:57 +0200},
biburl = {https://dblp.org/rec/bib/journals/corr/BhargavanDFHPRR17},
bibsource = {dblp computer science bibliography, https://dblp.org},
}
@article{Zinzindohoue2016AVE,
title={A Verified Extensible Library of Elliptic Curves},
author={Jean Karim Zinzindohoue and Evmorfia-Iro Bartzia and Karthikeyan Bhargavan},
journal={2016 IEEE 29th Computer Security Foundations Symposium (CSF)},
year={2016},
pages={296-309}
title = {A Verified Extensible Library of Elliptic Curves},
author = {Jean Karim Zinzindohoue and Evmorfia-Iro Bartzia and Karthikeyan Bhargavan},
journal = {2016 IEEE 29th Computer Security Foundations Symposium (CSF)},
year = {2016},
pages = {296-309},
note = {\url{https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7536383}}
}
@inproceedings{Chen2014VerifyingCS,
title={Verifying Curve25519 Software},
author={Yu-Fang Chen and Chang-Hong Hsu and Hsin-Hung Lin and Peter Schwabe and Ming-Hsien Tsai and Bow-Yaw Wang and Bo-Yin Yang and Shang-Yi Yang},
booktitle={ACM Conference on Computer and Communications Security},
year={2014}
title = {Verifying Curve25519 Software},
author = {Yu-Fang Chen and Chang-Hong Hsu and Hsin-Hung Lin and Peter Schwabe and Ming-Hsien Tsai and Bow-Yaw Wang and Bo-Yin Yang and Shang-Yi Yang},
booktitle = {ACM Conference on Computer and Communications Security},
year = {2014},
note = {\url{https://cryptojedi.org/papers/verify25519-20140428.pdf}}
}
@inproceedings{Beringer2015VerifiedCA,
title={Verified Correctness and Security of OpenSSL HMAC},
author={Lennart Beringer and Adam Petcher and Katherine Q. Ye and Andrew W. Appel},
booktitle={USENIX Security Symposium},
year={2015}
title = {Verified Correctness and Security of OpenSSL HMAC},
author = {Lennart Beringer and Adam Petcher and Katherine Q. Ye and Andrew W. Appel},
booktitle = {USENIX Security Symposium},
year = {2015},
note = {\url{https://www.cs.cmu.edu/~kqy/resources/verified-hmac.pdf}}
}
@inproceedings{Erbsen2017CraftingCE,
title={Crafting certified elliptic curve cryptography implementations in Coq},
author={Andres Erbsen},
year={2017}
title = {Crafting certified elliptic curve cryptography implementations in Coq},
author = {Andres Erbsen},
year = {2017},
note = {\url{http://adam.chlipala.net/theses/andreser_meng.pdf}}
}
@inproceedings{Philipoom2018CorrectbyconstructionFF,
title={Correct-by-construction finite field arithmetic in Coq},
author={Jade Philipoom},
year={2018}
title = {Correct-by-construction finite field arithmetic in Coq},
author = {Jade Philipoom},
year = {2018},
note = {\url{http://adam.chlipala.net/theses/jadep_meng.pdf}}
}
@inproceedings{Erbsen2016SystematicSO,
title={Systematic Synthesis of Elliptic Curve Cryptography Implementations},
author={Andres Erbsen and Jason Gross and Adam Chlipala},
year={2016}
title = {Systematic Synthesis of Elliptic Curve Cryptography Implementations},
author = {Andres Erbsen and Jason Gross and Adam Chlipala},
year = {2016},
note = {\url{https://people.csail.mit.edu/jgross/personal-website/papers/2017-fiat-crypto-pldi-draft.pdf}}
}
@inproceedings{Erbsen2019SimpleHC,
title={Simple High-Level Code for Cryptographic Arithmetic - With Proofs, Without Compromises},
author={Andres Erbsen and Jade Philipoom and Jason Gross and Robert H. Sloan and Adam Chlipala},
booktitle={S&P 2019},
year={2019}
@inproceedings{fiat-crypto,
title = {Simple High-Level Code For Cryptographic Arithmetic -- With Proofs, Without Compromises},
author = {Andres Erbsen and Jade Philipoom and Jason Gross and Robert Sloan and Adam Chlipala},
booktitle = {Proceedings of the \href{https://www.ieee-security.org/TC/SP2019/}{40th IEEE Symposium on Security and Privacy (S\&P'19)}},
year = {2019},
month = {May},
code-github = {https://github.com/mit-plv/fiat-crypto},
owner = {jgross},
timestamp = {2018.06.01},
url = {https://people.csail.mit.edu/jgross/personal-website/papers/2019-fiat-crypto-ieee-sp.pdf},
note = {\url{https://people.csail.mit.edu/jgross/personal-website/papers/2019-fiat-crypto-ieee-sp.pdf}}
}
@Article{CpdtJFR,
author = {Adam Chlipala},
title = {An Introduction to Programming and Proving with Dependent Types in Coq},
volume = {3(2)},
pages = {1-93},
year = {2010},
journal = {Journal of Formalized Reasoning},
url = {http://adam.chlipala.net/papers/CpdtJFR/}
author = {Adam Chlipala},
title = {An Introduction to Programming and Proving with Dependent Types in Coq},
volume = {3(2)},
pages = {1-93},
year = {2010},
journal = {Journal of Formalized Reasoning},
url = {http://adam.chlipala.net/papers/CpdtJFR/},
note = {\url{http://adam.chlipala.net/papers/CpdtJFR/}}
}
@article{gonthier2008formal,
title={Formal proof--the four-color theorem},
author={Gonthier, Georges},
journal={Notices of the AMS},
volume={55},
number={11},
pages={1382--1393},
year={2008}
title = {Formal proof--the four-color theorem},
author = {Georges Gonthier},
journal = {Notices of the AMS},
volume = {55},
number = {11},
pages = {1382--1393},
year = {2008},
note = {\url{https://www.ams.org/notices/200811/tx081101382p.pdf}}
}
@misc{this-that-use-curve25519,
title ={Things that use Curve25519},
author={},
url = {https://ianix.com/pub/curve25519-deployment.html},
note = {\url{https://ianix.com/pub/curve25519-deployment.html}}
title = {Things that use Curve25519},
author = {},
url = {https://ianix.com/pub/curve25519-deployment.html},
note = {\url{https://ianix.com/pub/curve25519-deployment.html}}
}
@inproceedings{zinzindohoue2017hacl,
title={HACL*: A verified modern cryptographic library},
author={Zinzindohou{\'e}, Jean-Karim and Bhargavan, Karthikeyan and Protzenko, Jonathan and Beurdouche, Benjamin},
booktitle={Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security},
pages={1789--1806},
year={2017},
organization={ACM}
title = {HACL*: A verified modern cryptographic library},
author = {Jean-Karim Zinzindohou{\'e} and Karthikeyan Bhargavan and Jonathan Protzenko and Benjamin Beurdouche},
booktitle = {Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security},
pages = {1789--1806},
year = {2017},
organization = {ACM},
note = {\url{https://eprint.iacr.org/2017/536.pdf}}
}
......@@ -75,16 +75,13 @@ The Netherlands}
\input{2_Implementation.tex}
\input{3_Maths.tex}
\input{4_NumberAndImplementation.tex}
\input{5_RelatedWorks.tex}
\input{6_UsingVST.tex}
\input{5_UsingVST.tex}
\vspace*{1cm}
{\footnotesize \bibliographystyle{acm}
\bibliography{collection}}
\begin{appendix}
\end{appendix}
\listoftodos
% \begin{appendix}
% \end{appendix}
\end{document}
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment