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
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
readme:
less README.md
# DEFINE GENERIC ROUTINES (hidden via . prefix)
.configure1 .configure2:
cd $P && $(SHELL) configure.sh
.building1: .configure1
.building2: .configure2
.building1 .building2:
cd $P && $(MAKE) -j all
cd $P && $(MAKE) install
.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
# 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
include coq.mk
.PHONY: clean
clean: clean-spec clean-vst clean-dist
......@@ -56,7 +23,7 @@ clean: clean-spec clean-vst clean-dist
# build paper
.PHONY: paper
paper:
cd paper && $(MAKE)
@cd paper && $(MAKE)
clean-paper:
cd paper && $(MAKE) clean
......@@ -71,7 +38,7 @@ $(DIST)/specs_map.pdf:
cd paper && $(MAKE) 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)
cp -r proofs $(DIST)
mkdir $(DIST)/packages
......@@ -82,7 +49,7 @@ dist: $(DIST) $(DIST)/specs_map.pdf
cp repo $(DIST)/
cp version $(DIST)/
cp README.md $(DIST)/
cp Makefile $(DIST)/
cp coq.mk $(DIST)/Makefile
cp opam $(DIST)/
@echo $(BOLD)$(LIGHTPURPLE)"Building $(DIST).tar.gz"$(NO_COLOR)$(DARKGRAY)
tar -czvf $(DIST).tar.gz $(DIST)
......@@ -90,6 +57,6 @@ dist: $(DIST) $(DIST)/specs_map.pdf
clean-dist:
@echo $(BOLD)$(YELLOW)"removing $(DIST)"$(NO_COLOR)$(DARKGRAY)
rm -r $(DIST)
rm $(DIST).tar.gz
-rm -r $(DIST)
-rm $(DIST).tar.gz
@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
similar to square-and-multiply: the Montgomery ladder where the basic operations
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
$(X : Z)$, with $x = X/Z$; the point at infinity is represented as $(1:0)$.
See \sref{subsec:ECC-projective} for more details.
......@@ -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.
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})$
such that $x$ is the \xcoord of $P$.
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.
One of them is interpreted as the little-endian encoding of a
non-negative integer $n$ (see \ref{subsec:integer-bytes}).
One of them is interpreted as the little-endian encoding of a
non-negative integer $n$ (see \ref{subsec:integer-bytes}).
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})$,
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
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
\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}$).
\subsection{TweetNaCl specifics}
......@@ -212,9 +212,9 @@ sv car25519(gf o)
In order to simplify the verification of this function,
we treat the last iteration of the loop $i = 15$ as a separate step.
Inverses in $\Zfield$ are computed with \TNaCle{inv25519}.
This function uses exponentiation by $2^{255}-21$,
computed with the square-and-multiply algorithm.
Inverses in $\Ffield$ are computed with \TNaCle{inv25519}.
This function uses exponentiation by $2^{255}-21$,
computed with the square-and-multiply algorithm.
Fermat's little theorem gives the correctness.
Notice that in this case the inverse of $0$ is defined as $0$.
\begin{lstlisting}[language=Ctweetnacl]
......@@ -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.
\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:
the \TNaCle{crypto_scalarmult} API function of TweetNaCl,
which is implemented through the Montgomery ladder.
......
......@@ -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.''}
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.
%We use this notation to emphasis its difference with $\Ffield$ where the
%modulo by $\p$ is applied in each operations.
......@@ -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}
\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
based on formulas from [montgomery]. All calculations are performed
in GF(p), i.e., they are performed modulo p.''}~\cite{rfc7748}
In TweetNaCl, as described in \sref{subsec:Number-TweetNaCl},
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
In TweetNaCl, as described in \sref{subsec:Number-TweetNaCl},
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
as a list of integers in Coq.
We define the little-endian projection to integers as follows.
\begin{dfn}
Let \Coqe{ZofList} : $\Z \rightarrow \texttt{list}~\Z \rightarrow \Z$,
a parameterized map by $n$ between a list $l$ and its little endian representation
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"?
a function given $n$ and a list $l$ returns its little endian decoding with radix $2^n$.
\end{dfn}
We define it in Coq as:
\begin{lstlisting}[language=Coq]
......@@ -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:
\begin{dfn}
Let \Coqe{ListofZ32} : $\Z \rightarrow \Z \rightarrow \texttt{list}~\Z$, given
$n$ and $a$ returns $a$'s little-endian representation
as a list with radix $2^n$.
%XXX-Peter: Again I'm confused... why are there two \rightarrows?
$n$ and $a$ returns $a$'s little-endian encoding as a list with radix $2^n$.
%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}
We define it in Coq as:
\begin{lstlisting}[language=Coq]
......
......@@ -24,91 +24,12 @@ Theorem body_crypto_scalarmult:
crypto_scalarmult_spec.
\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
triple before proving its correctness with VST (\ref{subsec:with-VST}).
We provide an example of equivalence of operations over different number
representations (\ref{subsec:num-repr-rfc}). Then, we describe efficient techniques
used to 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}.
used in some of our more complex proofs (\ref{subsec:inversions-reflections}).
\subsection{Applying the Verifiable Software Toolchain}
......@@ -202,18 +123,6 @@ their respective bounds: arrays of 32 bytes.
The correctness of this specification is formally proven in Coq with
\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.
% The Verifiable Software Toolchain uses a strongest postcondition strategy.
......@@ -233,7 +142,8 @@ The correctness of this specification is formally proven in Coq with
\subheading{Memory aliasing.}
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}),
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})
......@@ -262,6 +172,10 @@ This solution does not cover all cases (e.g. all arguments are aliased) but it
is enough for our needs.
%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?
\subheading{Verifying \texttt{for} loops.}
Final states of \texttt{for} loops are usually computed by simple recursive functions.
......@@ -283,8 +197,6 @@ iteratively applies $g$ with decreasing index:
Then we have :
\begin{align*}
f(4,s) &= g(0,g(1,g(2,g(3,s))))
% \\
% f(3,s) &= g(0,g(1,g(2,s)))
\end{align*}
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.
......@@ -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}
As described in \sref{subsec:Number-TweetNaCl}, numbers in \TNaCle{gf} are represented
......@@ -364,7 +276,7 @@ Lemma M_bound_Zlength :
\subsection{Inversions, Reflections and Packing}
\subsection{Inversions, reflections and packing}
\label{subsec:inversions-reflections}
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
in Coq with tacticals such as \Coqe{repeat}, but it generates a proof object which
will take a long time to verify.
\subheading{Reflections.}
\subheading{Reflections.}
In order to speed up the verification we use a
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
......@@ -482,11 +394,10 @@ With this technique we prove the functional correctness of the inversion over \Z
\end{lemma}
This statement is formalized as
\begin{lstlisting}[language=Coq]
Corollary Inv25519_Zpow_GF :
forall (g:list Z),
Corollary Inv25519_Zpow_GF : forall (g:list Z),
length g = 16 ->
Z16.lst (Inv25519 g) :GF =
(pow (Z16.lst g) (2^255-21)) :GF.
(pow (Z16.lst g) (2^255-21)) :GF.
\end{lstlisting}
This reflection technique is also used where proofs requires some computing
......@@ -513,10 +424,9 @@ for(i=1;i<15;i++) {
\end{lstlisting}
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
second loop, the number represented in $\Zfield$ stays the same. This leads to
the proof that \TNaCle{pack25519} is effectively reducing modulo $\p$ and
returning a number in base $2^8$.
subtraction of \p. The resulting number represented in $\Zfield$ is invariant with
the iteration of the second loop. This result in the proof that \TNaCle{pack25519}
reduces modulo $\p$ and returns a number in base $2^8$.
\begin{lstlisting}[language=Coq]
Lemma Pack25519_mod_25519 :
forall (l:list Z),
......@@ -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};
\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:
\begin{lstlisting}[language=Coq]
Lemma Crypto_Scalarmult_RFC_eq :
......
......@@ -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
correctness of the ladder (\ref{subsec:ECC-ladder}).
\subsection{Formalization of Elliptic Curves}
\subsection{Formalization of elliptic Curves}
\label{subsec:ECC}
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
$$E(\K) = \{(x,y) \in \K \times \K | E(x,y)\} \cup \{\Oinf\}$$
\end{dfn}
\subsubsection{Weierstra{\ss} Curves}
\subsubsection{Weierstra{\ss} curves}
\label{subsec:ECC-Weierstrass}
This equation $E(x,y)$ can be reduced into its short Weierstra{\ss} form.
......@@ -106,7 +106,7 @@ Definition addec (p1 p2 : ec) : ec :=
EC p1 p2 (addO p1 p2)
\end{lstlisting}
\subsubsection{Montgomery Curves}
\subsubsection{Montgomery curves}
\label{subsec:ECC-Montgomery}
Speedups can be obtained by switching to homogeneous coordinates and other forms
......@@ -187,7 +187,7 @@ Definition ec_of_mc p :=
Lemma ec_of_mc_bij : bijective ec_of_mc.
\end{lstlisting}
\subsubsection{Projective Coordinates}
\subsubsection{Projective coordinates}
\label{subsec:ECC-projective}
On a projective plane, points are represented with a triple $(X:Y:Z)$.
......@@ -257,7 +257,7 @@ we have $X_3/Z_3 = \chi(2P_1)$.
With \lref{lemma:xADD} and \lref{lemma:xDBL}, we are able to compute efficiently
differential additions and point doubling on projective coordinates.
\subsubsection{Scalar Multiplication Algorithms}
\subsubsection{Scalar multiplication algorithms}
\label{subsec:ECC-ladder}
By taking \aref{alg:montgomery-ladder} and replacing \texttt{xDBL} and \texttt{xADD}
......@@ -341,7 +341,7 @@ Theorem opt_montgomery_ok (n m: nat) (x : K) :
opt_montgomery n m x = (p *+ n)#x0.
\end{lstlisting}
\subsection{Curves, Twists and Extension Fields}
\subsection{Curves, twists and extension fields}
To be able to use the above theorem we need to satisfy hypothesis
\ref{hyp:a_minus_4_not_square}: $a^2-4$ is not a square in \K:
......@@ -353,7 +353,7 @@ with $\K = \F{p^2}$.
We first study Curve25519 and one of the quadratic twist Twist25519, both defined
over \F{p}.
\subsubsection{Curves and Twists}
\subsubsection{Curves and twists}
\label{subsec:Zmodp}
We define $\F{p}$ as the numbers between $0$ and $p = \p$.
......@@ -372,7 +372,6 @@ Definition pi (x : Z) : type :=
Zmodp (Z_mod_betweenb x Hp_gt0).
Coercion repr (x : type) : Z :=
let: @Zmodp x _ := x in x.
End Zmodp.
\end{lstlisting}
We define the basic operations ($+, -, \times$) with their respective neutral
......@@ -451,21 +450,21 @@ Definition pi (x: Zmodp.type * Zmodp.type) : type :=
Zmodp2 x.1 x.2.
Coercion repr (x: type) : Zmodp.type*Zmodp.type :=
let: Zmodp2 u v := x in (u, v).
Definition zero : type :=
pi ( 0%:R, 0%:R ).
Definition one : type :=
pi ( 1, 0%:R ).
Definition opp (x: type) : type :=
pi (- x.1 , - x.2).
Definition add (x y: type) : type :=
pi (x.1 + y.1, x.2 + y.2).
Definition sub (x y: type) : type :=
pi (x.1 - y.1, x.2 - y.2).
Definition mul (x y: type) : type :=
pi ((x.1 * y.1) + (2%:R * (x.2 * y.2)),
(x.1 * y.2) + (x.2 * y.1)).
\end{lstlisting}
% Definition zero : type :=
% pi ( 0%:R, 0%:R ).
% Definition one : type :=
% pi ( 1, 0%:R ).
% Definition opp (x: type) : type :=
% pi (- x.1 , - x.2).
% Definition add (x y: type) : type :=
% pi (x.1 + y.1, x.2 + y.2).
% Definition sub (x y: type) : type :=
% pi (x.1 - y.1, x.2 - y.2).
We define the basic operations ($+, -, \times$) with their respective neutral
elements $0$ and $1$. Additionally we verify that for each element of in
$\F{p^2}\backslash\{0\}$, there exists a multiplicative inverse.
......@@ -484,15 +483,21 @@ Similarly as in $\F{p}$, we define $0^{-1} = 0$ and prove \lref{lemma:Zmodp2_rin
%% If need remove this paragraph
We can then specialize the basic operations in order to speed up the verification
of formulas by using rewrite rules:
\begin{align*}
\begin{equation*}
\begin{split}
(a,0) + (b,0) &= (a+b, 0)\\
(a,0) \cdot (b,0) &= (a \cdot b, 0)\\
(a, 0)^n &= (a^n, 0)\\
(a, 0)^{-1} &= (a^{-1}, 0)\\
(a, 0)\cdot (0,b) &= (0, a\cdot b)\\
(0, a)\cdot (0,b) &= (2\cdot a\cdot b, 0)\\
(0,a)^{-1} &= ((2\cdot a)^{-1},0)
\end{align*}
% (a, 0)\cdot (0,b) &= (0, a\cdot b)\\
(a, 0)^n &= (a^n, 0)\\
\end{split}
\qquad
\begin{split}
(a,0) \cdot (b,0) &= (a \cdot b, 0)\\
(0,a)^{-1} &= ((2\cdot a)^{-1},0)\\
% (0, a)\cdot (0,b) &= (2\cdot a\cdot b, 0)\\
~\\
\end{split}
\end{equation*}
......@@ -544,9 +549,9 @@ Notice that:
In summary for all $n \in \N,\ n < 2^{255}$, for any given point $P\in\F{p}\times\F{p}$
on $M_{486662,1}(\F{p})$ or $M_{486662,2}(\F{p})$, $Curve25519\_Fp$
computes the $\chi_0(n \cdot P)$.
We have proved that for all $P \in \F{p^2}\times\F{p^2}$ such that $\chi_0(P) \in \F{p}$
We proved that for all $P \in \F{p^2}\times\F{p^2}$ such that $\chi_0(P) \in \F{p}$
there exists a corresponding point on the curve or the twist over $\F{p}$.
We have proved that for any point, on the curve or the twist we can compute the
We proved that for any point, on the curve or the twist we can compute the
scalar multiplication by $n$ and yield to the same result as if we did the
computation in $\F{p^2}$.
% As a result we have proved theorem 2.1 of \cite{Ber06}:
......@@ -557,7 +562,7 @@ computation in $\F{p^2}$.
for all $x \in \F{p}$ and $P \in M_{486662,1}(\F{p^2})$ such that $\chi_0(P) = x$,
$Curve25519\_Fp(n,x)$ computes $\chi_0(n \cdot P)$.
\end{theorem}
which can be formalized in Coq as:
which is formalized in Coq as:
\begin{lstlisting}[language=Coq]
Theorem curve25519_Fp2_ladder_ok:
forall (n : nat) (x:Zmodp.type),
......
......@@ -16,16 +16,15 @@ BOLD = "\033[1m"
tweetverif.pdf: FORCE tweetverif.tex
@echo $(BOLD)$(GREEN)"Building tweetverif.pdf"$(NO_COLOR)$(DARKGRAY)
@echo $(BOLD)$(LIGHTPURPLE)"Building tweetverif.pdf"$(NO_COLOR)$(DARKGRAY)