@@ -70,11 +70,19 @@ Such a paper is difficult to write. The authors have visibly devoted great effor

\item The paper takes us from one technical point to another in a manner that seems arbitrary at times, and hinders the overall structure. The problem is quite global, but a typical example is Definition 2.3: as a non-expert, it is hard to understand why this notion is important to introduce here, and it is essentially not used anywhere in the paper.

\end{itemize}

\begin{answer}

Computations over Curve25519 are done in $\F{p}$, as a result an easy mistake is to assume the curve defined over $\F{p}$ for all $x \in\F{p}$. However Curve25519 is defined over the quadratic extension which makes the Curve25519 over $\F{p}$ and its quadratic twist isomorphic over $\F{p^2}$ (Definition 2.3).

The notion of the twist of Curve25519 is quite central in the proof of the second main theorem of our paper,

which is linking our formalization of the RFC to the mathematical definition of Curve25519.

We therefore feel like it should not be omitted from the preliminaries, but we are of course

open to suggestions how to motivate the definition better at this early point of the paper.

\end{answer}

\begin{itemize}

\item Figure 1 and Figure 4 are great, and have the potential to help so much the reader against the previous issue. Unfortunately, they are not commenting, and hence fail to do so!

\end{itemize}

\begin{answer}

We extended the discussion of Figures 1, 3, and 4 to address this point.

\end{answer}

\begin{itemize}

\item The protocol considered is standard, and its implementation made to be of reasonable complexity. The paper should therefore really aim to:

\begin{enumerate}

\item promote a new approach (full stack, use of VST, use of the B\&S elliptic curve library,...)

...

...

@@ -85,6 +93,10 @@ Such a paper is difficult to write. The authors have visibly devoted great effor

The paper does a good job at 1, but unfortunately a quite poor at 2 and 3.

\item Skimming through the development convinces me that this is a consequent work. But the paper does not help evaluating this effort. It is always difficult to find relevant metrics to evaluate such things, but it would be great to get a sense of the aspects of the work that turned out difficult, and the extent of these difficulties.

\end{itemize}

\begin{answer}

\todo{We should say something regarding these two points.}

\end{answer}

\begin{center}

\subheading{===== Detailed comments for authors =====}

...

...

@@ -101,6 +113,11 @@ On a side note, I failed to compile the project: setting up an opam switch with

- coq-verif-tweetnacl $\rightarrow$ coq-stdpp \\

unknown package\\

No solution found, exiting"}}

\begin{answer}

We were not able to reproduce this error, but

now make the code available in an anonymous GitHub repository that also contains

a virtual-machine image with all software that is required to reproduce the proofs.

\end{answer}

Here are a few linear comments:

...

...

@@ -109,6 +126,12 @@ Here are a few linear comments:

- "the program satisfy" $\rightarrow$ "the program satisfies"\\

- "the result of this paper can readily be used in mechanized proofs of higher-level protocols (...)"

This statement should probably be made more precise, it is quite unclear to me what you mean exactly.

\end{itemize}

\begin{answer}

Typo fixed (the satisfy/satisfies actually refers to the semantics of a program in this sentence).

We rephrased the second statement to (hopefully) clarify what we mean.

\end{answer}

\begin{itemize}

\item\textbf{page 2:}\\

Figure 1 is great, but would deserve a lengthy explanation!

...

...

@@ -123,27 +146,49 @@ Here are a few linear comments:

Definition 2.3: It's been very unclear to me as a non-expert in cryptography and this protocole in particular what was the purpose of this definition.\\

Clarified that $m$ is an upper bound on the bitlength of the scalar. Typo fixed.

\end{answer}

\begin{itemize}

\item\textbf{page 4, column 2:}\\

It's minor, but it is more shiny nowadays to cite The Odd Order theorem that the Four Color theorem as a mathematical achievement in Coq\\

CompCert $\rightarrow$ Wrong hyphenation\\

Hoare-seq $\rightarrow$ It is clearly hard to find the balance with respect to what should be assumed on the crypto side, and what should be assumed on the verification side. I nonetheless think that this should be omitted.\\

"Separation logic is an extension of Hoare logic" $\rightarrow$ Minor, but the work "extension" does not quite sit right with me. The model is quite intrinsically different.

\end{itemize}

\begin{answer}

\todo{Fix, comment here.}

\end{answer}

\begin{itemize}

\item\textbf{page 5, column 2:}\\

"'To implement (...)" $\rightarrow$ I am very confused by this. The whole paragraph is an unannounced quote, it would need context/explanation.

\end{itemize}

\begin{answer}

\todo{Fix, comment here.}

\end{answer}

\begin{itemize}

\item\textbf{page 6, column 1:}\\

In ListofZn\_fp $\rightarrow$ The use of fuel might deserve a comment. Don't you end up having to prove at some point that you can always compute ahead of time an overapproximation of the fuel needed? Wouldn't it have been simple to use the strong recursion principle of naturals to define the function?

\end{itemize}

\begin{answer}

In our case the fuel is used to garantee to have as an output a list of 32 elements. This allows to prove that for all List of 32 bytes, ListofZn\_fp (ZofList L) = L. With this lemma at hand we can later simplify some of the expressions.

\end{answer}

\begin{itemize}

\item\textbf{page 6, column 2:}\\

"and the same code as a pure Coq function" $\rightarrow$ I would rephrase, the term "same code" is misleading.

Specification: I think explaining the structure of a VST statement would be necessary to help an unfamiliar reader understand this specification.

...

...

@@ -160,12 +205,22 @@ Here are a few linear comments:

Figure 3: Please comment generously this figure, it looks great but it is frustrating to try to decipher it without help.

\item\textbf{page 9:}\\

{\color{gray}"the type of field which characteristic" $\rightarrow$ "whose characteristic"\\

"The value of add is proven to be on the curve (with coercion)" $\rightarrow$ This parenthesis is too cryptic, it should probably be dropped.}

"the type of field which characteristic" $\rightarrow$ "whose characteristic"\\

"The value of add is proven to be on the curve (with coercion)" $\rightarrow$ This parenthesis is too cryptic, it should probably be dropped.

\end{itemize}

\begin{answer}

Fixed.

\end{answer}

\begin{itemize}

\item\textbf{page 11:}\\

Figure 4: this one is the apex: it would deserve a full column of explanations

\end{itemize}

\begin{answer}

\todo{How much explanation did we actually add here?}

\end{answer}

\begin{itemize}

\item\textbf{Conclusion:}\\

Great wrap up overall.\\

CompCert: "However, when compiling (...)" $\rightarrow$ I am quite confused about this sentence. Do you mean when compiling the verified C code with gcc? If so, beyond the question whether CompCert matches C17 (which it doesn't, it matches C99), the real problem is to assume that gcc is bug free! I would expect with this whole approach that the expectation is to run a protocole compiled with CompCert.\\

...

...

@@ -221,7 +276,7 @@ Here are a few linear comments:

\begin{answer}

For the X25519 implementation in TweetNaCl, CompCert generates code that is

about 6x slower than code generated with gcc. While this sounds like a lot, it

about 6$\times$ slower than code generated with gcc. While this sounds like a lot, it

may not be too much of an issue for projects that use TweetNaCl, because they

chose for a library that prioritizes simplicity over performance in the first

place. A more serious issue however can be the non-free CompCert license.