slides

1 files changed, 81 insertions, 30 deletions

diff --git a/presentation/slides.tex b/presentation/slides.tex
index 367d929..59e86b3 100644
--- a/presentation/slides.tex
+++ b/presentation/slides.tex
@@ -89,12 +89,6 @@
 \begin{document}
 
 
-
-%\begin{frame}
-%\frametitle{Overview} % Table of contents slide, comment this block out to remove it
-%\tableofcontents % Throughout your presentation, if you choose to use \section{} and \subsection{} commands, these will automatically be printed on this slide as an overview of your presentation
-%\end{frame}
-
 \titlegraphic{%
  \includegraphics[width=2.5cm]{pics/logo-inria.png}\hspace*{2cm}~%
  \includegraphics[width=1cm]{pics/logo-bretagne.png}\hspace*{2cm}~%
@@ -512,30 +506,80 @@ $\Rightarrow$ Naive refresh protocol enables tax evasion
   But of course we use modern instantiations.
 \end{frame}
 
-\begin{frame}{Refresh Protocol}
+%\begin{frame}{Refresh Protocol (Simplified Sketch)}
+%  Cut-and-choose to ensure linkability!
+%  \begin{itemize}
+%    \item Customer has old coin with key $(c_0, C_0)$
+%    \item Customer generates $\kappa$ (usually $\kappa=3$) transfer key pairs $(t_i, T_i)$,
+%    \item Customer derives $\kappa$ candidates (coin key pair,
+%      blinding factor, signing request) from \textbf{ECDH between old coin and
+%      transfer key}
+%    \item Customer sends transfer public keys and commitments to the $\kappa$ candidates to the exchange
+%    \item Exchange marks $C_0$ as spent and asks customer to reveal all candidates except $\gamma$-th
+%    \item Customer reveals all candidates except the $\gamma$-th, reveals blinded coin for $\gamma$-th candidate
+%    \item Exchange checks if commitments match revealed values (knowing the
+%      transfer secret key), i.e. if the new coin's private key could be derived
+%      knowing $T_i$ and $c_0$ (as $\textrm{ECDH}(t_i, C_0) = \textrm{ECDH}(c_0, T_i)$).
+%    \item If a commitment does not match, refreshing denied, no new attempts allowed.
+%    \item If commitments were correct, exchange signs blinded coin
+%  \end{itemize}
+%\end{frame}
+
+\begin{frame}{Refresh Protocol (Simplified Sketch)}
+  Expected result:
   \begin{itemize}
-    \item Use key exchange 
+    \item Every successful refresh results in a \emph{transfer public key}
+    \item Given the old coin's public key, the exchanges provides the transfer public key and blinded
+      signature on new coin.
+    \item Diffie-Hellman exchange between transfer public key and coin secret key gives seed
+      for deriving the new coin's blinding factor and secret key
+    \item \emph{Catch:} How can the exchange know that the transfer public key is correct?
   \end{itemize}
 \end{frame}
 
-%----------------------------
 
-\subsection{Implementation}
+\begin{frame}{Refresh Protocol (Simplified Sketch)}
+  Answer:  Cut-and-choose
+  \begin{itemize}
+    \item Naive refresh is run with multiple ($\kappa$, typically 3) instances in parallel, thus there are $\kappa$ candidates
+      for the new coin
+    \item At most one instance will result in a signature
+    \item At the beginning, customer makes a hiding+binding commitment to private values (priv. key / blinding factor)
+    \item For $\kappa - 1$ other instances, private values must be revealed, checked by exchange and thrown away
+    \item Diffie-Hellman exchange ($DH(a, B) = DH(b, A)$) allows us to check that commitment is correct
+      by revealing transfer key, but \emph{not} the old coin's secret key.
+    \item With probability $1/\kappa$, adversary can sneak in wrong transfer public key.
+    \item If cheating is attempted, with probability $1-1/\kappa$ the coin will be ``seized'' by the exchange.
+    \item $\Rightarrow$ Cheating not profitable
+  \end{itemize}
+\end{frame}
 
 %----------------------------
 
-\begin{frame}
-\frametitle{Implementation Overview}
-\end{frame}
-
 %----------------------------
 
 \begin{frame}
-\frametitle{Full Architecture}
+\frametitle{Real-World Deployment: Architecture}
 \includegraphics[width=\textwidth]{pics/taler-arch-full.pdf}
 \end{frame}
 
 \begin{frame}
+\frametitle{Implementation Overview}
+  \begin{itemize}
+    \item Implemented in multiple components:
+    \begin{itemize}
+      \item Exchange
+      \item Auditor
+      \item Merchant backend
+      \item Merchant frontends (donations, blog, survey, backoffice, codeless payments)
+      \item Browser Wallet (WebExtension)
+    \end{itemize}
+    \item Communication through HTTP/JSON protocol.
+    \item Plugin architecture for different wire methods
+  \end{itemize}
+\end{frame}
+
+\begin{frame}
 \frametitle{Entities / PKI}
 \includegraphics[width=\textwidth]{pics/taler-diagram-signatures.png}
 \end{frame}
@@ -562,20 +606,15 @@ $\Rightarrow$ Naive refresh protocol enables tax evasion
 
 %----------------------------
 
-\begin{frame}
-\frametitle{Practical Points}
-% mention code-less payments
-Separation between merchant front-end and backend
-
-Different register-layers (SEPA / Blockchain / taler-test) can be used.  Architecture is plugin-based.
-
-Additional features (tipping, ...)
-\end{frame}
-
-%----------------------------
-
 \begin{frame}{Web Integration}
-  payto://
+  payto:// URIs
+  \begin{itemize}
+    \item Well known: \url{mail:dold@taler.net?subject=hello} describes a mail address with
+      some additional info for sending the mail
+    \item Payto does the same for bank accounts / bitcoin wallets / ... ($=$ payment targets)
+    \item Used by Taler internally, as well as externally to prompt sending money to the exchange
+    \item Currently trying to find the right WG / AD at the IETF to make it a standard
+  \end{itemize}
 \end{frame}
 
 %----------------------------
@@ -584,8 +623,12 @@ Additional features (tipping, ...)
 \frametitle{Alternatives?}
 W3C Web Payments?  No, only concerned with showing payment request in browser UI.
 
+\vfill
+
 Proprietary Systems?
 
+\vfill
+
 Blockchain?
 
 \end{frame}
@@ -682,8 +725,6 @@ No considerations of practical compromise.
 
 \section{Byzantine Set Consensus}
 
-\frame{\tableofcontents[currentsection]}
-
 \begin{frame}
   \frametitle{Byzantine Consensus}
 \end{frame}
@@ -732,6 +773,16 @@ No considerations of practical compromise.
 
 \begin{frame}
 \frametitle{Publications}
+\vfill
+Dold, F. and Grothoff, C., 2017. Byzantine set-union consensus using efficient
+set reconciliation. EURASIP Journal on Information Security, 2017(1), p.14.
+\vfill
+Burdges, J., Dold, F., Grothoff, C. and Stanisci, M., 2016, December. Enabling Secure Web Payments with GNU Taler. In International Conference on Security, Privacy, and Applied Cryptography Engineering (pp. 251-270). Springer, Cham.
+\vfill
+Dold, Florian, and Christian Grothoff. "GNU Taler: Ethical online payments for the internet age." ERCIM NEWS 106 (2016): 12-13.
+\vfill
+Burdges, J., Dold, F., Grothoff, C. and Stanisci, M., 2016, June. Taler: Usable, privacy-preserving payments for the Web. In HotPETS 2016-Workshop on Hot Topics in Privacy Enhancing Technologies.
+\vfill
 \end{frame}
 
 %------------------------------------------------