diff options
author | Florian Dold <florian.dold@gmail.com> | 2018-09-05 01:00:44 +0200 |
---|---|---|
committer | Florian Dold <florian.dold@gmail.com> | 2018-09-05 01:00:44 +0200 |
commit | 980bdb7e2f6032cbaf22d3115eeca5a7b85c7e9f (patch) | |
tree | c715c8c6b3ab2fe9c6fb021aafc241fdf5789671 /conclusions.tex | |
parent | 9ea34dafb52a346272e8cb2900a7d2d8430140f4 (diff) | |
download | dold-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.tex | 105 |
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} |