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
coq-verif-tweetnacl
Commits
d23fddd5
Commit
d23fddd5
authored
Oct 01, 2020
by
Peter Schwabe
Browse files
Addressed various reviewer comments
parent
61fd712d
Changes
10
Expand all
Hide whitespace changes
Inline
Side-by-side
paper/csf-supplementary/previous.tex
View file @
d23fddd5
...
...
@@ -38,9 +38,9 @@ and to the USENIX Security Symposium (submission deadline February 15, 2020).
The paper received a ``reject'' decision from IEEE S
\&
P and a ``reject-and-resubmit''
decision from USENIX. In this supplementary material we provide the following documents:
\begin{itemize}
\item
The reviews we received at USENIX, together th
e
answers
we provided
in the rebuttal phase. Not
e
t
hat we
received only reviews
\#
324A,
\#
324B, and
\#
324C
before th
e
rebuttal
phase
.
\item
The reviews we received at USENIX, together
wi
th answers
to specific comments.
Some of these answers ar
e
w
hat we
already provided in the USENIX rebuttal;
before th
is
rebuttal
we had only received reviews
\#
324A,
\#
324B, and
\#
324C
.
\item
The version of the manuscript we submitted to USENIX. This version
contains in Appendix D the reviews we received at IEEE S
\&
P and our replies
to those reviews explaining how we addressed them in the revised version
...
...
paper/csf-supplementary/usenix-a.tex
View file @
d23fddd5
This diff is collapsed.
Click to expand it.
paper/csf-supplementary/usenix-b.tex
View file @
d23fddd5
\newpage
\section
{
Usenix Security 2020 Review
\#
324B
}
\section
*
{
Usenix Security 2020 Review
\#
324B
}
\begin{tabular}
{
rrp
{
.6
\textwidth
}}
\toprule
...
...
@@ -31,9 +31,27 @@ This paper presents two formal proofs. The first links a C implementation of the
\begin{itemize}
\item
The C code analyzed here is very simple; prior works have verified much more complex and optimized implementations of X25519
\end{itemize}
\begin{answer}
It is true that the C code is more simple and less optimized than the code considered in other verification efforts.
However, unlike
\emph
{
most
}
previous X25519 verification efforts we verify pre-existing code written in a language
that is not developed with easy verification in mind (like jasmin or F
$^
*
$
).
Also, our proof goes beyond what all previous X25519 verification efforts targeted and links the
high-level specification to the mathematical definition of X25519.
\end{answer}
\begin{itemize}
\item
The proof does not cover side-channel resistance ("constant-time")
\end{itemize}
\begin{answer}
We added a comment on ``constant-time'' verification in the introduction.
\end{answer}
\begin{itemize}
\item
The details of the Coq formalization may be less interesting for non-formally oriented readers
\end{itemize}
\begin{answer}
This is true; we hope that the audience of CSF is generally more oriented towards formal verification
than (most of) the USENIX audience.
\end{answer}
\begin{center}
\subheading
{
===== Detailed comments for authors =====
}
...
...
@@ -56,6 +74,25 @@ I enjoyed Section 5 and I believe it is one of the more important (and reusable)
\begin{itemize}
\item
Show a known bug that the VST proof would prevent
\end{itemize}
\begin{answer}
The most concerning bugs are, as the reviewer mentions, carry bugs that are triggered only with
very small probability on random inputs. As TweetNaCl uses a different internal representation
of field elements than the speed-optimized implementations that had such bugs in the past, we
cannot easily put precisely such a known bug into the software.
\\
As we provide the software together with the proofs, it is easy though, to see how the proof fails,
if, for example the final call to
\texttt
{
car25519
}
in the
\texttt
{
M
}
routine is omitted.
\end{answer}
\begin{itemize}
\item
Clarify that constant-timeness is not proved here
\end{itemize}
\begin{answer}
This is clarified in the introduction now.
\end{answer}
\begin{itemize}
\item
Rewrite section 5 to focus on proof structure and a few well-chosen lemmas/definitions
\end{itemize}
\begin{answer}
\todo
{
Say what we did here
}
\end{answer}
paper/csf-supplementary/usenix-c.tex
View file @
d23fddd5
\newpage
\section
{
Usenix Security 2020 Review
\#
324C
}
\section
*
{
Usenix Security 2020 Review
\#
324C
}
\begin{tabular}
{
rrp
{
.6
\textwidth
}}
\toprule
...
...
@@ -95,6 +95,7 @@ Let me start by stating that I’m no expert but rather an enthusiast hoping to
\item
bugs in the freezing (full modular reduction) of the final result,
\item
inconsistencies between the specification and the mathematical model.
\end{itemize}
We extended the discussion with regards to [12] in our related-work session now.
\end{answer}
\begin{center}
...
...
paper/csf-supplementary/usenix-d.tex
View file @
d23fddd5
\newpage
\section
{
Usenix Security 2020 Review
\#
324D
}
\section
*
{
Usenix Security 2020 Review
\#
324D
}
\begin{tabular}
{
rrp
{
.6
\textwidth
}}
\toprule
...
...
@@ -56,4 +56,7 @@ So, while I really like this work, the lack of reproducibility even with access
Please provide a working version, either clear instructions on how to build, or maybe a virtual machine image.
\begin{answer}
The revised version of the paper includes a link to an anonymous GitHub repository,
which also contains a virtual-machine image.
\end{answer}
paper/csf-supplementary/usenix-e.tex
View file @
d23fddd5
\newpage
\section
{
Usenix Security 2020 Review
\#
324E
}
\section
*
{
Usenix Security 2020 Review
\#
324E
}
\begin{tabular}
{
rrp
{
.6
\textwidth
}}
\toprule
...
...
@@ -40,5 +40,9 @@ In the end, I strongly feel that this paper must be rewritten with the low level
\end{center}
Why was this submitted to USENIX? S
\&
P seems like a much better venue.
\begin{answer}
Apparently the reviewer did not realize that the work had been submitted to S
\&
P before.
We hope that CSF is also a much better venue.
\end{answer}
What am I to take away from this? How does this generalize?
paper/csf-supplementary/usenix-f.tex
View file @
d23fddd5
\newpage
\section
{
Usenix Security 2020 Review
\#
324F
}
\section
*
{
Usenix Security 2020 Review
\#
324F
}
\begin{tabular}
{
rrp
{
.6
\textwidth
}}
\toprule
...
...
paper/csf-supplementary/usenix-g.tex
View file @
d23fddd5
\newpage
\section
{
Usenix Security 2020 Review
\#
324G
}
\section
*
{
Usenix Security 2020 Review
\#
324G
}
\begin{tabular}
{
rrp
{
.6
\textwidth
}}
\toprule
...
...
paper/intro.tex
View file @
d23fddd5
...
...
@@ -53,12 +53,41 @@ To our knowledge, this verification effort is the first to not just
connect a low-level implementation to a higher-level implementation (or ``specification''),
but to prove correctness all the way up
to the mathematical definition in terms of scalar multiplication on an elliptic curve.
As a consequence, the result of this paper can readily be used in mechanized proofs of
higher-level protocols that work with the mathematical definition of X25519.
As a consequence, the result of this paper can readily be used in mechanized proofs
arguing about the security of cryptographic constructions on the more abstract
level of operations in groups and related problems, like the elliptic-curve
discrete-logarithm (ECDLP) or elliptic-curve Diffie-Hellman (ECDH) problem.
\todo
{
Add examples of such mechanized proofs?
}
Also, connecting our formalization of the RFC to the mathematical definition
significantly increases trust into the correctness of the formalization and
reduces the effort of manual auditing of that formalization.
\subheading
{
The bigger picture of high-assurance crypto.
}
This work fits into the bigger area of
\emph
{
high-assurance
}
cryptography,
i.e., a line of work that applies techniques and tools from formal methods
to obtain computer-verified guarantees for cryptographic software.
Traditionally, high-assurance cryptography is concerned with three main properties
of cryptographic software:
\begin{enumerate}
\item
verifying
\textbf
{
correctness
}
of cryptographic software,
typically against a high-level specification;
\label
{
hacs:correct
}
\item
verifying
\textbf
{
implementation security
}
and in particular
security against timing attacks; and
\label
{
hacs:sca
}
\item
verifying
\textbf
{
cryptographic security
}
notions of primitives and protocols
through computer-checked reductions from some assumed-to-be-hard mathematical problem.
\label
{
hacs:secure
}
\end{enumerate}
A recent addition to this triplet (or rather an extension of implementation security)
is security also against speculative attacks. See, e.g.,~
\cite
{
XXX
}
.
This paper targets only the first point and attempts to make results
immediately usable for verification efforts of cryptographic security.
Verification of implementation security is probably equally important as
verification of correctness, but working on the C language level as we do
in this paper is not helpful. To obtain guarantees of security against
timing-attack we recommend verifying
\emph
{
compiled
}
code on LLVM level with,
e.g., ct-verif~
\cite
{
XXX
}
,
or even better on binary level with, e.g., BinSec/Rel~
\cite
{
XXX
}
.
\subheading
{
Related work.
}
The field of computer-aided cryptography, i.e., using computer-verified proofs
to strengthen our trust into cryptographic constructions and cryptographic software,
...
...
@@ -103,6 +132,10 @@ Their proof takes a different approach from ours.
It uses heavy annotation of the assembly-level code in order to ``guide'' a SAT solver;
also, it does not cover the full X25519 functionality and does
not make the link to the mathematical definition from~
\cite
{
Ber06
}
.
As a consequence, this work would not find bugs in any of the routines
processing the scalar (like ``clamping'', see Section~
\ref
{
subsec:X25519-key-exchange
}
),
bugs in the the serialization routines or, maybe most importantly,
bugs in the high-level specification that the code is verified against.
Finally, in terms of languages and tooling the work closest to what we present here
is the proof of correctness of OpenSSL's
...
...
paper/preliminaries.tex
View file @
d23fddd5
...
...
@@ -23,7 +23,6 @@ Finally, we provide a brief description of the formal tools we use in our proofs
\end{dfn}
Details of the formalization can be found in
\sref
{
subsec:ECC-Montgomery
}
.
For
$
M
_{
a,b
}$
over a finite field
$
\F
{
p
}$
, the parameter
$
b
$
is known as the ``twisting factor''.
For
$
b'
\in
\F
{
p
}
\backslash\{
0
\}
$
and
$
b'
\neq
b
$
, the curves
$
M
_{
a,b
}$
and
$
M
_{
a,b'
}$
are isomorphic via
$
(
x,y
)
\mapsto
(
x,
\sqrt
{
b
/
b'
}
\cdot
y
)
$
.
...
...
@@ -51,10 +50,13 @@ We define the operation:
\texttt
{
xDBL
\&
ADD
}
&
: (x
_{
Q-P
}
, (X
_
P:Z
_
P), (X
_
Q:Z
_
Q))
\mapsto
\\
&
((X
_{
2
\cdot
P
}
:Z
_{
2
\cdot
P
}
), (X
_{
P + Q
}
:Z
_{
P + Q
}
))
\end{align*}
In the Montgomery ladder,
% notice that
% the arguments of \texttt{xADD} and \texttt{xDBL}
A pseudocode description of the Montgomery ladder
is given in Algorithm~
\ref
{
alg:montgomery-ladder
}
.
The main loop iterates over the bits of the scalar
$
n
$
.
The
$
k
^{
\text
{
th
}}$
iteration conditionally swaps
the arguments
$
P
$
and
$
Q
$
of
\texttt
{
xDBL
\&
ADD
}
are swapped
depending on the value of the
$
k
^{
\text
{
th
}}$
bit.
depending on the value of the
$
k
^{
\text
{
th
}}$
bit
of
$
n
$
.
We use a conditional swap
\texttt
{
CSWAP
}
to change the arguments of the above
function while keeping the same body of the loop.
\label
{
cswap
}
Given a pair
$
(
P
_
0
, P
_
1
)
$
and a bit
$
b
$
,
\texttt
{
CSWAP
}
returns the pair
...
...
@@ -66,7 +68,7 @@ computing a \xcoord-only scalar multiplication (see \aref{alg:montgomery-ladder}
\caption
{
Montgomery ladder for scalar mult.
}
\label
{
alg:montgomery-ladder
}
\begin{algorithmic}
\REQUIRE
{
\xcoord
$
x
_
P
$
of a point
$
P
$
, scalar
$
n
$
with
$
n <
2
^
m
$}
\REQUIRE
{
\xcoord
$
x
_
P
$
of a point
$
P
$
, scalar
$
n
$
of bitlength upperbound by some integer
$
m
$}
\ENSURE
{
\xcoord
$
x
_
Q
$
of
$
Q
=
n
\cdot
P
$}
\STATE
$
Q
=
(
X
_
Q:Z
_
Q
)
\leftarrow
(
1
:
0
)
$
\STATE
$
R
=
(
X
_
R:Z
_
R
)
\leftarrow
(
x
_
P:
1
)
$
...
...
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