\documentclass[12pt,english]{mrl}
\usepackage{graphicx}
\usepackage{listings}

\renewcommand{\familydefault}{\rmdefault}
\usepackage[T1]{fontenc}
\usepackage[latin9]{inputenc}
\usepackage{color}
\usepackage{babel}
\usepackage{verbatim}
\usepackage{float}
\usepackage{url}
\usepackage{amsthm}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage[unicode=true,pdfusetitle,
 bookmarks=true,bookmarksnumbered=false,bookmarksopen=false,
 breaklinks=false,pdfborder={0 0 1},backref=false,colorlinks=true]
 {hyperref}
\usepackage{breakurl}

\makeatletter


\makeatletter

\newcommand{\h}{\mathcal{H}}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% LyX specific LaTeX commands.
\floatstyle{ruled}
\newfloat{algorithm}{tbp}{loa}
\providecommand{\algorithmname}{Algorithm}
\floatname{algorithm}{\protect\algorithmname}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Textclass specific LaTeX commands.
\numberwithin{equation}{section}
\numberwithin{figure}{section}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% User specified LaTeX commands.
\usepackage{algpseudocode}

\makeatother

\begin{document}
\begin{frontmatter}

\begin{fmbox}
\hfill\setlength{\fboxrule}{0px}\setlength{\fboxsep}{5px}\fbox{\includegraphics[width=2in]{moneroLogo.png}}
\dochead{Research bulletin \hfill MRL-0003}
\title{Monero is Not That Mysterious}
\date{25 September 2014}
\author[
   addressref={mrl},
   email={lab@monero.cc}
]{\fnm{Shen} \snm{Noether}}


\address[id=mrl]{
  \orgname{Monero Research Lab}
}
\end{fmbox}



\end{frontmatter}

\section{Introduction}
Recently, there have been some vague fears about the CryptoNote
source code and protocol floating around the internet based on the
fact that it is a more complicated protocol than, for instance, Bitcoin.
The purpose of this note is to try and clear up some misconceptions,
and hopefully remove some of the mystery surrounding Monero Ring Signatures.
I will start by comparing the mathematics involved in CryptoNote
ring signatures (as described in \cite{CN}) to the mathematics in
\cite{FS}, on which CryptoNote is based. After this, I will compare
the mathematics of the ring signature to what is actually in the
CryptoNote codebase. 


\section{CryptoNote Origins}

As noted in (\cite{CN}, 4.1) by Saberhagen, group ring signatures have a history
starting as early as 1991 \cite{CH}, and various ring signature
schemes have been studied by a number of researchers throughout the
past two decades. As claimed in (\cite{CN} 4.1), the main ring signature
used in CryptoNote appears to be based on \cite{FS}, with some changes
to accomodate block-chain technology. 


\subsection{Traceable Ring Signatures}

In \cite{FS}, Fujisaki and Suzuki introduced a scheme for a ring
signature designed to ``leak secrets anonymously, without the risk
of identity escrow.'' This lack of a need for ``identity escrow,''
allows users of the ring signature to hide themselves in a group with
an inherently higher level of trustlessness compared to schemes relying
on a group manager.

In ring-signature schemes relying on a group manager, such as the
original ring signatures described in \cite{CH}, a designated trusted
person guards the secrets of the group participants. While anonymous,
such schemes rely, of course, on the manager not being compromised.
The result of having a group-manager, in terms of currencies, is essentially
the same as having a trusted organization or node to mix your coins.

In contrast, the traceable ring signature scheme given in \cite{FS}
has no group manager, and is thus inherently more trustless, but potentially
has other vulnerabilities which will be discussed, and which \cite{CN}
attempts to mitigate via blockchain technology. 

According to \cite{FS}, there are four formal security requirements
to their traceable ring signature scheme:
\begin{itemize}
\item Public Traceability - Anyone who creates two signatures for different
messages with respect to the same tag can be traced. (In CryptoNote,
if the user opts not to use a one-time key for each transaction, then
they will be traceable, however if they desire anonymity, then they
will use the one-time key. Thus as stated on page 5 of \cite{CN},
the traceability property is weakened in CryptoNote.) 
\item Tag-Linkability - Every two signatures generated by the same signer
with respect to the same tag are linked. (This aspect in CryptoNote
refers to each transaction having a key-image which
prevents double spending.) %


