Reviewer interest & 2.& I might go to a talk about this \\

Reviewer expertise & 3.& Knowledgeable \\

Review recommendation & 3.& Major revision \\

Writing quality & 3.& Adequate \\

Reviewer interest & 2.& I might go to a talk about this \\

Reviewer expertise & 3.& Knowledgeable \\

\bottomrule

\end{tabular}

...

...

@@ -128,8 +128,10 @@ Here are a few linear comments:

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.

\begin{itemize}

\item[$-$] Typo fixed (the satisfy/satisfies actually refers to the semantics of a program in this sentence).

\item[$-$]We rephrased the second statement to (hopefully) clarify what we mean.

\end{itemize}

\end{answer}

\begin{itemize}

...

...

@@ -148,8 +150,11 @@ Here are a few linear comments:

"depending of the value of the kth bit" $\rightarrow$ unclear what k is at this point

\end{itemize}

\begin{answer}

Regarding Definition 2.3 see our answer above. Typo fixed.

We updated the text to clarify what we mean by the $k$th bit.

\begin{itemize}

\item[$-$] Regarding Definition 2.3 see our answer above.

\item[$-$] Typo fixed.

\item[$-$] We updated the text to clarify what we mean by the $k$th bit.

\end{itemize}

\end{answer}

\begin{itemize}

...

...

@@ -170,11 +175,12 @@ Here are a few linear comments:

\end{itemize}

\begin{answer}

\begin{itemize}

\item\todo{address other comments}

\item The paper introducing separation logic describes it as \emph{``an extension of Hoare logic''}.

See \url{https://www.cs.cmu.edu/~jcr/seplogic.pdf}.

\item\todo{address other comments}

\item[$-$] While the Odd Order theorem is shinier for the complexity of the work, it may not be as well known as the Four Color theorem. This lack of exposition makes its proof less impressive to readers not familiar with the subject.

\item[$-$] We fixed the hyphenation.

\item[$-$] The Hoare logic is not a known subject for most cryptographers not familiar with formal methods. In our opinion, the Hoare-Sec rule is the easiest rule with material (as opposed to Hoare-Skip) to understand by its composition nature and as it also relates to how instructions are read in the source code of a program.

\item[$-$] The Separation Logic was introduced by their authors \emph{``an extension of Hoare logic''}. See See \url{https://www.cs.cmu.edu/~jcr/seplogic.pdf}.

\end{itemize}

\end{answer}

\begin{itemize}

...

...

@@ -182,16 +188,16 @@ Here are a few linear comments:

"'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.}

Fixed, we added an introduction sentence.

\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{answer}

In our case the fuel is used to garantee to have as an output a list of 32 elements. This allows us 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:}\\

...

...

@@ -199,7 +205,8 @@ Here are a few linear comments:

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

\end{itemize}

\begin{answer}

\todo{Answer}

We rephrased this paragraph to avoid misleading the reader on the translations done.\\

\todo{add some more text before "In this specification we state preconditions like:" ?}

\end{answer}

\begin{itemize}

...

...

@@ -207,11 +214,16 @@ Here are a few linear comments:

Discussion on memory aliasing is great, I would have liked more of this kind through the paper.\\

Figure 2: I had to fish back a little for the definition of "sh", but "Ews" has really never been defined I believe.\\

"Improving speed" $\rightarrow$ of what? This whole paragraph is quite hard to read. In particular be careful that it is not obvious to the reader whether you are speeding up the verification process or the runtime of the implementation. In particular it was unclear to me what you were referring to by saying "Optimizations of such definitions".\\

The following paragraph also is a bit cryptic. I assume you are saying that identifying finely the dependencies between definitions allow for parallelizing the work? Arguably, simply admitting temporarily yon the fly any specification needed achieves the same.\\

The following paragraph also is a bit cryptic. I assume you are saying that identifying finely the dependencies between definitions allow for parallelizing the work? Arguably, simply admitting temporarily on the fly any specification needed achieves the same.\\

"Numbers in gf" $\rightarrow$ Please remind the reader what "gf" is. Good section overall

\end{itemize}

\begin{answer}

\todo{Answer}

\begin{itemize}

\item[$-$] We added a description of "Ews" in the precondition paragraph, this should clarify the global memory share name.

\item[$-$] We clarified that we improve the speed of the verification effort. ``Optimization of such definition'' refers to the will of some developers to use for example a fancy recursive definition of a function.

\item[$-$] In order to verify a file, Coq need the compiled proof of dependencies. However in the case of VST it is possible to split the specification from the proof, as a result the proof of the full scalar multiplication does not require the proof of the the multiplication in \F{p}, only its specification.

\item[$-$] We reminded the reader that "gf" is a C type.

\end{itemize}

\end{answer}

\begin{itemize}

...

...

@@ -220,7 +232,10 @@ 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.

\end{itemize}

\begin{answer}

\todo{Answer}

\begin{itemize}

\item[$-$] We removed the reflection mention, more explanations would require too many implementation details.

\item[$-$] We added a paragraph to describe the content of Figure 3.

\end{itemize}

\end{answer}

\begin{itemize}

...

...

@@ -237,7 +252,8 @@ Here are a few linear comments:

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?}

In addition to Figure 4, we added a full paragraph providing the red line of the proof of this theorem.

We hope to provide suficiant insights of the dependencies between lemmas to arrive into the final theorem.

\end{answer}

\begin{itemize}

...

...

@@ -259,7 +275,7 @@ Here are a few linear comments:

\item Please provide high level explanations to your three Figures describing the infrastructure.

\end{itemize}

\begin{answer}

\todo{We added such high-level descriptions.}

We added high-level description of Figures 1, 3 and 4. They should help the reader to follow the line of the proof.

\end{answer}

\begin{itemize}

\item Please reduce slightly the width of the technical material covered, and use the gained space to provide a bit more context to the one covered