Commit 7ee3cf60 authored by Benoit Viguier's avatar Benoit Viguier
Browse files

Fixes in paper + Makefile, thanks to Thom

parent 7dece01e
DIST=coq-verif-tweetnacl DIST=coq-verif-tweetnacl
NO_COLOR="\033[0m"
RED = "\033[38;5;009m"
GREEN = "\033[38;5;010m"
YELLOW = "\033[38;5;011m"
ORANGE = "\033[38;5;214m"
LIGHTPURPLE = "\033[38;5;177m"
PURPLE = "\033[38;5;135m"
CYAN = "\033[38;5;014m"
LIGHTGRAY = "\033[38;5;252m"
DARKGRAY = "\033[38;5;242m"
BRIGHTRED = "\033[91m"
BOLD = "\033[1m"
all: coq-tweetnacl-spec coq-tweetnacl-vst # NO_COLOR="\033[0m"
# RED = "\033[38;5;009m"
# GREEN = "\033[38;5;010m"
readme: # YELLOW = "\033[38;5;011m"
less README.md # ORANGE = "\033[38;5;214m"
# LIGHTPURPLE = "\033[38;5;177m"
# PURPLE = "\033[38;5;135m"
# DEFINE GENERIC ROUTINES (hidden via . prefix) # CYAN = "\033[38;5;014m"
.configure1 .configure2: # LIGHTGRAY = "\033[38;5;252m"
cd $P && $(SHELL) configure.sh # DARKGRAY = "\033[38;5;242m"
# BRIGHTRED = "\033[91m"
.building1: .configure1 # BOLD = "\033[1m"
.building2: .configure2 #
.building1 .building2: # all: coq-tweetnacl-spec coq-tweetnacl-vst
cd $P && $(MAKE) -j all
cd $P && $(MAKE) install include coq.mk
.dusting1: .configure1
.dusting2: .configure2
.dusting1 .dusting2:
cd $P && $(MAKE) clean
cd $P && rm _CoqProject
cd $P && rm Makefile
cd $P && rm Makefile.conf
# DEFINE REAL TARGETS
coq-tweetnacl-spec: P=proofs/spec
coq-tweetnacl-spec: .building1
clean-spec: P=proofs/spec
clean-spec: .dusting1
coq-tweetnacl-vst: P=proofs/vst
coq-tweetnacl-vst: coq-tweetnacl-spec .building2
clean-vst: P=proofs/vst
clean-vst: .dusting2
.PHONY: clean .PHONY: clean
clean: clean-spec clean-vst clean-dist clean: clean-spec clean-vst clean-dist
...@@ -56,7 +23,7 @@ clean: clean-spec clean-vst clean-dist ...@@ -56,7 +23,7 @@ clean: clean-spec clean-vst clean-dist
# build paper # build paper
.PHONY: paper .PHONY: paper
paper: paper:
cd paper && $(MAKE) @cd paper && $(MAKE)
clean-paper: clean-paper:
cd paper && $(MAKE) clean cd paper && $(MAKE) clean
...@@ -71,7 +38,7 @@ $(DIST)/specs_map.pdf: ...@@ -71,7 +38,7 @@ $(DIST)/specs_map.pdf:
cd paper && $(MAKE) specs_map.pdf cd paper && $(MAKE) specs_map.pdf
mv specs_map.pdf $(DIST)/specs_map.pdf mv specs_map.pdf $(DIST)/specs_map.pdf
dist: $(DIST) $(DIST)/specs_map.pdf dist: clean-dist $(DIST) $(DIST)/specs_map.pdf
@echo $(BOLD)$(YELLOW)"Preparing $(DIST)"$(NO_COLOR)$(DARKGRAY) @echo $(BOLD)$(YELLOW)"Preparing $(DIST)"$(NO_COLOR)$(DARKGRAY)
cp -r proofs $(DIST) cp -r proofs $(DIST)
mkdir $(DIST)/packages mkdir $(DIST)/packages
...@@ -82,7 +49,7 @@ dist: $(DIST) $(DIST)/specs_map.pdf ...@@ -82,7 +49,7 @@ dist: $(DIST) $(DIST)/specs_map.pdf
cp repo $(DIST)/ cp repo $(DIST)/
cp version $(DIST)/ cp version $(DIST)/
cp README.md $(DIST)/ cp README.md $(DIST)/
cp Makefile $(DIST)/ cp coq.mk $(DIST)/Makefile
cp opam $(DIST)/ cp opam $(DIST)/
@echo $(BOLD)$(LIGHTPURPLE)"Building $(DIST).tar.gz"$(NO_COLOR)$(DARKGRAY) @echo $(BOLD)$(LIGHTPURPLE)"Building $(DIST).tar.gz"$(NO_COLOR)$(DARKGRAY)
tar -czvf $(DIST).tar.gz $(DIST) tar -czvf $(DIST).tar.gz $(DIST)
...@@ -90,6 +57,6 @@ dist: $(DIST) $(DIST)/specs_map.pdf ...@@ -90,6 +57,6 @@ dist: $(DIST) $(DIST)/specs_map.pdf
clean-dist: clean-dist:
@echo $(BOLD)$(YELLOW)"removing $(DIST)"$(NO_COLOR)$(DARKGRAY) @echo $(BOLD)$(YELLOW)"removing $(DIST)"$(NO_COLOR)$(DARKGRAY)
rm -r $(DIST) -rm -r $(DIST)
rm $(DIST).tar.gz -rm $(DIST).tar.gz
@echo $(BOLD)$(GREEN)"Done."$(NO_COLOR) @echo $(BOLD)$(GREEN)"Done."$(NO_COLOR)
NO_COLOR="\033[0m"
RED = "\033[38;5;009m"
GREEN = "\033[38;5;010m"
YELLOW = "\033[38;5;011m"
ORANGE = "\033[38;5;214m"
LIGHTPURPLE = "\033[38;5;177m"
PURPLE = "\033[38;5;135m"
CYAN = "\033[38;5;014m"
LIGHTGRAY = "\033[38;5;252m"
DARKGRAY = "\033[38;5;242m"
BRIGHTRED = "\033[91m"
BOLD = "\033[1m"
all: deps coq-tweetnacl-spec coq-tweetnacl-vst
deps:
@command -v opam >/dev/null 2>&1 || { \
echo >&2 $(RED)"Error: opam is not installed.\n"$(NO_COLOR); \
echo $(YELLOW)"Please do 'make readme' \n"$(NO_COLOR); exit 1; }
readme:
less README.md
# DEFINE GENERIC ROUTINES (hidden via . prefix)
.configure1 .configure2:
@echo $(BOLD)$(ORANGE)"Configuring $P"$(NO_COLOR)$(DARKGRAY)
cd $P && $(SHELL) configure.sh
.building1: .configure1
.building2: .configure2 .building1
.building1 .building2:
@echo $(BOLD)$(YELLOW)"Building $P"$(NO_COLOR)$(DARKGRAY)
cd $P && $(MAKE) all
@echo $(BOLD)$(LIGHTPURPLE)"Installing $P"$(NO_COLOR)$(DARKGRAY)
cd $P && $(MAKE) install
@echo $(BOLD)$(GREEN)"Done."$(NO_COLOR)
.dusting1: .configure1
.dusting2: .configure2
.dusting1 .dusting2:
@echo $(BOLD)$(YELLOW)"Cleaning $P"$(NO_COLOR)$(DARKGRAY)
cd $P && $(MAKE) clean
cd $P && rm _CoqProject
cd $P && rm Makefile
cd $P && rm Makefile.conf
# DEFINE REAL TARGETS
coq-tweetnacl-spec: P=proofs/spec
coq-tweetnacl-spec: .building1
clean-spec: P=proofs/spec
clean-spec: .dusting1
coq-tweetnacl-vst: P=proofs/vst
coq-tweetnacl-vst: coq-tweetnacl-spec .building2
clean-vst: P=proofs/vst
clean-vst: .dusting2
.PHONY: clean
clean: clean-spec clean-vst
...@@ -42,7 +42,7 @@ In order to efficiently compute the scalar multiplication we use an algorithm ...@@ -42,7 +42,7 @@ In order to efficiently compute the scalar multiplication we use an algorithm
similar to square-and-multiply: the Montgomery ladder where the basic operations similar to square-and-multiply: the Montgomery ladder where the basic operations
are differential addition and doubling~\cite{MontgomerySpeeding}. are differential addition and doubling~\cite{MontgomerySpeeding}.
We consider \xcoord-only operations. Throughout the computation, We consider \xcoord-only operations. Throughout the computation,
these $x$-coordinates are kept in projective representation these $x$-coordinates are kept in projective representation
$(X : Z)$, with $x = X/Z$; the point at infinity is represented as $(1:0)$. $(X : Z)$, with $x = X/Z$; the point at infinity is represented as $(1:0)$.
See \sref{subsec:ECC-projective} for more details. See \sref{subsec:ECC-projective} for more details.
...@@ -87,15 +87,15 @@ computing a \xcoord-only scalar multiplication (see \aref{alg:montgomery-ladder} ...@@ -87,15 +87,15 @@ computing a \xcoord-only scalar multiplication (see \aref{alg:montgomery-ladder}
From now on let $\F{p}$ be the field with $p=2^{255}-19$ elements. From now on let $\F{p}$ be the field with $p=2^{255}-19$ elements.
We consider the elliptic curve $E$ over $\F{p}$ defined by the We consider the elliptic curve $E$ over $\F{p}$ defined by the
equation $y^2 = x^3 + 486662 x^2 + x$. equation $y^2 = x^3 + 486662 x^2 + x$.
For every $x \in \F{p}$ there exist a point $P$ in $E(\F{p^2})$ For every $x \in \F{p}$ there exist a point $P$ in $E(\F{p^2})$
such that $x$ is the \xcoord of $P$. such that $x$ is the \xcoord of $P$.
The core of the X25519 key-exchange protocol is a scalar-multiplication The core of the X25519 key-exchange protocol is a scalar-multiplication
function, which we will also refer to as X25519. function, which we will also refer to as X25519.
This function receives as input two arrays of $32$ bytes each. This function receives as input two arrays of $32$ bytes each.
One of them is interpreted as the little-endian encoding of a One of them is interpreted as the little-endian encoding of a
non-negative integer $n$ (see \ref{subsec:integer-bytes}). non-negative integer $n$ (see \ref{subsec:integer-bytes}).
The other is interpreted as the little-endian encoding of The other is interpreted as the little-endian encoding of
the \xcoord $x_P \in \F{p}$ of a point in $E(\F{p^2})$, the \xcoord $x_P \in \F{p}$ of a point in $E(\F{p^2})$,
using the standard mapping of integers modulo $p$ to elements in $\F{p}$. using the standard mapping of integers modulo $p$ to elements in $\F{p}$.
...@@ -110,7 +110,7 @@ RFC~7748~\cite{rfc7748} standardized the X25519 Diffie–Hellman key-exchange al ...@@ -110,7 +110,7 @@ RFC~7748~\cite{rfc7748} standardized the X25519 Diffie–Hellman key-exchange al
Given the base point $B$ where $X_B=9$, each party generate a secret random number Given the base point $B$ where $X_B=9$, each party generate a secret random number
$s_a$ (respectively $s_b$), and computes $X_{P_a}$ (respectively $X_{P_b}$), the $s_a$ (respectively $s_b$), and computes $X_{P_a}$ (respectively $X_{P_b}$), the
\xcoord of $P_A = s_a \cdot B$ (respectively $P_B = s_b \cdot B$). \xcoord of $P_A = s_a \cdot B$ (respectively $P_B = s_b \cdot B$).
The parties exchange $X_{P_a}$ and $X_{P_b}$ and compute their shared secret with The parties exchange $X_{P_a}$ and $X_{P_b}$ and compute their shared secret with
X25519 on $s_a$ and $X_{P_b}$ (respectively $s_b$ and $X_{P_a}$). X25519 on $s_a$ and $X_{P_b}$ (respectively $s_b$ and $X_{P_a}$).
\subsection{TweetNaCl specifics} \subsection{TweetNaCl specifics}
...@@ -212,9 +212,9 @@ sv car25519(gf o) ...@@ -212,9 +212,9 @@ sv car25519(gf o)
In order to simplify the verification of this function, In order to simplify the verification of this function,
we treat the last iteration of the loop $i = 15$ as a separate step. we treat the last iteration of the loop $i = 15$ as a separate step.
Inverses in $\Zfield$ are computed with \TNaCle{inv25519}. Inverses in $\Ffield$ are computed with \TNaCle{inv25519}.
This function uses exponentiation by $2^{255}-21$, This function uses exponentiation by $2^{255}-21$,
computed with the square-and-multiply algorithm. computed with the square-and-multiply algorithm.
Fermat's little theorem gives the correctness. Fermat's little theorem gives the correctness.
Notice that in this case the inverse of $0$ is defined as $0$. Notice that in this case the inverse of $0$ is defined as $0$.
\begin{lstlisting}[language=Ctweetnacl] \begin{lstlisting}[language=Ctweetnacl]
...@@ -283,7 +283,7 @@ to a \emph{unique} representation, i.e., also fully reduce modulo ...@@ -283,7 +283,7 @@ to a \emph{unique} representation, i.e., also fully reduce modulo
$p$ and remove the redundancy of the radix-$2^{16}$ representation. $p$ and remove the redundancy of the radix-$2^{16}$ representation.
\subheading{The Montgomery ladder.} \subheading{The Montgomery ladder.}
With these low-level arithmetic and helper functions defined, With these low-level arithmetic and helper functions defined,
we can now turn our attention to the core of the X25519 computation: we can now turn our attention to the core of the X25519 computation:
the \TNaCle{crypto_scalarmult} API function of TweetNaCl, the \TNaCle{crypto_scalarmult} API function of TweetNaCl,
which is implemented through the Montgomery ladder. which is implemented through the Montgomery ladder.
......
...@@ -83,7 +83,7 @@ The definitions of the encoding and decoding functions are detailed in ...@@ -83,7 +83,7 @@ The definitions of the encoding and decoding functions are detailed in
RFC~7748 states that \emph{``All calculations are performed in GF(p), i.e., they are performed modulo p.''} RFC~7748 states that \emph{``All calculations are performed in GF(p), i.e., they are performed modulo p.''}
Operations used in the Montgomery ladder of \coqe{RFC} are performed on Operations used in the Montgomery ladder of \coqe{RFC} are performed on
integers (See Appendix~\ref{subsubsec:RFC-Coq}). integers (See Appendix~\ref{subsubsec:RFC-Coq}).
The reduction modulo $\p$ is deferred to the very end as part of the \coqe{ZPack25519} operation. The reduction modulo $\p$ is deferred to the very end as part of the \coqe{ZPack25519} operation.
%We use this notation to emphasis its difference with $\Ffield$ where the %We use this notation to emphasis its difference with $\Ffield$ where the
%modulo by $\p$ is applied in each operations. %modulo by $\p$ is applied in each operations.
...@@ -123,7 +123,7 @@ We later prove our ladder correct in that respect (\sref{sec:maths}). ...@@ -123,7 +123,7 @@ We later prove our ladder correct in that respect (\sref{sec:maths}).
\subsection{Integers and Bytes} \subsection{Integers and bytes}
\label{subsec:integer-bytes} \label{subsec:integer-bytes}
\emph{``To implement the X25519(k, u) [...] functions (where k is \emph{``To implement the X25519(k, u) [...] functions (where k is
...@@ -132,18 +132,15 @@ perform the following procedure, which is taken from [curve25519] and ...@@ -132,18 +132,15 @@ perform the following procedure, which is taken from [curve25519] and
based on formulas from [montgomery]. All calculations are performed based on formulas from [montgomery]. All calculations are performed
in GF(p), i.e., they are performed modulo p.''}~\cite{rfc7748} in GF(p), i.e., they are performed modulo p.''}~\cite{rfc7748}
In TweetNaCl, as described in \sref{subsec:Number-TweetNaCl}, In TweetNaCl, as described in \sref{subsec:Number-TweetNaCl},
elements of $\F{p}$ are represented as big integers using radix $2^{16}$. elements of $\F{p}$ are represented as big integers using radix $2^{16}$.
We use a direct mapping to represent such an array of limbs We use a direct mapping to represent such an array of limbs
as a list of integers in Coq. as a list of integers in Coq.
We define the little-endian projection to integers as follows. We define the little-endian projection to integers as follows.
\begin{dfn} \begin{dfn}
Let \Coqe{ZofList} : $\Z \rightarrow \texttt{list}~\Z \rightarrow \Z$, Let \Coqe{ZofList} : $\Z \rightarrow \texttt{list}~\Z \rightarrow \Z$,
a parameterized map by $n$ between a list $l$ and its little endian representation a function given $n$ and a list $l$ returns its little endian decoding with radix $2^n$.
with a radix $2^n$.
%XXX-Peter: The sentence before is not clear to me. What exactly is mapped where?
%and what is the "little endian representation with a radix $2^n$ of a list"?
\end{dfn} \end{dfn}
We define it in Coq as: We define it in Coq as:
\begin{lstlisting}[language=Coq] \begin{lstlisting}[language=Coq]
...@@ -159,9 +156,9 @@ base to verify operations over lists in TweetNaCl (See~\ref{subsec:num-repr-rfc} ...@@ -159,9 +156,9 @@ base to verify operations over lists in TweetNaCl (See~\ref{subsec:num-repr-rfc}
The encoding from integers to bytes is defined in a similar way: The encoding from integers to bytes is defined in a similar way:
\begin{dfn} \begin{dfn}
Let \Coqe{ListofZ32} : $\Z \rightarrow \Z \rightarrow \texttt{list}~\Z$, given Let \Coqe{ListofZ32} : $\Z \rightarrow \Z \rightarrow \texttt{list}~\Z$, given
$n$ and $a$ returns $a$'s little-endian representation $n$ and $a$ returns $a$'s little-endian encoding as a list with radix $2^n$.
as a list with radix $2^n$. %XXX-Peter: Again I'm confused... why are there two \rightarrows?
%XXX-Peter: Again I'm confused... why are there two \rightarrows? %XXX-Benoit it is the functional view of arguments and partial functions. It is called Currying.
\end{dfn} \end{dfn}
We define it in Coq as: We define it in Coq as:
\begin{lstlisting}[language=Coq] \begin{lstlisting}[language=Coq]
......
...@@ -24,91 +24,12 @@ Theorem body_crypto_scalarmult: ...@@ -24,91 +24,12 @@ Theorem body_crypto_scalarmult:
crypto_scalarmult_spec. crypto_scalarmult_spec.
\end{lstlisting} \end{lstlisting}
We first describe the global structure of our proof (\ref{subsec:proof-structure}). % We first describe the global structure of our proof (\ref{subsec:proof-structure}).
Using our formalization of RFC~7748 (\sref{sec:Coq-RFC}) we specify the Hoare Using our formalization of RFC~7748 (\sref{sec:Coq-RFC}) we specify the Hoare
triple before proving its correctness with VST (\ref{subsec:with-VST}). triple before proving its correctness with VST (\ref{subsec:with-VST}).
We provide an example of equivalence of operations over different number We provide an example of equivalence of operations over different number
representations (\ref{subsec:num-repr-rfc}). Then, we describe efficient techniques representations (\ref{subsec:num-repr-rfc}). Then, we describe efficient techniques
used to in some of our more complex proofs (\ref{subsec:inversions-reflections}). used in some of our more complex proofs (\ref{subsec:inversions-reflections}).
%XXX-Peter: "used to" what? Incomplete sentence
%XXX-Peter: Does this subsection really belong here? My understanding is that it describes
%the full picture (Sections 4 and 5) and not just what is happening in this section.
\subsection{Structure of our proof}
\label{subsec:proof-structure}
% XXX-Peter: This whole paragraph can go away; we already said this before.
In order to prove the correctness of X25519 in TweetNaCl code \TNaCle{crypto_scalarmult},
we use VST to prove that the code matches our functional Coq specification of \Coqe{RFC}.
Then, we prove that our specification of the scalar multiplication matches the mathematical definition
of elliptic curves and Theorem 2.1 by Bernstein~\cite{Ber06} (\sref{sec:maths}).
Verifying \TNaCle{crypto_scalarmult} also implies verifying all the functions
subsequently called: \TNaCle{unpack25519}; \TNaCle{A}; \TNaCle{Z}; \TNaCle{M};
\TNaCle{S}; \TNaCle{car25519}; \TNaCle{inv25519}; \TNaCle{set25519}; \TNaCle{sel25519};
\TNaCle{pack25519}.
We prove that the implementation of X25519 is \textbf{sound}, \ie:
\begin{itemize}
\item absence of access out-of-bounds of arrays (memory safety).
\item absence of overflows/underflow in the arithmetic.
\end{itemize}
We also prove that TweetNaCl's code is \textbf{correct}:
\begin{itemize}
\item X25519 is correctly implemented (we get what we expect) .
\item Operations on \TNaCle{gf} (\TNaCle{A}, \TNaCle{Z}, \TNaCle{M}, \TNaCle{S})
are equivalent to operations ($+,-,\times,x^2$) in $\Zfield$.
\item The Montgomery ladder computes the multiple of a point.
%XXX-Peter: We don't prove this last statement in this section
\end{itemize}
In order to prove the soundness and correctness of \TNaCle{crypto_scalarmult},
we reuse the generic Montgomery ladder defined in \sref{sec:Coq-RFC}.
We define a high-level specification by instantiating the ladder with a generic
field $\K$, this allows us to prove the correctness of the ladder with respect
to the theory of elliptic curves.
This high-level specification does not rely on the parameters of Curve25519.
We later specialize $\K$ with $\Ffield$, and the parameters of Curve25519 ($a = 486662, b = 1$),
to derive the correctness of \coqe{RFC} (\sref{sec:maths}).
%XXX-Peter: not in this section, correct?
We define a mid-level specification by instantiating the ladder over $\Zfield$.
Additionally we also provide a low-level specification close to the \texttt{C} code
(over lists of $\Z$). We show this specification to be equivalent to the
\emph{semantic version} of C (Clight) using the VST.
This low level specification gives us the soundness assurance.
RFC~7748's X25519 formalization (\sref{sec:Coq-RFC}) takes as input list of $\Z$.
However the inner Montgomery ladder operates on $\Zfield$. We show its equivalence
with our mid-level and low-level specifications.
By showing that operations over instances ($\K = \Ffield$, $\Zfield$, list of $\Z$) are
equivalent, we bridge the gap between the different level of specification
with Curve25519 parameters.
As such, we prove all specifications to equivalent (\fref{tikz:ProofStructure}).
This guarantees us the correctness of the implementation.
\begin{figure}[h]
\centering
\include{tikz/specifications}
\caption{Structural construction of the proof}
\label{tikz:ProofStructure}
\end{figure}
% The location of the definitions are listed in Appendix~\ref{appendix:proof-files}.
\subsection{Applying the Verifiable Software Toolchain} \subsection{Applying the Verifiable Software Toolchain}
...@@ -202,18 +123,6 @@ their respective bounds: arrays of 32 bytes. ...@@ -202,18 +123,6 @@ their respective bounds: arrays of 32 bytes.
The correctness of this specification is formally proven in Coq with The correctness of this specification is formally proven in Coq with
\coqe{Theorem body_crypto_scalarmult}. \coqe{Theorem body_crypto_scalarmult}.
% \begin{theorem}
% \label{thm:crypto-vst}
% \TNaCle{crypto_scalarmult} in TweetNaCl has the same behavior as \coqe{RFC} in Coq.
% \end{theorem}
% % this does not exists anymore
% The location of the proof of this Hoare triple can be found in Appendix~\ref{appendix:proof-files}.
% We now bring the attention of the reader to details of verifications using the VST.
%% BLABLA about VST. Does not belong here. %% BLABLA about VST. Does not belong here.
% The Verifiable Software Toolchain uses a strongest postcondition strategy. % The Verifiable Software Toolchain uses a strongest postcondition strategy.
...@@ -233,7 +142,8 @@ The correctness of this specification is formally proven in Coq with ...@@ -233,7 +142,8 @@ The correctness of this specification is formally proven in Coq with
\subheading{Memory aliasing.} \subheading{Memory aliasing.}
In the VST, a simple specification of \texttt{M(o,a,b)} will assume that the pointer arguments In the VST, a simple specification of \texttt{M(o,a,b)} will assume that the pointer arguments
point to non-overlapping space in memory. % XXX-Peter: "memory share" is unclear; please fix in the next sentence. point to non-overlapping space in memory, also named memory share.
% XXX-Peter: "memory share" is unclear; please fix in the next sentence.
When called with three memory shares (\texttt{o, a, b}), When called with three memory shares (\texttt{o, a, b}),
the three of them will be consumed. However assuming this naive specification the three of them will be consumed. However assuming this naive specification
when \texttt{M(o,a,a)} is called (squaring), the first two memory shares (\texttt{o, a}) when \texttt{M(o,a,a)} is called (squaring), the first two memory shares (\texttt{o, a})
...@@ -262,6 +172,10 @@ This solution does not cover all cases (e.g. all arguments are aliased) but it ...@@ -262,6 +172,10 @@ This solution does not cover all cases (e.g. all arguments are aliased) but it
is enough for our needs. is enough for our needs.
%XXX-Peter: shouldn't verifying fixed-length for loops be rather standard? %XXX-Peter: shouldn't verifying fixed-length for loops be rather standard?
%XXX Benoit: it is simple if the argument is increasing or if the "recursive call"
% is made before the computations.
% This is not the case here: you compute idx 255 before 254...
% Can we shorten the next paragraph? % Can we shorten the next paragraph?
\subheading{Verifying \texttt{for} loops.} \subheading{Verifying \texttt{for} loops.}
Final states of \texttt{for} loops are usually computed by simple recursive functions. Final states of \texttt{for} loops are usually computed by simple recursive functions.
...@@ -283,8 +197,6 @@ iteratively applies $g$ with decreasing index: ...@@ -283,8 +197,6 @@ iteratively applies $g$ with decreasing index:
Then we have : Then we have :
\begin{align*} \begin{align*}
f(4,s) &= g(0,g(1,g(2,g(3,s)))) f(4,s) &= g(0,g(1,g(2,g(3,s))))
% \\
% f(3,s) &= g(0,g(1,g(2,s)))
\end{align*} \end{align*}
To prove the correctness of $f(4,s)$, we need to prove that intermediate steps To prove the correctness of $f(4,s)$, we need to prove that intermediate steps
$g(3,s)$; $g(2,g(3,s))$; $g(1,g(2,g(3,s)))$; $g(0,g(1,g(2,g(3,s))))$ are correct. $g(3,s)$; $g(2,g(3,s))$; $g(1,g(2,g(3,s)))$; $g(0,g(1,g(2,g(3,s))))$ are correct.
...@@ -304,7 +216,7 @@ in C provide the same computations as in \coqe{RFC}. ...@@ -304,7 +216,7 @@ in C provide the same computations as in \coqe{RFC}.
\subsection{Number Representation and C Implementation} \subsection{Number representation and C implementation}
\label{subsec:num-repr-rfc} \label{subsec:num-repr-rfc}
As described in \sref{subsec:Number-TweetNaCl}, numbers in \TNaCle{gf} are represented As described in \sref{subsec:Number-TweetNaCl}, numbers in \TNaCle{gf} are represented
...@@ -364,7 +276,7 @@ Lemma M_bound_Zlength : ...@@ -364,7 +276,7 @@ Lemma M_bound_Zlength :
\subsection{Inversions, Reflections and Packing} \subsection{Inversions, reflections and packing}
\label{subsec:inversions-reflections} \label{subsec:inversions-reflections}
We now turn our attention to the multiplicative inverse in $\Zfield$ and techniques We now turn our attention to the multiplicative inverse in $\Zfield$ and techniques
...@@ -461,7 +373,7 @@ apply the unrolling and exponentiation formulas 255 times. This could be automat ...@@ -461,7 +373,7 @@ apply the unrolling and exponentiation formulas 255 times. This could be automat
in Coq with tacticals such as \Coqe{repeat}, but it generates a proof object which in Coq with tacticals such as \Coqe{repeat}, but it generates a proof object which
will take a long time to verify. will take a long time to verify.
\subheading{Reflections.} \subheading{Reflections.}
In order to speed up the verification we use a In order to speed up the verification we use a
technique called ``Reflection''. It provides us with flexibility, \eg we don't technique called ``Reflection''. It provides us with flexibility, \eg we don't
need to know the number of times nor the order in which the lemmas needs to be need to know the number of times nor the order in which the lemmas needs to be
...@@ -482,11 +394,10 @@ With this technique we prove the functional correctness of the inversion over \Z ...@@ -482,11 +394,10 @@ With this technique we prove the functional correctness of the inversion over \Z
\end{lemma} \end{lemma}
This statement is formalized as This statement is formalized as
\begin{lstlisting}[language=Coq] \begin{lstlisting}[language=Coq]
Corollary Inv25519_Zpow_GF : Corollary Inv25519_Zpow_GF : forall (g:list Z),
forall (g:list Z),
length g = 16 -> length g = 16 ->
Z16.lst (Inv25519 g) :GF = Z16.lst (Inv25519 g) :GF =
(pow (Z16.lst g) (2^255-21)) :GF. (pow (Z16.lst g) (2^255-21)) :GF.
\end{lstlisting} \end{lstlisting}
This reflection technique is also used where proofs requires some computing This reflection technique is also used where proofs requires some computing
...@@ -513,10 +424,9 @@ for(i=1;i<15;i++) { ...@@ -513,10 +424,9 @@ for(i=1;i<15;i++) {
\end{lstlisting} \end{lstlisting}
This loop separation allows simpler proofs. The first loop is seen as the This loop separation allows simpler proofs. The first loop is seen as the
subtraction of a number in \Zfield. We then prove that with the iteration of the subtraction of \p. The resulting number represented in $\Zfield$ is invariant with
second loop, the number represented in $\Zfield$ stays the same. This leads to the iteration of the second loop. This result in the proof that \TNaCle{pack25519}
the proof that \TNaCle{pack25519} is effectively reducing modulo $\p$ and reduces modulo $\p$ and returns a number in base $2^8$.
returning a number in base $2^8$.
\begin{lstlisting}[language=Coq] \begin{lstlisting}[language=Coq]
Lemma Pack25519_mod_25519 : Lemma Pack25519_mod_25519 :
forall (l:list Z), forall (l:list Z),
...@@ -532,7 +442,7 @@ we defined a Coq definition \coqe{Crypto_Scalarmult} mimicking the exact behavio ...@@ -532,7 +442,7 @@ we defined a Coq definition \coqe{Crypto_Scalarmult} mimicking the exact behavio
By proving that each functions \coqe{Low.M}; \coqe{Low.A}; \coqe{Low.Sq}; \coqe{Low.Zub}; By proving that each functions \coqe{Low.M}; \coqe{Low.A}; \coqe{Low.Sq}; \coqe{Low.Zub};
\coqe{Unpack25519}; \coqe{clamp}; \coqe{Pack25519}; \coqe{Inv25519}; \coqe{car25519} are behaving over \coqe{list Z} \coqe{Unpack25519}; \coqe{clamp}; \coqe{Pack25519}; \coqe{Inv25519}; \coqe{car25519} are behaving over \coqe{list Z}
as their equivalent over \coqe{Z} in \coqe{:GF} (in \Zfield), we prove that given the same inputs \coqe{Crypto_Scalarmult} applies the same computation as \coqe{RFC}. as their equivalent over \coqe{Z} with \coqe{:GF} (in \Zfield), we prove that given the same inputs \coqe{Crypto_Scalarmult} applies the same computation as \coqe{RFC}.
% This is formalized as follows in Coq: % This is formalized as follows in Coq:
\begin{lstlisting}[language=Coq] \begin{lstlisting}[language=Coq]
Lemma Crypto_Scalarmult_RFC_eq : Lemma Crypto_Scalarmult_RFC_eq :
......
...@@ -28,7 +28,7 @@ We extend it to support Montgomery curves (\ref{subsec:ECC-Montgomery}) ...@@ -28,7 +28,7 @@ We extend it to support Montgomery curves (\ref{subsec:ECC-Montgomery})
with homogeneous coordinates (\ref{subsec:ECC-projective}) and prove the with homogeneous coordinates (\ref{subsec:ECC-projective}) and prove the
correctness of the ladder (\ref{subsec:ECC-ladder}). correctness of the ladder (\ref{subsec:ECC-ladder}).
\subsection{Formalization of Elliptic Curves} \subsection{Formalization of elliptic Curves}
\label{subsec:ECC} \label{subsec:ECC}
We consider elliptic curves over a field $\K$. We assume that the We consider elliptic curves over a field $\K$. We assume that the
...@@ -44,7 +44,7 @@ solutions $(x,y)$ of $E$ augmented by a distinguished point $\Oinf$ (called poin ...@@ -44,7 +44,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\}$$ $$E(\K) = \{(x,y) \in \K \times \K | E(x,y)\} \cup \{\Oinf\}$$
\end{dfn} \end{dfn}
\subsubsection{Weierstra{\ss} Curves} \subsubsection{Weierstra{\ss} curves}
\label{subsec:ECC-Weierstrass} \label{subsec:ECC-Weierstrass}
This equation $E(x,y)$ can be reduced into its short Weierstra{\ss} form. This equation $E(x,y)$ can be reduced into its short Weierstra{\ss} form.
...@@ -106,7 +106,7 @@ Definition addec (p1 p2 : ec) : ec := ...@@ -106,7 +106,7 @@ Definition addec (p1 p2 : ec) : ec :=
EC p1 p2 (addO p1 p2)