\section{Conclusion}
\label{sec:Conclusion}

Any formal system relies on a trusted base. In this section we describe our
chain of trust.

\subheading{Trusted Code Base of the proof.}
Our proof relies on a trusted base, i.e. a foundation of definitions that must be
correct. One should not be able to prove a false statement in that system, \eg by
proving an inconsistency.

In our case we rely on:
\begin{itemize}
  \item \textbf{Calculus of Inductive Constructions}. The intuitionistic logic
  used by Coq must be consistent in order to trust the proofs. As an axiom,
  we assume that the functional extensionality is also consistent with that logic.
  $$\forall x, f(x) = g(x) \implies f = g$$
\begin{lstlisting}[language=Coq,belowskip=-0.25 \baselineskip]
Lemma f_ext: forall (A B:Type),
  forall (f g: A -> B),
  (forall x, f(x) = g(x)) -> f = g.
\end{lstlisting}

  \item \textbf{Verifiable Software Toolchain}. This framework developed at
  Princeton allows a user to prove that a Clight code matches pure Coq
  specification.

  \item \textbf{CompCert}. When compiling with CompCert we only need to trust
  CompCert's {assembly} semantics, as the compilation chain has been formally proven correct.
  However, when compiling with other C compilers like Clang or GCC, we need to
  trust that the CompCert's Clight semantics matches the C17 standard.

  \item \textbf{\texttt{clightgen}}. The tool making the translation from {C} to
  {Clight}, the first step of the CompCert compilation.
  VST does not support the direct verification of \texttt{o[i] = a[i] + b[i]}.
  This needs to be rewritten into:
  \begin{lstlisting}[language=Ctweetnacl,stepnumber=0,belowskip=-0.5 \baselineskip]
aux1 = a[i]; aux2 = b[i];
o[i] = aux1 + aux2;
\end{lstlisting}
  The \texttt{-normalize} flag is taking care of this
  rewriting and factors out assignments from inside subexpressions.
  % The trust of the proof relies on a correct translation from the
  % initial version of \emph{TweetNaCl} to \emph{TweetNaClVerifiableC}.
  % The changes required for C code to make it verifiable are now minimal.

  \item Finally, we must trust the \textbf{Coq kernel} and its
  associated libraries; the \textbf{Ocaml compiler} on which we compiled Coq;
  the \textbf{Ocaml Runtime} and the \textbf{CPU}. Those are common to all proofs
  done with this architecture \cite{2015-Appel,coq-faq}.
\end{itemize}

\subheading{Corrections in TweetNaCl.}
As a result of this verification, we removed superfluous code.
Indeed indexes 17 to 79 of the \TNaCle{i64 x[80]} intermediate variable of
\TNaCle{crypto_scalarmult} were adding unnecessary complexity to the code,
we removed them.

Peter Wu and Jason A. Donenfeld brought to our attention that the original
\TNaCle{car25519} function carried a risk of undefined behavior if \texttt{c}
is a negative number.
\begin{lstlisting}[language=Ctweetnacl,stepnumber=0]
c=o[i]>>16;
o[i]-=c<<16; // c < 0 = UB !
\end{lstlisting}
We replaced this statement with a logical \texttt{and}, proved correctness,
and thus solved this problem.
\begin{lstlisting}[language=Ctweetnacl,stepnumber=0]
o[i]&=0xffff;
\end{lstlisting}

Aside from this modifications, all subsequent alterations to the TweetNaCl code%
---such as the type change of loop indexes (\TNaCle{int} instead of \TNaCle{i64})---%
were required for VST to step through the code properly. We believe that those
adjustments do not impact the trust of our proof.

We contacted the authors of TweetNaCl and expect that the changes described
above will soon be integrated in a new version of the library.


% Do we want to say that ?

% \subheading{Verification Effort.}
% In addition to the time required to get familiar with
% research software, we faced a few bugs which we reported
% to the developers of VST to get them fixed.
% It is very hard to work with a tool without being involved
% in the development loop. Additionally newer versions often
% broke some of our proofs and it was often needed to adapt
% to the changes.
% As a result we do not believe the metric person-month to be
% a good representation of the verification effort.

\subheading{Lessons learned.}
\todo{Write something about VST etc.}

\subheading{Extending our work.}
The high-level definition (\sref{sec:maths}) can easily be ported to any
other Montgomery curves and with it the proof of the ladder's correctness
assuming the same formulas are used.
In addition to the curve equation, the field \F{p} would need to be redefined
as $p=2^{255}-19$ is hard-coded in order to speed up some proofs.

With respect to the C code verification (\sref{sec:C-Coq}), the extension of
the verification effort to Ed25519 would make directly use of the low-level
arithmetic. The ladder steps formula being different this would require a high
level verification similar to \tref{thm:montgomery-ladder-correct}.

The verification of \eg X448~\cite{cryptoeprint:2015:625,rfc7748} in C would
require the adaptation of most of the low-level arithmetic (mainly the
multiplication, carry propagation and reduction).
Once the correctness and bounds of the basic operations are established,
reproving the full ladder would make use of our generic definition.

\subheading{A complete proof.}
We provide a mechanized formal proof of the correctness of the X25519
implementation in TweetNaCl from C up the mathematical definitions with a single tool.
We first formalized X25519 from RFC~7748~\cite{rfc7748} in Coq.
We then proved that TweetNaCl's implementation of X25519 matches our formalization.
In a second step we extended the Coq library for elliptic curves \cite{BartziaS14}
by Bartzia and Strub to support Montgomery curves.
Using this extension we proved that the X25519 from the RFC matches the
mathematical definitions as given in~\cite[Sec.~2]{Ber06}.
Therefore in addition to proving the mathematical correctness of TweetNaCl,
we also increases the trust of other works such as
\cite{zinzindohoue2017hacl,Erbsen2016SystematicSO} which rely on RFC~7748.