Addressed various reviewer comments

paper/csf-supplementary/previous.tex

@@ -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 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

paper/csf-supplementary/usenix-b.tex

 \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

 \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

 \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

 \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

 \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

 \newpage
-\section{Usenix Security 2020 Review \#324G}
+\section*{Usenix Security 2020 Review \#324G}
 
 \begin{tabular}{rrp{.6\textwidth}}
     \toprule

paper/intro.tex

@@ -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

@@ -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)$