Commit 374f9d0d authored by Benoit Viguier's avatar Benoit Viguier
Browse files

more text + make spell

parent 0c99e7b1
\todo{
- Get down to 12 pages: "no more than 12 pages long, excluding the bibliography,
well-marked appendices, and supplementary material."
- Emphasize:\\
+ the added confidence between in X25519 Correctness\\
+ proof of real world software\\
}
With respect to the reviews:
\todo{
- Give number of person-hours
- "This did not become very clear, because you mostly describe names
of tool while leaving out the details of what these tools carry out
conceptually."\\
+ anotation have to be carried out through the proof to help the smt-solver,
not in our case as we direct the proof.
- "In particular,
the Figure seems to used a nice abstraction of properties that is not
used elsewhere in the paper. I.e., elsewhere in the paper, there is
usually a lot of code details."\\
+ I don't know what to do on that one.
- "I was wondering whether you consider the approach in [13] as synthesis or
verification, because to me, it seemed a mix/neither."\\
+ [13] is "Verified Low-Level Programming Embedded in F*",\\
+ reread [13] and answer in the "our answer part"
- "[18] even uses Coq to verify a large portion of a C implementation of X25519
fully automatically."\\
+ This is not verification, this is synthesis. The approach is completely different.
- "Still, TweetNaCl is not necessarily the most complex (and certainly not the most
efficient) implementation of X25519 that has been verified, which makes the
novelty of this work hard to justify."\\
+ True, but all the other works have been from a spec and generate correct code
approach, here we go the opposite way. While the code of other libraries are
different, the montgomery ladder are often similar and the optimizations comes
mostly from the big number computations.\\
- "This is a well-known problem for formal
verification papers, and I don’t have great advice except to suggest
that the authors separate out the code fragments into figures and
let the text focus on the high-level ideas of the code."\\
+ @PETER: How to address that ?
- "At the end of Section IV, I would have loved to see some high-
level lessons on what the proof taught you, and what part of this
proof would be reusable if you decided to verify Ed25519 or X448
or P-256, for example."\\
+ see second Todo
- "It also appears that the authors do not verify the constant-time
guarantees of the TweetNaCl code. Could this be done in their
framework?"
+ Nope => mention in limitation at the end of the paper?
- Clamping and section V.\\
+ The clamping allows to reduce the group to prime elements, we do not provide
such proofs.\\
- We prove that for all n the computations on the ladder holds.
- "More importantly, could you claim that your proof of equivalence also provides
a justification for the implementations of Fiat Crypto or HACL*, hence adding
value to those other projects in addition to your own?"
+ Peter ?
}
% \todo{
%
% - Get down to 12 pages: "no more than 12 pages long, excluding the bibliography,
% well-marked appendices, and supplementary material."
%
% - Emphasize:\\
% + the added confidence between in X25519 Correctness\\
% + proof of real world software\\
% }
%
% With respect to the reviews:
%
% \todo{
%
% - Give number of person-hours
%
% - "This did not become very clear, because you mostly describe names
% of tool while leaving out the details of what these tools carry out
% conceptually."\\
% + anotation have to be carried out through the proof to help the smt-solver,
% not in our case as we direct the proof.
%
% - "I was wondering whether you consider the approach in [13] as synthesis or
% verification, because to me, it seemed a mix/neither."\\
% + [13] is "Verified Low-Level Programming Embedded in F*",\\
% + reread [13] and answer in the "our answer part"
%
% - "[18] even uses Coq to verify a large portion of a C implementation of X25519
% fully automatically."\\
% + This is not verification, this is synthesis. The approach is completely different.
%
% - "Still, TweetNaCl is not necessarily the most complex (and certainly not the most
% efficient) implementation of X25519 that has been verified, which makes the
% novelty of this work hard to justify."\\
% + True, but all the other works have been from a spec and generate correct code
% approach, here we go the opposite way. While the code of other libraries are
% different, the montgomery ladder are often similar and the optimizations comes
% mostly from the big number computations.\\
%
% - "This is a well-known problem for formal
% verification papers, and I don’t have great advice except to suggest
% that the authors separate out the code fragments into figures and
% let the text focus on the high-level ideas of the code."\\
% + @PETER: How to address that ?
%
% - "At the end of Section IV, I would have loved to see some high-
% level lessons on what the proof taught you, and what part of this
% proof would be reusable if you decided to verify Ed25519 or X448
% or P-256, for example."\\
% + see second Todo
%
% - "It also appears that the authors do not verify the constant-time
% guarantees of the TweetNaCl code. Could this be done in their
% framework?"
% + Nope => mention in limitation at the end of the paper?
%
% - Clamping and section V.\\
% + The clamping allows to reduce the group to prime elements, we do not provide
% such proofs.\\
% - We prove that for all n the computations on the ladder holds.
%
% - "More importantly, could you claim that your proof of equivalence also provides
% a justification for the implementations of Fiat Crypto or HACL*, hence adding
% value to those other projects in addition to your own?"
% + Peter ?
% }
......@@ -113,7 +113,10 @@ proof techniques used to show the correctness with respect to RFC~7748~\cite{rfc
and Strub and the correctness of X25519 implementation with respect to Bernstein's
specifications~\cite{Ber14}.
Finally in \sref{sec:Conclusion} we discuss the trusted code base of our proofs.
\fref{tikz:ProofOverview} shows a graph of dependencies of the proofs.
C source files are represented by {\color{doc@lstfunctions}.C} while
{\color{doc@lstfunctions}.V} corresponds to Coq files.
\begin{figure}[h]
\centering
......@@ -122,9 +125,6 @@ Finally in \sref{sec:Conclusion} we discuss the trusted code base of our proofs.
\label{tikz:ProofOverview}
\end{figure}
\todoln{NEW}
In this figure, {\color{doc@lstfunctions}.V} represent Coq files.
% Five years ago:
% \url{https://www.imperialviolet.org/2014/09/11/moveprovers.html}
% \url{https://www.imperialviolet.org/2014/09/07/provers.html}
......
......@@ -94,8 +94,6 @@ Then we describe our mapping between little-endian representations and integers
(\ref{subsec:integer-bytes}) which we use to formalize the encoding and decoding.
% subsection or subheading ?
\subsection{A generic ladder}
\label{subsec:spec-ladder}
......@@ -108,11 +106,6 @@ used in the ladder over generic types \coqe{T} and \coqe{T'}.
Those types are later instantiated as list of integers, integers, natural
numbers, or field elements.
% The generic definition of the ladder (\coqe{montgomery_rec}) and its parallel with
% the definition of RFC~7748 are provided in Appendix~\ref{subsubsec:coq-ladder}.
\todo{Do we keep the pointer to \sref{cswap} for CSWAP?}
Our formalization differs slightly from the RFC. Indeed in order to optimize the
number of calls to \texttt{CSWAP} (defined in \sref{cswap})
the RFC uses an additional variable to decide
......@@ -199,5 +192,5 @@ Definition encodeUCoordinate (x: Z) : list Z :=
ListofZ32 8 x.
\end{lstlisting}
In this definition, \coqe{clamp} is taking care of setting and unsetting the
In this definition, \coqe{clamp} is taking care of setting and clearing the
selected bits as stated in the RFC and described in~\sref{subsec:X25519-key-exchange}.
......@@ -110,7 +110,6 @@ The correctness of this specification is formally proven in Coq with
% For the sake of completeness we proved all intermediate functions.
\subheading{Memory aliasing.}
%
The semicolon in the \VSTe{SEP} parts of the Hoare triples represents the \emph{separating conjunction} (often written as a star), which means that
the memory shares of \texttt{q}, \texttt{n} and \texttt{p} do not overlap.
In other words,
......@@ -130,7 +129,6 @@ Examples of such cases are illustrated in \fref{tikz:MemSame}.
\caption{Aliasing and Separation Logic}%
\label{tikz:MemSame}%
\end{figure}
As a result, a function must either have multiple specifications or specify which
aliasing case is being used.
The first option would require us to do very similar proofs multiple times for a same function.
......@@ -145,3 +143,16 @@ we define an additional parameter $k$ with values in $\{0,1,2,3\}$:
In the proof of our specification, we do a case analysis over $k$ when needed.
This solution does not generate all the possible cases of aliasing over 3 pointers
(\eg \texttt{o} = \texttt{a} = \texttt{b}) but it is enough to cover our needs.
\subheading{Improving speed.}
To make the verification the smoothest, the Coq formal definition of the function
should be as close as possible to the C implementation behavior.
Optimizations of such definitions are often counter-productive as they increase the
amount of proofs required for \eg bounds checking, loops invariants\ldots.
In order to further speed-up the verification process, to prove the specification
\TNaCle{crypto_scalarmult}, we only need the specification of the subsequently
called functions (\eg \TNaCle{M}).
This provide with multiple advantages: the verification by the Coq kernel can be
done in parallel and multiple users can work on proving different functions at
the same time. For the sake of completeness we proved all intermediate functions.
\subsection{Number representation and C implementation}
\label{subsec:num-repr-rfc}
\todo{Do we completely rewrite this section?}
As described in \sref{subsec:Number-TweetNaCl}, numbers in \TNaCle{gf} are represented
in base $2^{16}$ and we use a direct mapping to represent that array as a list
integers in Coq. However, in order to show the correctness of the basic operations,
......
......@@ -16,7 +16,7 @@ Corollary Inv25519_Zpow_GF : forall (g:list Z),
By using each function \coqe{Low.M}; \coqe{Low.A}; \coqe{Low.Sq}; \coqe{Low.Zub};
\coqe{Unpack25519}; \coqe{clamp}; \coqe{Pack25519}; \coqe{Inv25519}; \coqe{car25519};
\coqe{montgomery_rec}, we defined in Coq \coqe{Crypto_Scalarmult} and with VST
proved it mimicks the exact behavior of X25519 in TweetNaCl.
proved it mimics the exact behavior of X25519 in TweetNaCl.
\end{sloppypar}
\begin{sloppypar}
......
\subsection{Advices to future VST users}
......@@ -32,8 +32,7 @@ We discuss the plot twist (\ref{subsec:Zmodp}) of Curve25519 and solve it (\ref{
\subsection{Formalization of elliptic Curves}
\label{subsec:ECC}
\todo{Beter here of after the final theorem of the subsection?}
\fref{tikz:ProofHighLevel1} presents a intuition of the proof.
\begin{figure}[h]
\centering
\include{tikz/highlevel1}
......@@ -41,7 +40,6 @@ We discuss the plot twist (\ref{subsec:Zmodp}) of Curve25519 and solve it (\ref{
\label{tikz:ProofHighLevel1}
\end{figure}
We consider elliptic curves over a field $\K$. We assume that the
characteristic of $\K$ is neither 2 or 3.
......@@ -322,16 +320,15 @@ Theorem opt_montgomery_ok (n m: nat) (x : K) :
\subsection{Curves, twists and extension fields}
\todo{Beter here of after the final theorem of the subsection?}
\fref{tikz:ProofHighLevel2} gives a high-level view of the proofs presented here.
\begin{figure}[h]
\centering
\include{tikz/highlevel2}
\caption{Instanciations and proof dependencies for the correctness of X25519}
\caption{Instantiation and proof dependencies for the correctness of X25519}
\label{tikz:ProofHighLevel2}
\end{figure}
To be able to use the above theorem we need to satisfy hypothesis
\ref{hyp:a_minus_4_not_square}: $a^2-4$ is not a square in \K:
$$\forall x \in \K,\ x^2 \neq a^2-4.$$
......@@ -392,14 +389,12 @@ We instantiate \coqe{opt_montgomery} in two specific ways:\\
With \tref{thm:montgomery-ladder-correct} we derive the following two lemmas:
\begin{lemma}
For all $x \in \F{p},\ n \in \N,\ P \in \F{p} \times \F{p}$,\\
such that $P \in M_{486662,1}(\F{p})$ and $\chi_0(P) = x$.\\
% Given $n$ and $x$,
such that $P \in M_{486662,1}(\F{p})$ and $\chi_0(P) = x$.
$$Curve25519\_Fp(n,x) = \chi_0(n \cdot P)$$
\end{lemma}
\begin{lemma}
For all $x \in \F{p},\ n \in \N,\ P \in \F{p} \times \F{p}$\\
such that $P \in M_{486662,2}(\F{p})$ and $\chi_0(P) = x$.\\
% Given $n$ and $x$,
such that $P \in M_{486662,2}(\F{p})$ and $\chi_0(P) = x$.
$$Twist25519\_Fp(n,x) = \chi_0(n \cdot P)$$
\end{lemma}
As the Montgomery ladder does not depend on $b$, it is trivial to
......@@ -505,9 +500,6 @@ of formulas by using rewrite rules:
\end{split}
\end{equation*}
The injection $a \mapsto (a,0)$ from $\F{p}$ to $\F{p^2}$ preserves
$0, 1, +, -, \times$. Thus $(a,0)$ can be abbreviated as $a$ without confusions.
......
......@@ -52,8 +52,6 @@ o[i] = aux1 + aux2;
done with this architecture \cite{2015-Appel,coq-faq}.
\end{itemize}
\todo{NEW}
\subheading{Corrections in TweetNaCl.}
As a result of this verification, we removed superfluous code.
Indeed indexes 17 to 79 of the \TNaCle{i64 x[80]} intermediate variable of
......@@ -73,20 +71,18 @@ and thus solved this problem.
o[i]&=0xffff;
\end{lstlisting}
\todo{NEW}
Aside from the modications above mentionned, all subsequent alteration
Aside from the modifications above mentioned, all subsequent alteration
---such as the type change of loop indexes (\TNaCle{int} instead of \TNaCle{i64})---
were required for VST to parse properly the code. We believe those
adjustments do not impact the trust of our proof.
We contacted the authors of TweetNaCl and expect that the changes above
mentionned will soon be integrated in a new version of the library.
mentioned will soon be integrated in a new version of the library.
\subheading{Extending our work.}
The high-level definition (\sref{sec:maths}) can easily be ported to any
other Montgomery curves and with it the proof of the ladder's correctness
assuming the same forumlas are used.
assuming the same formulas are used.
In addition to the curve equation, the field \F{p} would need to be redefined
as $p=2^{255}-19$ is hard-coded in order to speed up some proofs.
......@@ -97,7 +93,7 @@ level verification similar to \tref{thm:montgomery-ladder-correct}.
The verification \eg X448~\cite{cryptoeprint:2015:625,rfc7748} in C would
require the adaptation of most of the low level arithmetic (mainly the
multiplication, carry propagations and reductions).
multiplication, carry propagation and reductions).
Once the correctness and bounds of the basic operations are established,
reproving the full ladder would make use of our generic definition and lower
the workload.
......
\newpage
\section{Prior reviews}
\label{appendix:past-reviews}
......@@ -90,8 +91,9 @@ It lies in the assurance gained by the formalization of the X25519 from RFC~7748
and its correctness with respect to the theory of elliptic curves.
It is the first time, we have a link from the C code up to the mathematical
definitions of Curve25519.
We removed the description of how verification of for loops are handled and the
details of the proof by reflections.
While they are part of the main proof but not novel techniques we removed the
description of how verification of for loops are handled and the details of the
proof by reflections.
We described in the Conclusion (\sref{sec:Conclusion}) how our results can be
extended or reused in future works.
......@@ -130,11 +132,11 @@ the body on conceptual insights (see comments below).
\end{center}
I was confused that you did not seem have found any errors in an implementation.
I can believe that the implementers of [2] are proficient implementers, but I
would have expected some minor bugs/parsing issues to be found anyway. What is
your explanation that you haven't found any issues?
I can believe that the implementers of \cite{BGJ+15} are proficient implementers,
but I would have expected some minor bugs/parsing issues to be found anyway.
What is your explanation that you haven't found any issues?
p.1: You discuss [10] as using heavy annotation of code, differently from your
p.1: You discuss \cite{Ber06} as using heavy annotation of code, differently from your
own code. However, as far as I understand, your Coq implementation must also be
type-annotated. Thus, I imagine that the difference lies in whether SAT-solvers
are used or not? This did not become very clear, because you mostly describe
......@@ -178,11 +180,12 @@ interesting if the paper highlights the interesting aspects of the verification.
Related work:
In reference [13], the order of authors is different than in the original
publication. I think that you might want to discuss [13] in the Related work
In reference \cite{DBLP:journals/corr/BhargavanDFHPRR17}, the order of authors
is different than in the original publication. I think that you might want to
discuss \cite{DBLP:journals/corr/BhargavanDFHPRR17} in the Related work
section, since it seems quite close. I was wondering whether you consider the
approach in [13] as synthesis or verification, because to me, it seemed a
mix/neither.
approach in \cite{DBLP:journals/corr/BhargavanDFHPRR17} as synthesis or
verification, because to me, it seemed a mix/neither.
Clarification in intro:
......@@ -197,10 +200,8 @@ whether this is careful quantification or not.
Clarification in intro: VST has already been used to verify symmetric Cryptographic
primities, as mentioned later by \cite{Beringer2015VerifiedCA} and \cite{2015-Appel}.
We have not found errors in the implementation but we removed an
undefined behavior by the C standard.
\todo{Can I say that?}
Compilers were smart enough to prevent problems in that instance.
We have not found errors in the implementation but we removed an undefined
behavior by the C standard.
......@@ -233,9 +234,9 @@ that uses X25519 is provably secure, based on some cryptographic assumption on
the ECDH construction. It is rare to find papers that combine more than one of
these proof levels, and this paper does a creditable job of linking (a) with (b),
relying on the Coq framework to soundly glue these proofs together. Although a
similar goal was considered in [12], this paper provides a more satisfying
solution by not leaving any gaps between the formalizations, and by relying on a
smaller trusted computing base.
similar goal was considered in \cite{Zinzindohoue2016AVE}, this paper provides
a more satisfying solution by not leaving any gaps between the formalizations,
and by relying on a smaller trusted computing base.
\begin{center}
......@@ -243,12 +244,13 @@ smaller trusted computing base.
\end{center}
X25519 implementations have now been verifying in multiple papers using multiple
verification frameworks, and [18] even uses Coq to verify a large portion of a C
implementation of X25519 fully automatically. So, the main contribution here is
that that the authors verify an existing popular implementation (TweetNaCl)
without making many changes to the source code. Still, TweetNaCl is not necessarily
the most complex (and certainly not the most efficient) implementation of X25519
that has been verified, which makes the novelty of this work hard to justify.
verification frameworks, and \cite{Erbsen2016SystematicSO} even uses Coq to
verify a large portion of a C implementation of X25519 fully automatically.
So, the main contribution here is that that the authors verify an existing
popular implementation (TweetNaCl) without making many changes to the source
code. Still, TweetNaCl is not necessarily the most complex (and certainly not
the most efficient) implementation of X25519 that has been verified, which
makes the novelty of this work hard to justify.
\begin{center}
......
......@@ -100,11 +100,11 @@
\texttt{clamp} & \texttt{Low/Prep\_n.v} & Clamping \\
\texttt{Unpack25519} & \texttt{Low/Unpack25519.v} & unpacking (mod $2^{255}$)\\
\hline
\multicolumn{3}{c}{Instanciations of \texttt{Ops}}\\
\multicolumn{3}{c}{Instantiation of \texttt{Ops}}\\
\hline
\texttt{Z25519\_Ops} & \texttt{Mid/Instances.v} & Instanciations over \F{p} with $p = \p$\\
\texttt{Z\_Ops} & \texttt{Mid/Instances.v} & Instanciations over $\Zfield$ \\
\texttt{List\_Z\_Ops} & \texttt{Mid/Instances.v} & Instanciations lists of \Z \\
\texttt{Z25519\_Ops} & \texttt{Mid/Instances.v} & Instantiation over \F{p} with $p = \p$\\
\texttt{Z\_Ops} & \texttt{Mid/Instances.v} & Instantiation over $\Zfield$ \\
\texttt{List\_Z\_Ops} & \texttt{Mid/Instances.v} & Instantiation lists of \Z \\
\hline
\multicolumn{3}{c}{X25519 over \Z and list of \Z}\\
\hline
......
......@@ -20,14 +20,14 @@
% M is a finite assoc group
\begin{scope}[yshift=0 cm,xshift=3 cm]
\draw [fill=green!20] (0,0) -- (3.25,0) -- (3.25,-0.75) -- (0, -0.75) -- cycle;
\draw (1.675,-0.375) node[textstyle, anchor=center] {$M_{a,b}(\K)$ is an Assoc. Fin. Grp};
\draw (1.675,-0.375) node[textstyle, anchor=center] {$M_{a,b}(\K)$ is an Assoc. Fin. Grp.};
\end{scope}
% Hypothesis x square is not 2
\begin{scope}[yshift=-1.5 cm,xshift=0 cm]
\draw [fill=orange!20] (0,0) -- (1.5,0) -- (1.5,-1.25) -- (0, -1.25) -- cycle;
\draw (0,0) node[textstyle, anchor=north west] {\textbf{Hyp:}};
\draw (0.75,-0.375) node[textstyle, anchor=north] {$\forall x \in \K,$\\$x^2 \neq 2$};
\draw (0.75,-0.375) node[textstyle, anchor=north] {$\forall x \in \K,$\\$x^2 \neq a^2-4$};
\end{scope}
% Final theorem
......
......@@ -13,25 +13,31 @@
\end{scope}
\begin{scope}[yshift=-1 cm,xshift=1.5 cm]
\draw[fill=green!20] (0,0) -- (1.25,0) -- (1.25,-0.75) -- (0, -0.75) -- cycle;
\draw (0.615,-0.375) node[textstyle, anchor=center] {$\forall x \in \F{p},$\\$x^2 \neq 2$};
\end{scope}
\begin{scope}[yshift=-1 cm,xshift=2.875 cm]
\draw[fill=green!20] (0,0) -- (1.5,0) -- (1.5,-0.75) -- (0, -0.75) -- cycle;
\draw (0.75,-0.375) node[textstyle, anchor=center] {$\forall x \in \F{p},$\\$x^2 \neq 2$};
\draw (0.75,-0.375) node[textstyle, anchor=center] {$\forall x \in \F{p},$\\$x^2 \neq a^2-4$};
\end{scope}
\begin{scope}[yshift=-1 cm,xshift=4 cm]
\draw[fill=white] (0,0) -- (1.5,0) -- (1.5,-0.75) -- (0, -0.75) -- cycle;
\draw (0.75,-0.375) node[textstyle, anchor=center] {$C(\F{p})$};
\begin{scope}[yshift=-1 cm,xshift=4.5 cm]
\draw[fill=white] (0,0) -- (1,0) -- (1,-0.75) -- (0, -0.75) -- cycle;
\draw (0.5,-0.375) node[textstyle, anchor=center] {$C(\F{p})$};
\end{scope}
\begin{scope}[yshift=-1 cm,xshift=6 cm]
\draw[fill=white] (0,0) -- (1.5,0) -- (1.5,-0.75) -- (0, -0.75) -- cycle;
\draw (0.75,-0.375) node[textstyle, anchor=center] {$T(\F{p})$};
\begin{scope}[yshift=-1 cm,xshift=6.5 cm]
\draw[fill=white] (0,0) -- (1,0) -- (1,-0.75) -- (0, -0.75) -- cycle;
\draw (0.5,-0.375) node[textstyle, anchor=center] {$T(\F{p})$};
\end{scope}
\path [thick, double, ->] (0.25,0.75) edge [out=-90, in=90] (0.25,0);
\path [thick, double] (1,-0.375) edge [out=0, in=180] (6.75,-0.375);
\path [thick, double, ->] (2.25,-0.375) edge [out=-90, in=90] (2.25,-1);
\path [thick, double, ->] (4.75,-0.375) edge [out=-90, in=90] (4.75,-1);
\path [thick, double, ->] (6.75,-0.375) edge [out=-90, in=90] (6.75,-1);
\path [thick, double] (1,-0.375) edge [out=0, in=180] (7,-0.375);
\path [thick, double, ->] (2.125,-0.375) edge [out=-90, in=90] (2.125,-1);
\path [thick, double, ->] (3.625,-0.375) edge [out=-90, in=90] (3.625,-1);
\path [thick, double, ->] (5,-0.375) edge [out=-90, in=90] (5,-1);
\path [thick, double, ->] (7,-0.375) edge [out=-90, in=90] (7,-1);
\begin{scope}[yshift=-2.5 cm,xshift=1.5 cm]
......@@ -39,20 +45,21 @@
\draw (0.75,0) node[textstyle, anchor=north] {$\forall x \in \F{p},$\\$\exists P \in C(\F{p}),$\\$\exists Q \in T(\F{p})$,\\$x = \chi(P)\vee x = \chi(Q)$};
\end{scope}
\begin{scope}[yshift=-2.5 cm,xshift=4 cm]
\begin{scope}[yshift=-2.5 cm,xshift=4.25 cm]
\draw[fill=green!20] (-0.20,0) -- (1.70,0) -- (1.70,-1.25) -- (-0.20, -1.25) -- cycle;
\draw (0.75,0) node[textstyle, anchor=north] {$\forall x \in \F{p},$\\$\forall P \in C(\F{p}),$\\$x = \chi(P)\implies$\\lad. $n$ $x = \chi(n \cdot P)$};
\end{scope}
\begin{scope}[yshift=-2.5 cm,xshift=6 cm]
\begin{scope}[yshift=-2.5 cm,xshift=6.25 cm]
\draw[fill=green!20] (-0.20,0) -- (1.70,0) -- (1.70,-1.25) -- (-0.20, -1.25) -- cycle;
\draw (0.75,0) node[textstyle, anchor=north] {$\forall x \in \F{p},$\\$\forall Q \in T(\F{p}),$\\$x = \chi(Q)\implies$\\lad. $n$ $x = \chi(n \cdot Q)$};
\end{scope}
\path [thick, double] (2.25,-2.125) edge [out=0, in=180] (6.75,-2.125);
\path [thick, double, ->] (2.25,-1.75) edge [out=-90, in=90] (2.25,-2.5);
\path [thick, double, ->] (4.75,-1.75) edge [out=-90, in=90] (4.75,-2.5);
\path [thick, double, ->] (6.75,-1.75) edge [out=-90, in=90] (6.75,-2.5);
\path [thick, double, ->] (2.125,-1.75) edge [out=-90, in=90] (2.125,-2.5);
\path [thick, double] (2.125,-2.125) edge [out=0, in=180] (7,-2.125);
\path [thick, double] (3.625,-1.75) edge [out=-90, in=90] (3.625,-2.125);
\path [thick, double, ->] (5,-1.75) edge [out=-90, in=90] (5,-2.5);
\path [thick, double, ->] (7,-1.75) edge [out=-90, in=90] (7,-2.5);
% F(p^2)
......
......@@ -103,5 +103,6 @@
\path [thick, double, ->] (3, -7.75) edge [out=0, in=-180] (6, -7.75);
\path [thick, double, ->] (1.75,-8) edge [out=0, in=-180] (6, -8);
\draw (4.5,-0.75) node[textstyle, anchor=south] {clightgen};
\end{tikzpicture}
Supports Markdown
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