\item Anonymity - As long as a signer does not sign on two different messages
with respect to the same tag, the identity of the signer is indistinguishable
from any of the possible ring members. In addition, any two signatures
generated with respect to two distinct tags are always unlinkable.
(In terms of CryptoNote, if the signer attempts to use the same key-image
more than once, then they can be identified out of the group. The
unlinkability aspect is retained and is a key part of CryptoNote.)
\item Exculpability - An honest ring member cannot be accused of signing
twice with respect to the same tag. In other words, it should be infeasible
to counterfeit a tag corresponding to another person's secret key.
(In terms of CryptoNote, this says that key-images cannot be faked.)
\end{itemize}
In addition, \cite{FS} provide a ring signature protocol on page
10 of their paper, which is equivalent to the CryptoNote ring signature
algorithm, as described on page 9-10 of \cite{CN}. It is worthwhile
to note that \cite{FS} is a publicly peer-reviewed publication appearing
in Lecture Notes in Computer Science, as opposed to typical crypto-currency
protocol descriptions, where it is  unclear whether or not they have been reviewed or not. 


\subsection{Traceability vs CryptoNote}

In the original traceable ring signature algorithm described in \cite{FS},
it is possible to use the tag $L$ corresponding to a signature multiple
times. However, multiple uses of the tag allow the user to be traced;
in other words, the signer's index can be determined out of the group of users
signing. It is worthwhile to note that, due to the exculpability
feature of the protocol (\cite{FS} 5.6, \cite{CN}, A2), keys cannot
be stolen this way, unless an attacker is able to solve the Elliptic
Curve Discrete Logarithm Problem (ECDLP) upon which a large portion of modern
cryptography is based (\cite{Si} XI.4).

The process to trace a tag $L$ used more than once is described
on (\cite{FS}, page 10). In the CryptoNote protocol, however, key
images (tags) used more than once are rejected by the block-chain
as double-spends, and hence traceability is not an aspect of CryptoNote.


\subsection{Tag-Linkability vs CryptoNote}

In essence, the tag-linkability aspect of the traceable ring signature
protocol is what prevents CryptoNote transactions from being double-spends.
The relevant protocols are referred to as ``Trace'' in (\cite{FS},
5) and ``LNK'' in the CryptoNote paper. Essentially all that is
required is to be able to keep track of the key images which have
been used before, and to verify that a key image is not used again. 

If one key-image is detected on the block-chain before
another key-image, then the second key image is detected as a double-spend
transaction. As key-images cannot be forged, being exculpable, the
double-spender must in fact be the same person, and not another person
trying to steal a wallet. 


\section{One-Time Ring Signatures (mathematics)}

