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
fdfe7791
Commit
fdfe7791
authored
Feb 14, 2020
by
Benoit Viguier
Browse files
incorporating Freek's comments
parent
8b9f4c04
Changes
7
Hide whitespace changes
Inline
Sidebyside
paper/2.2X25519.tex
View file @
fdfe7791
...
...
@@ 17,15 +17,16 @@ 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
}$
.
The X25519 function first computes a scalar
$
n'
$
from
$
n
$
by setting
bits at position 0, 1, 2 and 255 to
\texttt
{
0
}
; and
to
\texttt
{
1
}
bit at
position 254
.
bits at position 0, 1, 2 and 255 to
\texttt
{
0
}
; and
at position 254
to
\texttt
{
1
}
.
This operation is often called ``clamping'' of the scalar
$
n
$
.
Note that
$
n'
\in
2
^{
254
}
+
8
\{
0
,
1
,
\ldots
,
2
^{
251
}

1
\}
$
.
X25519 then computes the
\xcoord
of
$
n'
\cdot
P
$
.
RFC~7748~
\cite
{
rfc7748
}
standardize
d
the X25519 Diffie–Hellman keyexchange algorithm.
RFC~7748~
\cite
{
rfc7748
}
standardize the X25519 Diffie–Hellman keyexchange algorithm.
Given the base point
$
B
$
where
$
X
_
B
=
9
$
, each party generates 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
$
s
_
a
\cdot
s
_
b
\cdot
B
$
with
X25519 on
$
s
_
a
$
and
$
X
_{
P
_
b
}$
(respectively
$
s
_
b
$
and
$
X
_{
P
_
a
}$
).
paper/2.3TweetNaCl.tex
View file @
fdfe7791
...
...
@@ 15,7 +15,7 @@ TweetNaCl functions take pointers as arguments. By convention the first one
points to the output array
\texttt
{
o
}
. It is then followed by the input arguments.
Due to some limitations of the VST, indexes used in
\TNaCle
{
for
}
loops have to be
of type
\TNaCle
{
int
}
instead of
\TNaCle
{
i64
}
. We change the code to allow our
of type
\TNaCle
{
int
}
instead of
\TNaCle
{
i64
}
. We change
d
the code to allow our
proofs to carry through. We believe this does not affect the correctness of the
original code. A complete diff of our modifications to TweetNaCl can be found in
Appendix~
\ref
{
verifiedCanddiff
}
.
...
...
@@ 67,7 +67,7 @@ This function is considerably more complex as it needs to convert
to a
\emph
{
unique
}
representation, i.e., also fully reduce modulo
$
p
$
and remove the redundancy of the radix
$
2
^{
16
}$
representation.
The C definition of those functions are available in
The C definition
s
of those functions are available in
Appendix
\ref
{
verifiedCanddiff
}
.
\subheading
{
The Montgomery ladder.
}
...
...
@@ 126,4 +126,4 @@ int crypto_scalarmult(u8 *q,
}
\end{lstlisting}
Also n
ote that lines 10
\&
11 represent the ``clamping'' operation.
N
ote that lines 10
\&
11 represent the ``clamping'' operation.
paper/2.5Coq.tex
View file @
fdfe7791
...
...
@@ 33,7 +33,7 @@ memory shared such as being disjoint.
We discuss this limitation further in
\sref
{
subsec:withVST
}
.
The Verified Software Toolchain (VST)~
\cite
{
cao2018vstfloyd
}
is a framework
which uses
S
eparation logic proven correct with respect to CompCert semantics
which uses
s
eparation logic
(
proven correct with respect to CompCert semantics
)
to prove the functional correctness of C programs.
The first step consists of translating the source code into Clight,
an intermediate representation used by CompCert.
...
...
@@ 41,4 +41,4 @@ For such purpose one uses the parser of CompCert called \texttt{clightgen}.
In a second step one defines the Hoare triple representing the specification of
the piece of software one wants to prove. Then using the VST, one uses a strongest
postcondition approach to prove the correctness of the triple.
This
approach
can be seen as a forward symbolic execution of the program.
This can be seen as a forward symbolic execution of the program.
paper/3RFC.tex
View file @
fdfe7791
...
...
@@ 4,7 +4,7 @@
In this section we present our formalization of RFC~7748~
\cite
{
rfc7748
}
.
\begin{informaltheorem}
The specification of X25519 in RFC~7748 is formalized by
\Coqe
{
RFC
}
in Coq.
The specification of X25519 in RFC~7748 is formalized by
the function
\Coqe
{
RFC
}
in Coq.
\end{informaltheorem}
More specifically, we formalized X25519 with the following definition:
...
...
@@ 84,14 +84,15 @@ match m with
end.
\end{lstlisting}
Our formalization matches perfectly the RFC. In order to optimize the
The comments in the ladder represent the text from the RFC which
our formalization matches perfectly. In order to optimize the
number of calls to
\texttt
{
CSWAP
}
(defined in
\sref
{
cswap
}
)
the RFC uses an additional variable to decide whether a conditional swap
is required or not
, this differ from
\aref
{
alg:montgomeryladder
}
.
is required or not.
Later in our proof we use a simpler description of the ladder
(
\coqe
{
montgomery
_
rec
}
) which follows strictly the
shape of
the exponent
and prove those ladder equivalent.
(
\coqe
{
montgomery
_
rec
}
) which follows strictly the
\aref
{
alg:montgomeryladder
}
and prove those ladder equivalent.
\emph
{
``To implement the X25519(k, u) [...] functions (where k is
the scalar and u is the ucoordinate), first decode k and u and then
...
...
paper/4.1VST.tex
View file @
fdfe7791
...
...
@@ 84,10 +84,10 @@ As postcondition we have conditions like:
We show that the computation for
\VSTe
{
RFC
}
fits in
\TNaCle
{
u8[32]
}
.
\end{itemize}
computes the same result as
\VSTe
{
RFC
}
in Coq provided that inputs are within
their respective bounds: arrays of 32 bytes.
\TNaCle
{
crypto
_
scalarmult
}
computes the same result as
\VSTe
{
RFC
}
in Coq provided that inputs are within
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
as
\coqe
{
Theorem body
_
crypto
_
scalarmult
}
.
% \begin{sloppypar}
...
...
@@ 141,18 +141,19 @@ we define an additional parameter $k$ with values in $\{0,1,2,3\}$:
\item
else there is no aliasing.
\end{itemize}
In the proof of our specification, we do a case analysis over
$
k
$
when needed.
This solution does not
generate
all the possible cases of aliasing over 3 pointers
(
\eg
\texttt
{
o
}
=
\texttt
{
a
}
=
\texttt
{
b
}
) but it is enough to
cover
our needs.
This solution does not
cover
all the possible cases of aliasing over 3 pointers
(
\eg
\texttt
{
o
}
=
\texttt
{
a
}
=
\texttt
{
b
}
) but it is enough to
satisfy
our needs.
\subheading
{
Improving speed.
}
To make the verification the smoothest, the Coq formal definition of the function
should be as close as possible to the C implementation
behavior
.
should be as close as possible to the C implementation.
Optimizations of such definitions are often counterproductive as they increase the
amount of proofs required for
\eg
bounds checking, loop
s
invariants.
amount of proofs required for
\eg
bounds checking, loop invariants.
In order to further speedup the verification process, to prove the specification
\TNaCle
{
crypto
_
scalarmult
}
, we only need the specification of the subsequently
called functions (
\eg
\TNaCle
{
M
}
).
This provide with multiple advantages: the verification by
the Coq kernel
can be
This provide with multiple advantages: the verification by
Coq
can be
done in parallel and multiple users can work on proving different functions at
the same time. For the sake of completeness we proved all intermediate functions.
the same time.
% We proved all intermediate functions.
paper/4.3numbers.tex
View file @
fdfe7791
...
...
@@ 4,7 +4,7 @@
As described in
\sref
{
subsec:NumberTweetNaCl
}
, numbers in
\TNaCle
{
gf
}
are represented
in
$
2
^{
16
}$
and we use a direct mapping to represent that array as a list
integers in Coq. However, in order to show the correctness of the basic operations,
we need to convert this number to a
full
integer.
we need to convert this number to a
n
integer.
We reuse the mapping
$
\text
{
\coqe
{
ZofList
}}
:
\Z
\rightarrow
\texttt
{
list
}
~
\Z
\rightarrow
\Z
$
from
\sref
{
sec:CoqRFC
}
and define a notation where
$
n
$
is
$
16
$
, placing us with a radix of
$
2
^{
16
}$
.
...
...
@@ 15,7 +15,7 @@ To facilitate working in $\Zfield$, we define the \coqe{:GF} notation.
\begin{lstlisting}
[language=Coq]
Notation "A :GF" := (A mod (2
^
25519)).
\end{lstlisting}
Later in
\sref
{
subsec:Zmodp
}
, we formally define
$
\Ffield
$
.
Later in
\sref
{
subsec:Zmodp
}
, we formally define
$
\Ffield
$
as a field
.
Equivalence between operations in
$
\Zfield
$
(
\ie
under
\coqe
{
:GF
}
) and in
$
\Ffield
$
are easily proven.
Using these two definitions, we prove intermediate lemmas such as the correctness of the
...
...
paper/4.4reflections.tex
View file @
fdfe7791
Then u
sing ``Reflections'' techniques (chapter 15 in
\cite
{
CpdtJFR
}
), we prove
the functional correctness of the invers
ion
over
\Zfield
.
U
sing ``Reflections'' techniques (chapter 15 in
\cite
{
CpdtJFR
}
), we prove
the functional correctness of the
multiplicative
invers
e
over
\Zfield
.
\begin{lemma}
\label
{
cor:inv
_
comput
_
field
}
\Coqe
{
Inv25519
}
computes an inverse in
\Zfield
.
...
...
@@ 16,7 +16,7 @@ Corollary Inv25519_Zpow_GF : forall (g:list Z),
By using each function
\coqe
{
Low.M
}
;
\coqe
{
Low.A
}
;
\coqe
{
Low.Sq
}
;
\coqe
{
Low.Zub
}
;
\coqe
{
Unpack25519
}
;
\coqe
{
clamp
}
;
\coqe
{
Pack25519
}
;
\coqe
{
Inv25519
}
;
\coqe
{
car25519
}
;
\coqe
{
montgomery
_
rec
}
, we defined in Coq
\coqe
{
Crypto
_
Scalarmult
}
and with VST
proved it m
imic
s the exact behavior of X25519 in TweetNaCl.
proved it m
atche
s the exact behavior of X25519 in TweetNaCl.
\end{sloppypar}
\begin{sloppypar}
...
...
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