summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorChristian Grothoff <christian@grothoff.org>2021-05-18 17:00:53 +0200
committerChristian Grothoff <christian@grothoff.org>2021-05-18 17:00:53 +0200
commit75804f8bceb7249f7b6b1c7248f7f90e721d1c57 (patch)
treef30590667356fc557478b404ff45111b862f8fb4
parent4f75848465f6dd94d1dd9dc31b307bf9f98e2ce9 (diff)
downloadmarketing-75804f8bceb7249f7b6b1c7248f7f90e721d1c57.tar.gz
marketing-75804f8bceb7249f7b6b1c7248f7f90e721d1c57.tar.bz2
marketing-75804f8bceb7249f7b6b1c7248f7f90e721d1c57.zip
NYC update
-rw-r--r--presentations/comprehensive/nyc.tex201
1 files changed, 89 insertions, 112 deletions
diff --git a/presentations/comprehensive/nyc.tex b/presentations/comprehensive/nyc.tex
index 3f671f0..6a36176 100644
--- a/presentations/comprehensive/nyc.tex
+++ b/presentations/comprehensive/nyc.tex
@@ -612,12 +612,6 @@ But of course we use modern instantiations.
\end{minipage}
\end{frame}
-\begin{frame}{Withdrawing coins on the Web}
- \begin{center}
- \includegraphics[height=0.9\textheight]{figs/taler-withdraw.pdf}
- \end{center}
-\end{frame}
-
\begin{frame}{Customer: Build shopping cart}
\begin{center}
@@ -654,18 +648,6 @@ But of course we use modern instantiations.
\end{frame}
-\begin{frame}{Merchant Integration: Contract}
- % \begin{figure*}[t!]
- {\tiny
- \lstset{language=JavaScript}
- \lstinputlisting{figs/taler-contract.json}
-% \caption{Minimal Taler contract over a digital article with a value of \EUR{0.10}. The merchant will pay transaction fees up to \EUR{0.01}. The hash over the wire transfer information was truncated to make it fit to the page.}
-% \label{listing:json-contract}
- % \end{figure*}
- }
-\end{frame}
-
-
\begin{frame}{Merchant: Propose contract (EdDSA)}
\begin{minipage}{6cm}
\begin{enumerate}
@@ -762,13 +744,6 @@ But of course we use modern instantiations.
\end{frame}
-\begin{frame}{Payment processing with Taler}
- \begin{center}
- \includegraphics[height=0.9\textheight]{figs/taler-pay.pdf}
- \end{center}
-\end{frame}
-
-
\begin{frame}{Giving change}
It would be inefficient to pay EUR 100 with 1 cent coins!
\begin{itemize}
@@ -1173,93 +1148,6 @@ But of course we use modern instantiations.
-\begin{frame}{Warranting deposit safety}
- Exchange has {\em another} online signing key $W = wG$:
- \begin{center}
- Sends $EdDSA_w(M,H(D),FDH(C))$ to the merchant.
- \end{center}
- This signature means that $M$ was the {\em first} to deposit
- $C$ and that the exchange thus must pay $M$.
- \vfill
- \begin{center}
- Without this, an evil exchange could renege on the deposit
- confirmation and claim double-spending if a coin were
- deposited twice, and then not pay either merchant!
- \end{center}
-\end{frame}
-
-
-\begin{frame}{Online keys}
-\begin{itemize}
-\item The exchange needs $d$ and $w$ to be available for online signing.
-\item The corresponding public keys $W$ and $(e,n)$ are certified using
- Taler's public key infrastructure (which uses offline-only keys).
-\end{itemize}
-\begin{center}
-\includegraphics[width=0.5\textwidth]{taler-diagram-signatures.png}
-\end{center}
-\vfill
-\begin{center}
-{\bf What happens if those private keys are compromised?}
-\end{center}
-\vfill
-\end{frame}
-
-
-\begin{frame}{Denomination key $(e,n)$ compromise}
-\begin{itemize}
-\item An attacker who learns $d$ can sign an arbitrary number of illicit coins
- into existence and deposit them.
-\item Auditor and exchange can detect this once the total number of deposits
- (illicit and legitimate) exceeds the number of legitimate coins the
- exchange created.
-\item At this point, $(e,n)$ is {\em revoked}. Users of {\em unspent}
- legitimate coins reveal $b$ from their withdrawal operation and
- obtain a {\em refund}.
-\item The financial loss of the exchange is {\em bounded} by the number of
- legitimate coins signed with $d$.
-\item[$\Rightarrow$] Taler frequently rotates denomination signing keys and
- deletes $d$ after the signing period of the respective key expires.
-\end{itemize}
-\begin{center}
-\includegraphics[width=0.5\textwidth]{taler-diagram-denom-expiration.png}
-\end{center}
-\end{frame}
-
-
-\begin{frame}{Online signing key $W$ compromise}
-\begin{itemize}
-\item An attacker who learns $w$ can sign deposit confirmations.
-\item Attacker sets up two (or more) merchants and customer(s) which double-spend
- legitimate coins at both merchants.
-\item The merchants only deposit each coin once at the exchange and get paid once.
-\item The attacker then uses $w$ to fake deposit confirmations for the double-spent
- transactions.
-\item The attacker uses the faked deposit confirmations to complain to the auditor
- that the exchange did not honor the (faked) deposit confirmations.
-\end{itemize}
-The auditor can then detect the double-spending, but cannot tell who is to blame,
-and (likely) would presume an evil exchange, forcing it to pay both merchants.
-\end{frame}
-
-
-\begin{frame}{Detecting online signing key $W$ compromise}
-\begin{itemize}
-\item Merchants are required to {\em probabilistically} report
- signed deposit confirmations to the auditor.
-\item Auditor can thus detect exchanges not reporting signed
- deposit confirmations.
-\item[$\Rightarrow$] Exchange can rekey if illicit key use is detected,
- then only has to honor deposit confirmations it already provided
- to the auditor {\em and} those without proof of double-spending
- {\em and} those merchants reported to the auditor.
-\item[$\Rightarrow$] Merchants that do not participate in reporting
- to the auditor risk their deposit permissions being voided in
- cases of an exchange's private key being compromised.
-\end{itemize}
-\end{frame}
-
-
\section{Competitor analysis}
@@ -1749,6 +1637,95 @@ General notions:
+\begin{frame}{Warranting deposit safety}
+ Exchange has {\em another} online signing key $W = wG$:
+ \begin{center}
+ Sends $EdDSA_w(M,H(D),FDH(C))$ to the merchant.
+ \end{center}
+ This signature means that $M$ was the {\em first} to deposit
+ $C$ and that the exchange thus must pay $M$.
+ \vfill
+ \begin{center}
+ Without this, an evil exchange could renege on the deposit
+ confirmation and claim double-spending if a coin were
+ deposited twice, and then not pay either merchant!
+ \end{center}
+\end{frame}
+
+
+\begin{frame}{Online keys}
+\begin{itemize}
+\item The exchange needs $d$ and $w$ to be available for online signing.
+\item The corresponding public keys $W$ and $(e,n)$ are certified using
+ Taler's public key infrastructure (which uses offline-only keys).
+\end{itemize}
+\begin{center}
+\includegraphics[width=0.5\textwidth]{taler-diagram-signatures.png}
+\end{center}
+\vfill
+\begin{center}
+{\bf What happens if those private keys are compromised?}
+\end{center}
+\vfill
+\end{frame}
+
+
+\begin{frame}{Denomination key $(e,n)$ compromise}
+\begin{itemize}
+\item An attacker who learns $d$ can sign an arbitrary number of illicit coins
+ into existence and deposit them.
+\item Auditor and exchange can detect this once the total number of deposits
+ (illicit and legitimate) exceeds the number of legitimate coins the
+ exchange created.
+\item At this point, $(e,n)$ is {\em revoked}. Users of {\em unspent}
+ legitimate coins reveal $b$ from their withdrawal operation and
+ obtain a {\em refund}.
+\item The financial loss of the exchange is {\em bounded} by the number of
+ legitimate coins signed with $d$.
+\item[$\Rightarrow$] Taler frequently rotates denomination signing keys and
+ deletes $d$ after the signing period of the respective key expires.
+\end{itemize}
+\begin{center}
+\includegraphics[width=0.5\textwidth]{taler-diagram-denom-expiration.png}
+\end{center}
+\end{frame}
+
+
+\begin{frame}{Online signing key $W$ compromise}
+\begin{itemize}
+\item An attacker who learns $w$ can sign deposit confirmations.
+\item Attacker sets up two (or more) merchants and customer(s) which double-spend
+ legitimate coins at both merchants.
+\item The merchants only deposit each coin once at the exchange and get paid once.
+\item The attacker then uses $w$ to fake deposit confirmations for the double-spent
+ transactions.
+\item The attacker uses the faked deposit confirmations to complain to the auditor
+ that the exchange did not honor the (faked) deposit confirmations.
+\end{itemize}
+The auditor can then detect the double-spending, but cannot tell who is to blame,
+and (likely) would presume an evil exchange, forcing it to pay both merchants.
+\end{frame}
+
+
+\begin{frame}{Detecting online signing key $W$ compromise}
+\begin{itemize}
+\item Merchants are required to {\em probabilistically} report
+ signed deposit confirmations to the auditor.
+\item Auditor can thus detect exchanges not reporting signed
+ deposit confirmations.
+\item[$\Rightarrow$] Exchange can rekey if illicit key use is detected,
+ then only has to honor deposit confirmations it already provided
+ to the auditor {\em and} those without proof of double-spending
+ {\em and} those merchants reported to the auditor.
+\item[$\Rightarrow$] Merchants that do not participate in reporting
+ to the auditor risk their deposit permissions being voided in
+ cases of an exchange's private key being compromised.
+\end{itemize}
+\end{frame}
+
+
+
+
\end{document}