Skip to content
GitLab
Menu
Projects
Groups
Snippets
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
Menu
Open sidebar
Benoit Viguier
coqveriftweetnacl
Commits
7067f229
Commit
7067f229
authored
Aug 17, 2019
by
Benoit Viguier
Browse files
finish paper: one todo left = conclusion
parent
bb8cee63
Changes
5
Expand all
Hide whitespace changes
Inline
Sidebyside
paper/conclusion.tex
View file @
7067f229
...
@@ 26,12 +26,11 @@ Lemma f_ext: forall (A B:Type),
...
@@ 26,12 +26,11 @@ Lemma f_ext: forall (A B:Type),
\item
\textbf
{
Verifiable Software Toolchain
}
. This framework developed at
\item
\textbf
{
Verifiable Software Toolchain
}
. This framework developed at
Princeton allows a user to prove that a
\texttt
{
CLight
}
code matches pure Coq
Princeton allows a user to prove that a
\texttt
{
CLight
}
code matches pure Coq
specification. However one must trust the framework properly captures and
specification. However one must trust the framework properly captures and
map the CLight behavior to the basic pure Coq functions.
At the beginning of
map the CLight behavior to the basic pure Coq functions.
the project we found inconsistency and reported them to the authors.
% At the beginning of
the project we found inconsistency and reported them to the authors.
\item
\textbf
{
CompCert
}
. The formally proven compiler. We trust that the Clight
\item
\textbf
{
CompCert
}
. The formally proven compiler. We trust that the Clight
model captures correctly the C standard.
model captures correctly the C99 standard.
\todo
{
VERIFY THIS, WHICH STANDARD ?
}
.
Our proof also assumes that the TweetNaCl code will behave as expected if
Our proof also assumes that the TweetNaCl code will behave as expected if
compiled under CompCert. We do not provide guarantees for other C compilers
compiled under CompCert. We do not provide guarantees for other C compilers
such as Clang or GCC.
such as Clang or GCC.
...
@@ 47,10 +46,8 @@ o[i] = aux1 + aux2;
...
@@ 47,10 +46,8 @@ o[i] = aux1 + aux2;
\end{lstlisting}
\end{lstlisting}
The trust of the proof relied on the trust of a correct translation from the
The trust of the proof relied on the trust of a correct translation from the
initial version of
\textit
{
TweetNaCl
}
to
\textit
{
TweetNaclVerificable
}
.
initial version of
\textit
{
TweetNaCl
}
to
\textit
{
TweetNaclVerificable
}
.
\texttt
{
clightgen
}
now comes with
\texttt
{
normalize
}
flag which
While this problem is still present, the CompCert developers provided us with
factors out function calls and assignments from inside subexpressions.
the
\texttt
{
normalize
}
option for
\texttt
{
clightgen
}
which takes care of
generating auxiliary variables in order to automatically derive these steps.
The changes required for a Ccode to make it Verifiable are now minimal.
The changes required for a Ccode to make it Verifiable are now minimal.
\item
Last but not the least, we must trust: the
\textbf
{
Coq kernel
}
and its
\item
Last but not the least, we must trust: the
\textbf
{
Coq kernel
}
and its
...
@@ 59,10 +56,26 @@ o[i] = aux1 + aux2;
...
@@ 59,10 +56,26 @@ o[i] = aux1 + aux2;
done with this architecture
\cite
{
2015Appel,coqfaq
}
.
done with this architecture
\cite
{
2015Appel,coqfaq
}
.
\end{itemize}
\end{itemize}
\subsection
{
Modifications in TweetNaCl
}
\subsection
{
Corrections in TweetNaCl
}
As a result of this verification, we removed superflous code.
Indeed the upper 64 indexes of the
\TNaCle
{
i64 x[80]
}
intermediate variable of
\TNaCle
{
crypto
_
scalarmult
}
were adding unnecessary complexity to the code, we fixed it.
Peter Wu and Jason A. Donenfeld brought to our attention that the original
\TNaCle
{
car25519
}
function presented risk of Undefined Behavior if
\texttt
{
c
}
is a negative number.
\begin{lstlisting}
[language=Ctweetnacl]
c=o[i]>>16;
o[i]=c<<16; // c < 0 = UB !
\end{lstlisting}
By replacing statement by a logical
\texttt
{
and
}
(and proving the correctness)
we solved this problem.
\begin{lstlisting}
[language=Ctweetnacl]
o[i]
&
=0xffff;
\end{lstlisting}
The upper 64 indexes of the
\TNaCle
{
i64 x[80]
}
intermediate variable of
We believe that the type change of the loop index (
\TNaCle
{
int
}
instead of
\TNaCle
{
i64
}
)
\TNaCle
{
crypto
_
scalarmult
}
were adding unnecessary complexity to the code,
does not impact the trust of our proof.
we fixed it.
\todo
{
Mention Peter Wu and Jason A. Donenfeld change to car25519
}
\todo
{
I don't see what to say more here.
}
paper/highlevel.tex
View file @
7067f229
This diff is collapsed.
Click to expand it.
paper/lowlevel.tex
View file @
7067f229
...
@@ 296,6 +296,9 @@ We formalized this result in a generic way in Appendix~\ref{subsubsec:for}.
...
@@ 296,6 +296,9 @@ We formalized this result in a generic way in Appendix~\ref{subsubsec:for}.
Using this formalization, we prove that the 255 steps of the Montgomery ladder
Using this formalization, we prove that the 255 steps of the Montgomery ladder
in C provide the same computations as in
\coqe
{
CSM
}
.
in C provide the same computations as in
\coqe
{
CSM
}
.
\subsection
{
Number Representation and C Implementation
}
\subsection
{
Number Representation and C Implementation
}
As described in
\sref
{
subsec:NumberTweetNaCl
}
, numbers in
\TNaCle
{
gf
}
are represented
As described in
\sref
{
subsec:NumberTweetNaCl
}
, numbers in
\TNaCle
{
gf
}
are represented
...
@@ 323,7 +326,6 @@ To facilitate working in \Zfield, we define the \coqe{:GF} notation.
...
@@ 323,7 +326,6 @@ To facilitate working in \Zfield, we define the \coqe{:GF} notation.
\begin{lstlisting}
[language=Coq]
\begin{lstlisting}
[language=Coq]
Notation "A :GF" := (A mod (2
^
25519)).
Notation "A :GF" := (A mod (2
^
25519)).
\end{lstlisting}
\end{lstlisting}
Later in
\sref
{
sec:maths
}
, we formally define
\F
{
\p
}
.
Later in
\sref
{
sec:maths
}
, we formally define
\F
{
\p
}
.
Equivalence between operations under
\coqe
{
:GF
}
and in
\F
{
\p
}
are easily proven.
Equivalence between operations under
\coqe
{
:GF
}
and in
\F
{
\p
}
are easily proven.
...
@@ 363,6 +365,9 @@ Lemma M_bound_Zlength :
...
@@ 363,6 +365,9 @@ Lemma M_bound_Zlength :
Forall (fun x => 38 <= x < 2
^
16 + 38) (Low.M a b).
Forall (fun x => 38 <= x < 2
^
16 + 38) (Low.M a b).
\end{lstlisting}
\end{lstlisting}
\subsection
{
Inversions, Reflections and Packing
}
\subsection
{
Inversions, Reflections and Packing
}
We now turn our attention to the inversion in
\Zfield
and techniques to
We now turn our attention to the inversion in
\Zfield
and techniques to
...
@@ 403,7 +408,6 @@ Function pow_fn_rev (a:Z) (b:Z)
...
@@ 403,7 +408,6 @@ Function pow_fn_rev (a:Z) (b:Z)
let prev := pow
_
fn
_
rev (a  1) b c g in
let prev := pow
_
fn
_
rev (a  1) b c g in
step
_
pow (b  a) prev g.
step
_
pow (b  a) prev g.
\end{lstlisting}
\end{lstlisting}
This
\Coqe
{
Function
}
requires a proof of termination. It is done by proving the
This
\Coqe
{
Function
}
requires a proof of termination. It is done by proving the
wellfoundedness of the decreasing argument:
\Coqe
{
measure Z.to
_
nat a
}
. Calling
wellfoundedness of the decreasing argument:
\Coqe
{
measure Z.to
_
nat a
}
. Calling
\Coqe
{
pow
_
fn
_
rev
}
254 times allows us to reproduce the same behavior as the
\texttt
{
Clight
}
definition.
\Coqe
{
pow
_
fn
_
rev
}
254 times allows us to reproduce the same behavior as the
\texttt
{
Clight
}
definition.
...
@@ 443,6 +447,7 @@ Lemma Inv25519_Z_GF : forall (g:list Z),
...
@@ 443,6 +447,7 @@ Lemma Inv25519_Z_GF : forall (g:list Z),
(Z16.lst (Inv25519 g)) :GF =
(Z16.lst (Inv25519 g)) :GF =
(Inv25519
_
Z (Z16.lst g)) :GF.
(Inv25519
_
Z (Z16.lst g)) :GF.
\end{lstlisting}
\end{lstlisting}
In TweetNaCl,
\TNaCle
{
inv25519
}
computes an inverse in
$
\Zfield
$
.
In TweetNaCl,
\TNaCle
{
inv25519
}
computes an inverse in
$
\Zfield
$
.
It uses Fermat's little theorem by doing an exponentiation to
$
2
^{
255
}

