diff options
Diffstat (limited to 'presentation/slides.tex')
-rw-r--r-- | presentation/slides.tex | 111 |
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} %------------------------------------------------ |