summaryrefslogtreecommitdiff
path: root/conclusions.tex
diff options
context:
space:
mode:
authorFlorian Dold <florian.dold@gmail.com>2018-09-05 01:00:44 +0200
committerFlorian Dold <florian.dold@gmail.com>2018-09-05 01:00:44 +0200
commit980bdb7e2f6032cbaf22d3115eeca5a7b85c7e9f (patch)
treec715c8c6b3ab2fe9c6fb021aafc241fdf5789671 /conclusions.tex
parent9ea34dafb52a346272e8cb2900a7d2d8430140f4 (diff)
downloaddold-thesis-phd-980bdb7e2f6032cbaf22d3115eeca5a7b85c7e9f.tar.gz
dold-thesis-phd-980bdb7e2f6032cbaf22d3115eeca5a7b85c7e9f.tar.bz2
dold-thesis-phd-980bdb7e2f6032cbaf22d3115eeca5a7b85c7e9f.zip
sync
Diffstat (limited to 'conclusions.tex')
-rw-r--r--conclusions.tex105
1 files changed, 77 insertions, 28 deletions
diff --git a/conclusions.tex b/conclusions.tex
index 7ae9d1e..aaf506c 100644
--- a/conclusions.tex
+++ b/conclusions.tex
@@ -1,37 +1,86 @@
\chapter{Future Work}\label{chapter:future-work}
-\subsection*{Post-Quantum security}
-
-\subsection*{Standard Model}
-
-\subsection*{Applications to GNUnet / incentives}
-
-\subsection*{gnunet-blockchain / deployment of the full stack payment system}
-=> no, talk more about integration with real banks, KYC
-
-\subsection*{P2P payments}
-
-\subsection*{NFC Wallet}
+We now discuss future work that builds upon the results presented so far.
-\subsection*{smart contracts and auctions}
-\subsection*{implement backup and sync}
-
-\subsection*{large, scaleable deployment}
-I.e. sharding, db replication, load balancer(s)
-
-\subsection*{Hardware security module for exchange}
-
-\subsection*{Bitcoin/Blockchain integration}
-
-\subsection*{UX study and improvements}
-(including tracking/planning of spending)
-
-\subsection*{News Distribution}
+\subsection*{Standard Model}
+Our current instantiation of the Taler protocol relies heavily on hash
+functions. Since the result by Canetti and others \cite{canetti2004random}
+about the theoretical impossibility of securely instantiating protocols that
+rely on the random oracle assumption for their security, a vast amount of
+literature has been devoted to find instantiations of interesting protocols in
+the standard model \cite{koblitz2015random}. The Taler protocol syntax could
+likely be also instantiated securely in the standard model, based existing on
+blind signature schemes in the standard model. The tradeoff however is that
+while removing the random oracle assumption, typically other less well known
+assumptions must be made.
-\subsection*{Formal verification of proofs}
-(CryptoVerif, etc.)
+\subsection*{Post-Quantum security}
+The possibility of post-quantum computers breaking the security of established
+cryptographic primitives has lately received a lot of attention from
+cryptographers. While currently most schemes with post-quantum security are impractical,
+it might be worthwhile to further investigate their application to e-cash, based
+on existing work such as \cite{zhang2018new}.
+
+\subsection*{Applications to network incentives}
+Some peer-to-peer networking protocols (such as onion routing
+\cite{dingledine2004tor}) do not have inherent incentives and rely on
+volunteers to provide infrastructure. In future work, we want to look at
+adding incentives in the form of Taler payments to a peer-to-peer networking
+platform such as GNUnet.
+
+\subsection*{Smart(er) Contracts and Auctions}
+Contract terms in Taler are relatively limited. There are some interesting
+secure multiparty computations, such as privacy-preserving auctions
+\cite{brandt2006obtain} that could be offered by exchanges as a fixed smart
+contract. This would allow a full privacy-preserving auction platform, as
+current auction protocols only output the winner of a privacy-preserving
+auction but do not address the required anonymous payments.
+
+
+\subsection*{Backup and Sync}
+Synchronization of wallets between multiple devices is a useful feature, but a
+naive implementation endangers privacy. A carefully designed protocol for
+backup and synchronization must make sure that the hosting service for the
+wallet's data cannot collaborate with the exchange and merchants to deaonymize
+users or transactions. Thus when spending coins for a payment, devices should
+not have to synchronously talk to their backup/sync provider. This creates the
+challenge of allocating the total available balance to individual devices in a
+way that fits the customer's spending pattern, and only require synchronous
+communication at fixed intervals or when really necessary to re-allocate coins.
+
+\subsection*{Formal Verification of Proofs}
+We currently model only a subset of the GNU Taler protocol formally, and proofs
+are handwritten and verified by humans. A tool such as CryptoVerif
+\cite{blanchet2007cryptoverif} can allow a higher coverage and computer-checked
+proofs, and would allow protocol changes to be validated in shorter time.
\subsection*{Coin Restrictions / ``Taler for Children''}
+By designating certain denominations for different purposes, GNU Taler could be
+used to implement a very simple form of anonymous credentials
+\cite{paquin2011u,camenisch2004signature}, which then could be used to
+implement a Taler wallet specifically aimed at children, in order to teach them
+responsible and autonomous spending behavior, while granting them privacy and
+at the same time preventing them from making age-inappropriate purchases
+online, as the discretion of parents.
+
+%\subsection*{gnunet-blockchain / deployment of the full stack payment system}
+%=> no, talk more about integration with real banks, KYC
+%
+%\subsection*{P2P payments}
+%
+%\subsection*{NFC Wallet}
+%
+%\subsection*{large, scaleable deployment}
+%I.e. sharding, db replication, load balancer(s)
+%
+%\subsection*{Hardware security module for exchange}
+%
+%\subsection*{Bitcoin/Blockchain integration}
+%
+%\subsection*{UX study and improvements}
+%(including tracking/planning of spending)
+%
+%\subsection*{News Distribution}
\chapter{Conclusion}\label{chapter:conclusion}