Commit d23fddd5 authored by Peter Schwabe's avatar Peter Schwabe
Browse files

Addressed various reviewer comments

parent 61fd712d
......@@ -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:
\item The reviews we received at USENIX, together the answers we provided
in the rebuttal phase. Note that we received only reviews \#324A, \#324B, and \#324C
before the rebuttal phase.
\item The reviews we received at USENIX, together with answers to specific comments.
Some of these answers are what we already provided in the USENIX rebuttal;
before this 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
This diff is collapsed.
\section{Usenix Security 2020 Review \#324B}
\section*{Usenix Security 2020 Review \#324B}
......@@ -31,9 +31,27 @@ This paper presents two formal proofs. The first links a C implementation of the
\item The C code analyzed here is very simple; prior works have verified much more complex and optimized implementations of X25519
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.
\item The proof does not cover side-channel resistance ("constant-time")
We added a comment on ``constant-time'' verification in the introduction.
\item The details of the Coq formalization may be less interesting for non-formally oriented readers
This is true; we hope that the audience of CSF is generally more oriented towards formal verification
than (most of) the USENIX audience.
\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)
\item Show a known bug that the VST proof would prevent
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.
\item Clarify that constant-timeness is not proved here
This is clarified in the introduction now.
\item Rewrite section 5 to focus on proof structure and a few well-chosen lemmas/definitions
\todo{Say what we did here}
\section{Usenix Security 2020 Review \#324C}
\section*{Usenix Security 2020 Review \#324C}
......@@ -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.
We extended the discussion with regards to [12] in our related-work session now.
\section{Usenix Security 2020 Review \#324D}
\section*{Usenix Security 2020 Review \#324D}
......@@ -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.
The revised version of the paper includes a link to an anonymous GitHub repository,
which also contains a virtual-machine image.
\section{Usenix Security 2020 Review \#324E}
\section*{Usenix Security 2020 Review \#324E}
......@@ -40,5 +40,9 @@ In the end, I strongly feel that this paper must be rewritten with the low level
Why was this submitted to USENIX? S\&P seems like a much better venue.
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.
What am I to take away from this? How does this generalize?
\section{Usenix Security 2020 Review \#324F}
\section*{Usenix Security 2020 Review \#324F}
\section{Usenix Security 2020 Review \#324G}
\section*{Usenix Security 2020 Review \#324G}
......@@ -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:
\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}
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
......@@ -23,7 +23,6 @@ Finally, we provide a brief description of the formal tools we use in our proofs
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}))
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.}
\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)$
Markdown is supported
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