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
......@@ -212,7 +212,7 @@ 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}.
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.
......
......@@ -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
......@@ -140,10 +140,7 @@ 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$.
$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
......@@ -482,8 +394,7 @@ 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.
......@@ -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)
python3 latexrun.py tweetverif.tex
tweetverif.tex: FORCE $(FILES) collection.bib
@echo $(BOLD)$(YELLOW)"Generating tweetverif.tex"$(NO_COLOR)$(DARKGRAY)
python3 gen.py tweetverif.tex
@echo $(BOLD)$(GREEN)"Done."$(NO_COLOR)
specs_map.pdf: FORCE _files.tex
@echo $(BOLD)$(GREEN)"Building specs_map.pdf"$(NO_COLOR)$(DARKGRAY)
@echo $(BOLD)$(LIGHTPURPLE)"Building specs_map.pdf"$(NO_COLOR)$(DARKGRAY)
python3 latexrun.py _files.tex
@echo $(BOLD)$(ORANGE)"Moving specs_map.pdf to ../"$(NO_COLOR)$(DARKGRAY)
@mv _files.pdf ../specs_map.pdf
......
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