The security of the ring signature scheme as described in (\cite{FS}
10, \cite{CN} 10) and implemented in the CryptoNote source relies on the known
security properties of Curve25519. Note that this is the same curve
used in OpenSSH 6.5, Tor, Apple iOS, and many other%
\footnote{\url{http://ianix.com/pub/curve25519-deployment.html}%
} security systems.


\subsection{\label{sub:Twisted-Edwards-Curves}Twisted Edwards Curves}

The basic security in the CryptoNote Ring Signature algorithm is guaranteed
by the ECDLP (\cite{Si}, XI.4) on the Twisted Edwards curve ed25519.
The security properties of curve ed25519 are described in \cite{Bern},
by noted cryptographer Daniel Bernstein, and in (\cite{BCPM}) by
a team from Microsoft Research. Bernstein notes about ed25519 the ``every known
attack is more expensive than performing a brute-force search on a
typical 128-bit secret-key cipher.'' 

The curve ed25519 is a singular curve of genus $1$ with
a group law, and described by $-x^{2}+y^{2}=1+\left(\frac{-121665}{121666}\right)x^{2}y^{2}$.
This curve is considered over the finite field $\mathbb{F}_{q}$,
$q=2^{255}-19$. For those readers unfamiliar with algebraic geometry,
an algebraic curve is considered as a one dimensional sort of space, consisting
of all points $\left(x,y\right)$ satisfying the above equation. All
points are also considered modulo $q$. By virtue of its genus, ed25519
has a ``group structure'' which, for the purpose of this discussion, means if $P=\left(x_{1},y_{1}\right)$
is a point on the curve, and $Q=\left(x_{2},y_{2}\right)$ is another
point on the curve, then these points can be added (or subtracted) and the sum (or difference), $P+Q$ (or $P-Q$)
will also be on the curve. The addition is \textbf{not} the naive
adding of $x_{1}+x_{2}$ and $y_{1}+y_{2}$, but instead points are
added using the rule 
\[
P+Q=\left(\frac{x_{1}y_{2}+y_{1}x_{2}}{1+dx_{1}x_{2}y_{1}y_{2}},\frac{y_{1}y_{2}+x_{1}x_{2}}{1-dx_{1}x_{2}y_{1}y_{2}}\right)
\]
 where $d=\left(\frac{-121665}{121666}\right)$ (\cite{BBJLP} 6,
\cite{BCPM}). The mathematics of curves of genus one are explained
in great detail in \cite{Si} for the interested reader. 

Based on the above, we can compute $P+P$ for any
such point. In order to shorten notation, we rely on our algebraic intuition and denote $2P = P + P$.
If $n\in\mathbb{Z}$, then $nP$ denotes the repeated sum $$\underbrace{P+P+\cdots+P}_{n\ times}$$
using the above nonlinear addition law. As an example of how this
differs from ordinary addition, consider the following system of equations:
\begin{eqnarray*}
aP+bQ&=&X \\
aP^{\prime}+bQ^{\prime}&=&Y
\end{eqnarray*}
 where $a,b,c,d$ are integers and $P,Q,X$ are points. If this were a standard
 system of linear equations then one could use linear algebraic techniques
to easily solve for $a$ and $b$, assuming that $P,Q,X,Y,P^{\prime}$,
and $Q^{\prime}$ are known. However, even if $a,b$ are very small
the above system is extremely difficult to solve using the ed25519
addition law. For example, if $a=1$ and $b=1$, we have 
\begin{eqnarray*}
\left(\frac{x_{P}y_{Q}+y_{P}x_{Q}}{1+dx_{P}x_{Q}y_{P}y_{Q}},\frac{y_{P}y_{Q}+x_{P}x_{Q}}{1-dx_{P}x_{Q}y_{P}y_{Q}}\right)&=&\left(x_{X},y_{X}\right) \\
\left(\frac{x_{P^{\prime}}y_{Q^{\prime}}+y_{P^{\prime}}x_{Q^{\prime}}}{1+dx_{P^{\prime}}x_{Q^{\prime}}y_{P^{\prime}}y_{Q^{\prime}}},\frac{y_{P^{\prime}}y_{Q^{\prime}}+x_{P^{\prime}}x_{Q^{\prime}}}{1-dx_{P^{\prime}}x_{Q^{\prime}}y_{P^{\prime}}y_{Q^{\prime}}}\right)&=&\left(x_{Y},y_{Y}\right)
\end{eqnarray*}
 So in reality, this is a system of $4$ nonlinear equations. To convince
yourself that it is in fact difficult to figure out $a$ and $b$,
try writing the above systems assuming $a=2$, $b=1$. It should become
clear that the problem is extremely difficult when $a,b$ are chosen
to be very large. As of yet, there are no known methods available to
efficiently solve this system for large values of $a$ and $b$.

Consider the following problem. Suppose your friend has a random integer
$q$, and computes $qP$ using the above form of addition. Your friend
then tells you the $x$ and $y$ coordinates $qP=\left(x,y\right)$,
but not what $q$ itself is. Without asking, how do you find out what
$q$ is? $ $A naive approach might be to start with $P$ and keep
adding $P+P+P...$ until you reach $qP$ (which you will know because
you will end up at $\left(x,y\right)$). But if $q$ is very large
then this naive approach might take billions of years using modern
supercomputers. Based on what mathematicians currently know about
the problem and the number of possible $q$, none of the currently
known attacking techniques can, as a general rule, do better in any
practical sense than brute force.

In CryptoNote, your secret key is essentially just a very, very large
number $x$ (for other considerations, see section \ref{sub:generate_keys},
we choose $x$ to be a multiple of $8$). There is a special point
$G$ on the curve ed25519 called ``the base point'' of the curve
which is used as the starting point to get $xG$. Your public key is just $xG$, and you are protected by the above problem from someone using known information to determine the private key.


\subsection{\label{sub:Relation-to-Diffie}Relation to Diffie Helman}

Included in a ring signature are the following equations
involving your secret key $x$:

\begin{eqnarray*}
P&=&xG \\
I&=&x\mathcal{H}_{p}\left(P\right) \\
r_{s}&=&q_{s}-c_{s}x.
\end{eqnarray*}

Here $s$ is a number giving the index in the group signature to
your public key, and $\mathcal{H}_{p}\left(P\right)$ is a hash function which
deterministically takes the point $P$ to another point $P^{\prime}=x^{\prime}G$,
where $x^{\prime}$ is another very large uniformly chosen number.
The value $q_s$ is chosen uniformly at random, and $c_s$ is computed using
another equation involving random values.
The particular hash function used in CryptoNote is Keccak1600,
used in other applications such as SHA-3; it is currently considered
to be secure (\cite{FIPS}). 

The above equations can be written as follows:
\begin{eqnarray*}
P&=&xG \\
P^{\prime}&=&xx^{\prime}G^{\prime} \\
r_{s}&=&q_{s}-c_{s}x
\end{eqnarray*}

Solving the top two equations
is equivalent to the ECDH (as outlined in a previous note (\cite{SN}))
and is the same practical difficulty as the ECDLP.
Although the equations appear linear, they are in fact highly non-linear,
as they use the addition described in \ref{sub:Twisted-Edwards-Curves} and above.
The third equation (with unknowns $q_{s}$ and $x$), has the difficulty
of finding a random number (either $q_{s}$ or $x$) in $\mathbb{F}_{q}$,
a very large finite field; this is not feasible.
Note that as the third equation has two unknowns, combining
it with the previous two equations does not help; an attacker needs to
determine at least one of the random numbers $q_{s}$ or $x$. 


\subsection{\label{sub:Time-Cost-to}Time Cost to Guess q or x }

Since $q$ and $x$ are assumed to be random very large numbers in
$\mathbb{F}_{q}$ , with $q=2^{255}-19$ (generated as 32-byte
integers), this is equivalent to a 128-bit security level (\cite{BCPM}),
which is known to take billions of years to compute with current supercomputers. 


\subsection{Review of Proofs in Appendix}

In the CryptoNote appendix, there are four proofs of the four basic
properties required for security of the one-time ring-signature scheme:
\begin{itemize}
\item Linkability (protection against double-spending)
\item Exculpability (protection of your secret key)
\item Unforgeability (protection against forged ring signatures)
\item Anonymity (Ability to hide a transaction within other transactions)
\end{itemize}
These theorems are essentially identical to those in \cite{FS} and show that
the ring signature protocol satisfies the above traits. The first
theorem shows that only the secret keys corresponding
to the public keys included in a group can produce a signature for
that group. This relies on the ECDLP for the solution of two simultaneous
(non-linear) elliptic curve equations, which, as explained in \ref{sub:Relation-to-Diffie},
is practically unsolvable. The second theorem uses the same reasoning,
but shows that in order to create a fake signature that passes verification, 
one would need to be able to solve the ECDLP. The third and fourth theorems 
are taken directly from \cite{FS}.

\section{One-Time Ring Signatures (Application)}

To understand how CryptoNote is implementing the One-Time Ring signatures,
I built a model in Python of Crypto-ops.cpp and Crypto.cpp from the Monero source
code using naive Twisted Edwards Curve operations (taken
from code by Bernstein), rather than the apparently reasonably optimized
operations existing in the CryptoNote code. Functions
are explained in the code comments below. Using the model will produce
a working ring signature that differs slightly from the Monero ring
signatures only because of hashing and packing differences between
the used libraries. The full code is hosted at the following address: 
\begin{center}
\url{https://github.com/ShenNoether/MiniNero/blob/master/MiniNero.py}
\end{center}
Note that most of the important helper functions in crypto-ops.cpp in the CryptoNote source
are pulled from the reference implementation of Curve25519. This reference
implentation was coded by Matthew Dempsky (Mochi Media, now Google)%
\footnote{\url{http://nacl.cr.yp.to/}%
}. 

In addition, after comparing the python code to the paper, and in
turn comparing the python code to the actual Monero source, it is
fairly easy to see that functions like \texttt{generate\_ring\_sig} are
all doing what they are supposed to based on the protocol described
in the whitepaper. For example, here is the ring signature generation algorithm
used in the CryptoNote source:

\begin{algorithm}[H]
\caption{Ring Signatures}


\begin{algorithmic} 
\State $i\gets 0$
\While {$i<numkeys$}       
	\If {$i= s$}
		\State $k \gets random\ \mathbb{F}_q\  element$       
		\State $L_i \gets k \cdot G$
		\State $R_i \gets k\cdot \mathcal{H}_p(P_i)$
	\Else
		\State $k1 \gets random\ \mathbb{F}_q\  element$
		\State $k2 \gets random\ \mathbb{F}_q\  element$
		\State $L_i\gets k_1 P_i + k_2  G$
		\State $R_i\gets k_1 I+k_2 \mathcal{H}_p(P_i)$
		\State $c_i \gets k_1$
		\State $r_i \gets k_2$
	\EndIf 
	\State $i \gets i+1$
\EndWhile
\State $h \gets \mathcal{H}_s(prefix+L_i's+R_i's))$
\State $c_{s} \gets h-\sum_{i\neq s} c_i$
\State $r_s \gets k - x c_s$
\State \Return $(I, \{c_{i}\}, \{r_i\})$
\end{algorithmic} 
\end{algorithm}


Comparing this with \cite{CN} shows that it agrees with the whitepaper.
Similarly, here is the algorithm used in the CryptoNote source
to verify ring signatures:

\begin{algorithm}[H]
\caption{VER}


\begin{algorithmic} 
\State $i=0$
\While {$i<numkeys$}      
	\State $L_i^{\prime}\gets c_i P_i + r_i  G$
	\State $R_i^{\prime}\gets r_i \mathcal{H}_p(P_i)+c_i I$
	\State $i \gets i+1$
\EndWhile
\State $h \gets \mathcal{H}_s(prefix+L_i's+R_i's))$
\State $h \gets h-\sum_{i\neq s} c_i$
 \State \Return $(h == 0 (mod\ q)) == 0$
\end{algorithmic} 
\end{algorithm}



\subsection{Important Crypto-ops Functions}

Descriptions of important functions in Crypto-ops.cpp. Even more references
and information is given in the comments in the MiniNero.py code linked
above. 


\subsubsection{ge\_frombytes\_vartime}

Takes as input some data and converts to a point on ed25519. For a
reference of the equation used, $\beta=uv^{3}\left(uv^{7}\right)^{\left(q-5\right)/8}$,
see (\cite{BBJLP}, section 5).


\subsubsection{ge\_fromfe\_frombytesvartime}

Similar to the above, but compressed in another form. 


\subsubsection{ge\_double\_scalarmult\_base\_vartime}

Takes as inputs two integers $a$ and $b$ and a point $A$ on ed25519
and returns the point $aA+bG$, where $G$ is the ed25519 base point.
Used for the ring signatures when computing, for example, $ $$L_{i}$
with $i\neq s$ as in (\cite{CN}, 4.4)


\subsubsection{ge\_double\_scalarmult\_vartime}

Takes as inputs two integers $a$ and $b$ and two points $A$ and $B$ on ed25519
and outputs $aA+bB$. Used, for example, when computing the $R_{i}$
in the ring signatures with $i\neq s$ (\cite{CN}, 4.4)


\subsubsection{ge\_scalarmult}

Given a point $A$ on ed25519 and an integer $a$, this computes
the point $aA$. Used for example when computing $L_{i}$ and $R_{i}$
when $i=s$. 


\subsubsection{ge\_scalarmult\_base}

Takes as input an integer $a$ and computes $aG$, where $G$ is the
ed25519 base point. 


\subsubsection{ge\_p1p1\_to\_p2}

There are different representations of curve points for ed25519, this
converts between them. See MiniNero for more reference. 


\subsubsection{ge\_p2\_dbl}

This takes a point in the ``p2'' representation and doubles it.


\subsubsection{ge\_p3\_to\_p2}

Takes a point in the ``p3'' representation on ed25519 and turns
it into a point in the ``p2'' representation. 


\subsubsection{ge\_mul8}

This takes a point $A$ on ed25519 and returns $8A$. 


\subsubsection{sc\_reduce}

Takes a 64-byte integer and outputs the lowest 32 bytes modulo the
prime $q$. This is not a CryptoNote-specific function, but comes
from the standard ed25519 library. 


\subsubsection{sc\_reduce32}

Takes a 32-byte integer and outputs the integer modulo $q$. Same
code as above, except skipping the 64$\to$32 byte step. 


\subsubsection{sc\_mulsub}

Takes three integers $a,b,c$ in $\mathbb{F}_{q}$ and returns $c-ab$
modulo $q$. 


\subsection{Important Hashing Functions}


\subsubsection{cn\_fast\_hash}

Takes data and returns the Keccak1600 hash of the data. 


\subsection{Crypto.cpp Functions }


\subsubsection{random\_scalar}

Generates a 64-byte integer and then reduces it to a 32 byte integer
modulo $q$ for 128-bit security as described in section \ref{sub:Time-Cost-to}. 


\subsubsection{hash\_to\_scalar}

Inputs data (for example, a point $P$ on ed25519) and outputs $\mathcal{H}_{s}\left(P\right)$,
which is the Keccak1600 hash of the data. The function then converts
the hashed data to a 32-byte integer modulo $q$. 


\subsubsection{\label{sub:generate_keys}generate\_keys}

Returns a secret key and public key pair, using \texttt{random\_scalar} (as
described above) to get the secret key. Note that, as described in
\cite{Bern}, the key set for ed25519 actually is only multiples of
$8$ in $\mathbb{F}_{q}$, and hence \texttt{ge\_scalarmult\_base} includes
a \texttt{ge\_mul8} to ensure the secret key is in the key set. This prevents 
transaction malleability attacks as described in (\cite{Bern},
{\it c.f.} section on ``small subgroup attacks''). This is part of the
\textbf{GEN} algorithm as described in (\cite{CN}, 4.4).


\subsubsection{check\_key}

Inputs a public key and outputs if the point is on the curve.


\subsubsection{secret\_key\_to\_public\_key}

Inputs a secret key, checks it for some uniformity conditions, and
outputs the corresponding public key, which is essentially just $8$
times the base point times the point. 


\subsubsection{hash\_to\_ec}

Inputs a key, hashes it, and then does the equivalent in bitwise operations
of multiplying the resulting integer by the base point and then by $8$. 


\subsubsection{generate\_key\_image}

Takes as input a secret key $x$ and public key $P$, and returns
$I=x\mathcal{H}_{p}\left(P\right)$, the key image. This is part of
the \textbf{GEN} algorithm as described in (\cite{CN}, 4.4).


\subsubsection{generate\_ring\_signature}

Computes a ring signature, performing \textbf{SIG} as in (\cite{CN},
4.4) given a key image $I$, a list of $n$ public keys $P_{i}$,
and a secret index. Essentially there is a loop on $i$, and if the
secret-index is reached, then an if-statement controls the special
computation of $L_{i},R_{i}$ when $i$ is equal to the secret index.
The values $c_{i}$ and $r_{i}$ for the signature are computed throughout
the loop and returned along with the image to create the total signature
$\left(I,c_{1},...,c_{n},r_{1},...,r_{n}\right).$ 


\subsubsection{check\_ring\_signature}

Runs the \textbf{VER} algorithm in (\cite{CN}, 4.4). The verifier
uses a given ring signature to compute $L_{i}^{\prime}=r_{i}G_{i}$,
$R_{i}^{\prime}=r_{i}\mathcal{H}_{p}\left(P_{i}\right)+c_{i}I$, and
finally to check if $\sum_{i=0}^{n}c_{i}=\mathcal{H}_{s}\left(m,L_{0}^{\prime},...,L_{n}^{\prime},R_{0}^{\prime},...,R_{n}^{\prime}\right)\ mod\ l$. 


\subsubsection{generate\_key\_derivation}

Takes a secret key $b$, and a public key $P$, and outputs $8\cdot bP$.
(The $8$ being for the purpose of the secret key set, as described
in \ref{sub:generate_keys}). This is used in derive\_public\_key
as part of creating one-time addresses. 


\subsubsection{derivation\_to\_scalar}

Performs $\mathcal{H}_{s}\left(-\right)$ as part of generating keys in
(\cite{CN}, 4.3, 4.4). It hashes an output index together with the
point. 


\subsubsection{derive\_public\_key}

Takes a derivation $rA$ (computed via \texttt{generate\_key\_derivation}),
a point $B$, and an output index, computes a scalar via \texttt{derivation\_to\_scalar},
and then computes $\mathcal{H}_{s}\left(rA\right)+B$. 


\subsubsection{generate\_signature}

This takes a prefix, a public key, and a secret key, and generates
a standard (not ring) transaction signature (similar to a Bitcoin
transaction signature). 


\subsubsection{check\_signature}

This checks if a standard (not ring) signature is a valid signature. 

\section{Conclusion}
Despite the ring signature functions in the original CryptoNote source being poorly commented, the code can be traced back to established and used sources, and is relatively straightfoward. The Python implementation provided with this review gives further indication of the code's correctness. Furthermore, the elliptic curve mathematics underlying the ring signature scheme has been extremely-well studied; the concept of ring signatures is not novel, even if their application to cryptocurrencies is.

\medskip{}

\begin{thebibliography}{BBJLP}
\bibitem[BBJLP]{BBJLP} Bernstein, Daniel J., et al. "Twisted
edwards curves." Progress in Cryptology\textendash{}AFRICACRYPT
2008. Springer Berlin Heidelberg, 2008. 389-405.

\bibitem[BCPM]{BCPM} Bos, Joppe W., et al. "Selecting
Elliptic Curves for Cryptography: An Efficiency and Security Analysis."
IACR Cryptology ePrint Archive 2014 (2014): 130.

\bibitem[Bern]{Bern} Bernstein, Daniel J. "Curve25519:
new Diffie-Hellman speed records." Public Key Cryptography-PKC
2006. Springer Berlin Heidelberg, 2006. 207-228.

\bibitem[CH]{CH} Chaum, David, and Eugene Van Heyst. "Group
signatures." Advances in Cryptology\textemdash{}EUROCRYPT\textquoteright{}91.
Springer Berlin Heidelberg, 1991.

\bibitem[CN]{CN} van Saberhagen, Nicolas. "CryptoNote
v 2.0." (2013).

\bibitem[FIPS]{FIPS} SHA, NIST DRAFT. "standard: Permutation-based
hash and extendable-output functions." DRAFT FIPS 202
(2014).

\bibitem[Fu]{Fu} Fujisaki, Eiichiro. "Sub-linear size
traceable ring signatures without random oracles." IEICE
TRANSACTIONS on Fundamentals of Electronics, Communications and Computer
Sciences 95.1 (2012): 151-166.

\bibitem[FS]{FS} Fujisaki, Eiichiro, and Koutarou Suzuki. "Traceable
ring signature." Public Key Cryptography\textendash{}PKC
2007. Springer Berlin Heidelberg, 2007. 181-200.

\bibitem[IAN]{IAN} IANIX http://ianix.com/pub/curve25519-deployment.html

\bibitem[Si]{Si} Silverman, Joseph H. The arithmetic of elliptic
curves. Vol. 106. Dordrecht: Springer, 2009.

\bibitem[SN]{SN} http://lab.monero.cc/pubs/multiple\_equations\_attack.pdf\end{thebibliography}
\end{document}
