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
aca27411
Commit
aca27411
authored
Feb 15, 2020
by
Benoit Viguier
Browse files
more of Freek's comment
parent
d4fa4057
Changes
3
Show whitespace changes
Inline
Sidebyside
paper/1intro.tex
View file @
aca27411
...
...
@@ 39,7 +39,7 @@ This part of the proof uses the Verifiable Software Toolchain (VST)~\cite{2012A
to establish a link between C and Coq.
VST uses separation logic~
\cite
{
1969Hoare,Reynolds02separationlogic
}
to show that the semantics of the program satisfy a functional specification in Coq.
To the best of our knowledge, this is the first time that VST
To the best of our knowledge, this is the first time that
the
VST
is used in the formal proof of correctness of an implementation
of an asymmetric cryptographic primitive.
...
...
paper/5highlevel.tex
View file @
aca27411
...
...
@@ 32,7 +32,7 @@ We discuss the plot twist (\ref{subsec:Zmodp}) of Curve25519 and solve it (\ref{
\subsection
{
Formalization of elliptic Curves
}
\label
{
subsec:ECC
}
\fref
{
tikz:ProofHighLevel1
}
presents
an intuition
of the proof of the ladder's
\fref
{
tikz:ProofHighLevel1
}
presents
the structure
of the proof of the ladder's
correctness.
\begin{figure}
[h]
\centering
...
...
@@ 149,7 +149,7 @@ Inductive mc : Type := MC p of oncurve p.
Lemma oncurve
_
mc: forall p : mc, oncurve p.
\end{lstlisting}
We define the addition on Montgomery curves in
the
similar way as
in
the Weierstra
{
\ss
}
form.
We define the addition on Montgomery curves in
a
similar way as
for
the Weierstra
{
\ss
}
form.
\begin{lstlisting}
[language=Coq,belowskip=0.25
\baselineskip
]
Definition add (p1 p2 : point K) :=
match p1, p2 with
...
...
@@ 165,7 +165,7 @@ Definition add (p1 p2 : point K) :=
( xs,  s * (xs  x1)  y1 )
end.
\end{lstlisting}
And again we prove the result is on the curve (again with coercion):
And again we prove the result is on the curve
:
%
(again with coercion):
\begin{lstlisting}
[language=Coq]
Lemma addO (p q : mc) : oncurve (add p q).
Definition addmc (p1 p2 : mc) : mc :=
...
...
@@ 239,7 +239,7 @@ We define $\chi$ and $\chi_0$ to return the \xcoord of points on a curve.

$
\chi
_
0
: M
_{
a,b
}
(
\K
)
\to
\K
$
\\
such that
$
\chi
_
0
(
\Oinf
)
=
0
$
and
$
\chi
_
0
((
x,y
))
=
x
$
.
\end{dfn}
Using projective coordinates we prove the formula for differential addition (
\lref
{
lemma:xADD
}
).
Using projective coordinates we prove the formula for differential addition
.
%
(\lref{lemma:xADD}).
\begin{lemma}
\label
{
lemma:xADD
}
Let
$
M
_{
a,b
}$
be a Montgomery curve such that
$
a
^
2

4
$
is not a square in
\K
, and
...
...
@@ 254,11 +254,10 @@ then for any point $P_1$ and $P_2$ in $M_{a,b}(\K)$ such that
$
X
_
1
/
Z
_
1
=
\chi
(
P
_
1
)
, X
_
2
/
Z
_
2
=
\chi
(
P
_
2
)
$
, and
$
X
_
4
/
Z
_
4
=
\chi
(
P
_
1

P
_
2
)
$
,
we have
$
X
_
3
/
Z
_
3
=
\chi
(
P
_
1
+
P
_
2
)
$
.
\\
\textbf
{
Remark:
}
%For any $x \in \K \backslash\{0\}, x/0$ should be understood as $\infty$.
These definitions should be understood in
$
\K
\cup
\{\infty\}
$
.
If
$
x
\ne
0
$
then we define
$
x
/
0
=
\infty
$
.
\end{lemma}
Similarly we also prove the formula for point doubling (
\lref
{
lemma:xDBL
}
).
Similarly we also prove the formula for point doubling
.
%
(\lref{lemma:xDBL}).
\begin{lemma}
\label
{
lemma:xDBL
}
Let
$
M
_{
a,b
}$
be a Montgomery curve such that
$
a
^
2

4
$
is not a square in
\K
, and
...
...
@@ 331,7 +330,7 @@ final proof of \coqe{Theorem RFC_Correct}.
\begin{figure}
[h]
\centering
\include
{
tikz/highlevel2
}
\caption
{
Instantiation and p
roof dependencies for the correctness of X25519
}
\caption
{
P
roof dependencies for the correctness of X25519
.
}
\label
{
tikz:ProofHighLevel2
}
\end{figure}
...
...
@@ 444,10 +443,8 @@ elements here.
For this reason we decided to formalize a definition of
$
\F
{
p
^
2
}$
ourselves.
We can represent
$
\F
{
p
^
2
}$
as the set
$
\F
{
p
}
\times
\F
{
p
}$
,
%with $\delta = 2$,
%we haven't introduced this delta?
in other words,
the polynomial with coefficients in
$
\F
{
p
}$
modulo
$
X
^
2

2
$
. In a similar way
% in other words,
representing polynomials with coefficients in
$
\F
{
p
}$
modulo
$
X
^
2

2
$
. In a similar way
as for
$
\F
{
p
}$
we use a module in Coq.
\begin{lstlisting}
[language=Coq,belowskip=0.25
\baselineskip
]
Module Zmodp2.
...
...
@@ 481,7 +478,7 @@ $\F{p^2}\backslash\{0\}$, there exists a multiplicative inverse.
For all
$
x
\in
\F
{
p
^
2
}
\backslash\{
0
\}
$
and
$
a,b
\in
\F
{
p
}$
such that
$
x
=
(
a,b
)
$
,
$$
x
^{

1
}
=
\Big
(
\frac
{
a
}{
a
^
2

2
b
^
2
}
\
,
\frac
{

b
}{
a
^
2

2
b
^
2
}
\Big
)
$$
\end{lemma}
Similarly a
s in
$
\F
{
p
}$
, we define
$
0
^{

1
}
=
0
$
and prove
\lref
{
lemma:Zmodp2
_
field
}
.
A
s in
$
\F
{
p
}$
, we define
$
0
^{

1
}
=
0
$
and prove
\lref
{
lemma:Zmodp2
_
field
}
.
\begin{lemma}
\label
{
lemma:Zmodp2
_
field
}
$
\F
{
p
^
2
}$
is a commutative field.
...
...
paper/6conclusion.tex
View file @
aca27411
...
...
@@ 6,7 +6,7 @@ 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
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:
...
...
@@ 26,7 +26,7 @@ Lemma f_ext: forall (A B:Type),
specification.
\item
\textbf
{
CompCert
}
. When compiling with CompCert we only need to trust
CompCert's
{
assembly
}
semantics,
because it
has been formally proven correct.
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.
...
...
@@ 71,7 +71,7 @@ o[i]&=0xffff;
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
parse
the code properly. We believe that those
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
...
...
@@ 89,12 +89,11 @@ the verification effort to Ed25519 would make directly use of the lowlevel
arithmetic. The ladder steps formula being different this would require a high
level verification similar to
\tref
{
thm:montgomeryladdercorrect
}
.
The verification
\eg
X448~
\cite
{
cryptoeprint:2015:625,rfc7748
}
in C would
The verification
of
\eg
X448~
\cite
{
cryptoeprint:2015:625,rfc7748
}
in C would
require the adaptation of most of the lowlevel 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 and lower
the workload.
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
...
...
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