21
$
.
It uses Fermat's little theorem by doing an exponentiation to
$
2
^{
255
}

21
$
.
This is done by applying a squareandmultiply algorithm. The binary representation
This is done by applying a squareandmultiply algorithm. The binary representation
...
@@ 570,6 +575,7 @@ Definition decide_f_inv (f:formula_inv) : bool :=
...
@@ 570,6 +575,7 @@ Definition decide_f_inv (f:formula_inv) : bool :=
 Eq
_
inv x y => decide
_
e
_
inv x y
 Eq
_
inv x y => decide
_
e
_
inv x y
end.
end.
\end{lstlisting}
\end{lstlisting}
We prove our decision procedure correct.
We prove our decision procedure correct.
\begin{lemma}
\begin{lemma}
\label
{
lemma:decide
}
\label
{
lemma:decide
}
...
@@ 583,6 +589,7 @@ Lemma decide_formula_inv_impl :
...
@@ 583,6 +589,7 @@ Lemma decide_formula_inv_impl :
decide
_
f
_
inv f = true >
decide
_
f
_
inv f = true >
f
_
inv
_
denote f.
f
_
inv
_
denote f.
\end{lstlisting}
\end{lstlisting}
By reification to over DSL (
\lref
{
lemma:reify
}
) and by applying our decision
By reification to over DSL (
\lref
{
lemma:reify
}
) and by applying our decision
(
\lref
{
lemma:decide
}
), we prove the following corollary.
(
\lref
{
lemma:decide
}
), we prove the following corollary.
\begin{lemma}
\begin{lemma}
...
@@ 633,6 +640,7 @@ for(i=1;i<15;i++) {
...
@@ 633,6 +640,7 @@ for(i=1;i<15;i++) {
m[i1]
&
=0xffff;
m[i1]
&
=0xffff;
}
}
\end{lstlisting}
\end{lstlisting}
This loop separation allows simpler proofs. The first loop is seen as the subtraction of a number in
\Zfield
.
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.
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
$
.
This leads to the proof that
\TNaCle
{
pack25519
}
is effectively reducing modulo
$
\p
$
and returning a number in base
$
2
^
8
$
.
...
...
paper/macros.tex
View file @
7067f229
...
@@ 4,7 +4,7 @@
...
@@ 4,7 +4,7 @@
\newtheorem
{
proposition
}
[theorem]
{
Proposition
}
\newtheorem
{
proposition
}
[theorem]
{
Proposition
}
\newtheorem
{
corollary
}
[theorem]
{
Corollary
}
\newtheorem
{
corollary
}
[theorem]
{
Corollary
}
\newtheorem
{
dfn
}
[theorem]
{
Definition
}
\newtheorem
{
dfn
}
[theorem]
{
Definition
}
\newtheorem
{
hypothesis
}{
Hypothesis
}
\newtheorem
{
hypothesis
}
[theorem]
{
Hypothesis
}
\newcommand\invisiblesection
[1]
{
%
\newcommand\invisiblesection
[1]
{
%
\refstepcounter
{
section
}
\refstepcounter
{
section
}
...
...
paper/preliminaries.tex
View file @
7067f229
...
@@ 244,7 +244,6 @@ sv pack25519(u8 *o,const gf n)
...
@@ 244,7 +244,6 @@ sv pack25519(u8 *o,const gf n)
}
}
}
}
\end{lstlisting}
\end{lstlisting}
As we can see, this function is considerably more complex than the
As we can see, this function is considerably more complex than the
unpacking function. The reason is that it needs to convert
unpacking function. The reason is that it needs to convert
to a
\emph
{
unique
}
representation before packing into the output
to a
\emph
{
unique
}
representation before packing into the output
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment