taler/exchange
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Merge branch 'master' into ar14-merging

Browse Source
This commit is contained in:
Özgür Kesim 2022-02-15 23:20:33 +01:00
commit acab20a2ab
Signed by: oec
GPG Key ID: 3D76A56D79EDD9D7
183 changed files with 21495 additions and 2693 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
.gitignore vendored
View File

@ -5,6 +5,8 @@
*.gcno
*.gcda
*.mo
*.blg
*.bbl
.dirstamp
m4/*.m4
doc/coverage/
@ -34,7 +36,8 @@ GRTAGS
GTAGS
*.swp
src/include/taler_error_codes.h
src/lib/test_exchange_api
src/testing/test_exchange_api_rsa
src/testing/test_exchange_api_cs
doc/doxygen/doxygen_sqlite3.db
src/auditor/taler-auditor-dbinit
src/auditor/taler-auditor-sign
@ -71,6 +74,9 @@ src/exchange-tools/taler-wire
src/exchangedb/perf-exchangedb
src/benchmark/taler-exchange-benchmark
src/benchmark/auditor.in
src/benchmark/exchange_benchmark_home/.local/share/taler/exchange-offline/
src/benchmark/exchange_benchmark_home/.local/share/taler/exchange-secmod-eddsa/
src/benchmark/exchange_benchmark_home/.local/share/taler/exchange-secmod-rsa/
src/benchmark/exchange_benchmark_home/.local/share/taler/exchange/live-keys/*
src/benchmark/exchange_benchmark_home/.local/share/taler/auditors/
src/benchmark/exchange_benchmark_home/.local/share/taler/auditor/
@ -110,9 +116,11 @@ doc/manual/manual.vr
doc/prebuilt/*
contrib/taler-exchange.tag
doxygen-doc/
src/testing/test_exchange_api_keys_cherry_picking
src/testing/test_exchange_api_keys_cherry_picking_cs
src/testing/test_exchange_api_keys_cherry_picking_rsa
src/auditor/taler-auditor-sync
src/auditor/taler-wire-auditor
src/auditor/generate_auditordb_home/
contrib/auditor-report.aux
contrib/auditor-report.log
contrib/auditor-report.tex
@ -120,8 +128,10 @@ contrib/auditor-report.pdf
src/bank-lib/taler-bank-transfer
src/bank-lib/test_bank_api_twisted
src/testing/test_exchange_api
src/testing/test_auditor_api
src/testing/test_exchange_api_overlapping_keys_bug
src/testing/test_auditor_api_cs
src/testing/test_auditor_api_rsa
src/testing/test_exchange_api_overlapping_keys_bug_cs
src/testing/test_exchange_api_overlapping_keys_bug_rsa
src/testing/test_exchange_api_home/.local/share/taler/exchange/revocations/
src/wire-plugins/test_wire_plugin_legacy_taler_bank
uncrustify.cfg

24
contrib/microhttpd.tag
View File

@ -172,6 +172,30 @@
<anchorfile>microhttpd.h</anchorfile>
<arglist></arglist>
</member>
<member kind="define">
<type>#define</type>
<name>MHD_HTTP_METHOD_GET</name>
<anchorfile>microhttpd.h</anchorfile>
<arglist></arglist>
</member>
<member kind="define">
<type>#define</type>
<name>MHD_HTTP_METHOD_POST</name>
<anchorfile>microhttpd.h</anchorfile>
<arglist></arglist>
</member>
<member kind="define">
<type>#define</type>
<name>MHD_HTTP_METHOD_PUT</name>
<anchorfile>microhttpd.h</anchorfile>
<arglist></arglist>
</member>
<member kind="define">
<type>#define</type>
<name>MHD_HTTP_METHOD_DELETE</name>
<anchorfile>microhttpd.h</anchorfile>
<arglist></arglist>
</member>
<member kind="typedef">
<type>int</type>
<name>MHD_AccessHandlerCallback</name>

1375
doc/cbdc-it/agsm-mod.bst Normal file
View File

File diff suppressed because it is too large Load Diff

561
doc/cbdc-it/cbdc-it.bib Normal file
View File

@ -0,0 +1,561 @@
%% To be used with modified bibliography style agsm-mod + hyperref + natbib + italian babel
@article{Adrian,
author = {Adrian, Tobias and Mancini-Griffoli},
year = {2019},
title = {{The Rise of Digital Money}},
journal = {IMF Fintech Note},
volume = {19/01},
}
@article{Agarwal,
author = {Agarwal, Ruchir and Miles S. Kimball},
year = {2019},
title = {{Enabling Deep Negative Rates to Fight Recessions: A Guide}},
journal = {IMF Working Paper},
volume = {19/84},
}
@article{Agur,
author = {Agur, Itai and Anil Ari and Giovanni Dell'Ariccia},
year = {2019},
title = {{Designing Central Bank Digital Currencies}},
journal = {IMF Working Paper},
volume = {19/252},
}
@article{Allen,
author = {Allen, Sarah and Srđjan Čapkun and Ittay Eyal and Giulia Fanti and Bryan A. Ford and James Grimmelmann and Ari Juels and Kari Kostiainen and Sarah Meiklejohn and Andrew Miller and Eswar Prasad and Karl Wüst and Fan Zhang},
year = {2020},
title = {{Design Choices for Central Bank Digital Currency: Policy and Technical Considerations}},
journal = {NBER Working Paper},
volume = {27634},
}
@article{Alves,
author = {Alves, Tiago and Don Felton},
year = {2004},
title = {TrustZone: Integrated hardware and software security},
journal = {ARM IQ},
volume = {3},
number = {4},
pages = {18--24},
}
@article{AuerBoehme,
author = {Auer, Raphael and Rainer Böhme},
year = {2020},
title = {The technology of retail central bank digital currency},
journal = {BIS Quarterly Review},
month = {March},
pages = {85--96},
}
@article{AuerCornelli,
author = {Auer, Raphael and Giulio Cornelli and Jon Frost},
year = {2020},
title = {{Taking stock: ongoing retail CBDC projects}},
journal = {BIS Quarterly Review},
month = {March},
pages = {97--98},
}
@booklet{BIS,
author = {{Bank for International Settlements}},
year = {2018},
title = {{Central Bank Digital Currencies. Joint Report of the Committee on Payments and Market Infrastructures and Markets Committee}},
}
@booklet{BoE,
author = {{Bank of England}},
year = {2020},
title = {{Central Bank Digital Currency: Opportunities, Challenges and Design. Discussion Paper}},
month = {March},
}
@article{Baiocchi,
author = {Baiocchi, Giovanni and Walter Distaso},
year = {2003},
title = {{GRETL: Econometric Software for the GNU Generation}},
journal = {Journal of Applied Econometrics},
volume = {18},
pages = {105-110},
}
@article{Bech,
author = {Bech, Morten and Rodney Garratt},
year = {2017},
title = {Central bank cryptocurrencies},
journal = {BIS Quarterly Review},
month = {September},
pages = {55--70},
}
@article{Berentsen,
author = {Berentsen, Aleksander and Fabian Schär},
year = {2018},
title = {{The Case for Central Bank Electronic Money and the Non-case for Central Bank Cryptocurrencies}},
journal = {Federal Reserve Bank of St. Louis Review},
volume = {100},
number = {2},
pages = {97--106},
}
@article{Bernstein2020,
author = {Bernstein, Daniel J. and Tanja Lange},
year = {2020},
title = {{eBACS: ECRYPT Benchmarking of Cryptographic Systems}},
url = {\url{https://bench.cr.yp.to}, consultato il 17 marzo 2020},
}
@article{Bernstein2012,
author = {Bernstein, Daniel J. and Niels Duif and Tanja Lange and Peter Schwabe and Bo-Yin Yang},
year = {2012},
title = {High-speed high-security signatures},
journal = {Journal of Cryptographic Engineering},
volume = {2},
pages = {77--89},
}
@InCollection{Bindseil,
author = {Bindseil, Ulrich},
year = {2020},
title = {{Tiered CBDC and the financial system}},
publisher = {European Central Bank},
series = {ECB Working Paper},
number = {2351},
month = {January},
}
@article{Boar,
author = {Boar, Codruta and Henry Holden and Amber Wadsworth},
year = {2020},
title = {Impending arrival - a sequel to the survey on central bank digital currency},
journal = {BIS Papers},
volume = {107},
}
@article{Boneh,
author = {Boneh, Dan},
year = {1999},
title = {{Twenty Years of Attacks on the RSA Cryptosystem}},
journal = {Notices of the AMS},
volume = {42},
number = {2},
pages = {202--213},
}
@InCollection{Bordo,
author = {Bordo, Michael D. and Andrew T. Levin},
year = {2017},
title = {Central bank digital currency and the future of monetary policy},
publisher = {National Bureau of Economic Research},
series = {NBER Working Paper Series},
number = {23711},
}
@article{Brunnermeier,
author = {Brunnermeier, Markus and Dirk Niepelt},
year = {2019},
title = {{On the Equivalence of Private and Public Money}},
journal = {Journal of Monetary Economics},
volume = {106},
pages = {27--41},
}
@article{Buiter,
author = {Buiter, Willem H. and Nikolaos Panigirtzoglou},
year = {2003},
title = {{Overcoming the Zero Bound on Nominal Interest Rates with Negative Interest on Currency: Gesell's Solution}},
journal = {The Economic Journal},
volume = {113},
number = {490},
pages = {723--746},
}
@InCollection{Bullmann,
author = {Bullmann, Dirk and Jonas Klemm and Andrea Pinna},
year = {2019},
title = {In search for stability in crypto-assets: are stablecoins the solution?},
publisher = {European Central Bank},
series = {ECB Occasional Paper Series},
number = {230},
}
@inproceedings{Camenisch2007,
author = {Camenisch, Jan and Aanna Lysyanskaya and Mira Meyerovich},
year = {2007},
title = {{Endorsed E-Cash}},
booktitle = {\textit{2007 IEEE Symposium on Security and Privacy (SP'07)}},
month = {May},
pages = {101--115},
}
@inproceedings{Camenisch2005,
author = {Camenisch, Jan and Susan Hohenberger and Anna Lysyanskaya},
year = {2005},
title = {{Compact E-Cash}},
booktitle = {\textit{Advances in Cryptology -- EUROCRYPT 2005: 24th Annual International Conference on the Theory and Applications of Cryptographic Techniques}},
address = {Aarhus, Denmark},
month = {May},
day = {22-26},
editor = {Ed. di Ronald Cramer},
publisher = {Springer-Verlag Berlin Heidelberg},
}
@inproceedings{Canard,
author = {Canard, Sébastien and Aline Gouget},
year = {2007},
title = {Divisible e-cash systems can be truly anonymous},
booktitle = {\textit{Annual International Conference on the Theory and Applications of Cryptographic Techniques}},
pages = {482--497},
}
@misc{CCC,
author = {{CCC e.V.}},
year = {2017},
title = {{Chaos Computer Club hacks e-motor charging stations}},
howpublished = {34c3},
}
@article{Chapman,
author = {Chapman, James and Rodney Garratt and Scott Hendry and Andrew McCormack and Wade McMahon},
year = {2017},
title = {{Project Jasper: Are Distributed Wholesale Payment Systems Feasible Yet?}},
journal = {Financial System Review},
publisher = {Bank of Canada},
month = {June},
pages = {59--69},
}
@inproceedings{Chaum1983,
author = {Chaum, David},
year = {1983},
title = {Blind signatures for untraceable payments},
booktitle = {\textit{Advances in Cryptology: Proceedings of Crypto `82}},
pages = {199--203},
}
@inproceedings{Chaum1990,
author = {Chaum, David and Amos Fiat and Moni Naor},
year = {1990},
title = {Untraceable electronic cash},
booktitle = {\textit{Advances in Cryptology: Proceedings of CRYPTO '88}},
pages = {319--327},
}
@inproceedings{Danezis,
author = {Danezis, George and Sarah Meiklejohn},
year = {2016},
title = {{Centrally Banked Cryptocurrencies}},
booktitle = {\textit{23nd Annual Network and Distributed System Security Symposium, NDSS2016}},
address = {San Diego, California, USA},
month = {February},
day = {21--24},
publisher = {The Internet Society},
}
@article{Diffie,
author = {Diffie, Whitfield and Martin Hellmann},
year = {1976},
title = {{New Directions in Cryptography}},
journal = {IEEE Trans. on Inf. Theory, IT-22},
pages = {644--654},
}
@phdthesis{Dold,
author = {Dold, Florian},
year = {2019},
title = {{The GNU Taler System: Practical and Provably Secure Electronic Payments. PhD Thesis}},
school = {University of Rennes 1},
}
@article{ECB,
author = {{European Central Bank}},
year = {2019},
title = {Exploring anonymity in central bank digital currencies},
journal = {In Focus},
number = {4},
month = {December},
}
@inproceedings{Fuchsbauer,
author = {Fuchsbauer, Georg and David Pointcheval and Damien Vergnaud},
year = {2009},
title = {Transferable constant-size fair e-cash},
booktitle = {International Conference on Cryptology and Network Security},
publisher = {Springer-Verlag Berlin Heidelberg},
pages = {226--247},
}
@inproceedings{Garcia,
author = {Garcia, Flavio and Gerhard de Koning Gans and Ruben Muijrers and Peter van Rossum and Roel Verdult and Ronny Wichers Schreur and Bart Jacobs},
year = {2008},
title = {{Dismantling MIFARE Classic}},
booktitle = {\textit{European Symposium on Research in Computer Security}},
}
@article{Garratt,
author = {Garratt, Rod and Michael Lee and Brendan Malone and Antoine Martin},
year = {2020},
title = {{Token- or Account-Based? A Digital Currency Can Be Both}},
journal = {Liberty Street Economics},
publisher = {Federal Reserve Bank of New York},
month = {August},
day = {12},
}
@article{Goodfriend,
author = {Goodfriend, Marvin},
year = {2000},
title = {{Overcoming the Zero Bound on Interest Rate Policy}},
journal = {Journal of Money, Credit, and Banking},
volume = {32},
number = {4},
pages = {1007--1035},
}
@article{Johnston,
author = {Johnston, Casey},
year = {2010},
title = {PS3 hacked through poor cryptography implementation},
journal = {Ars Technica},
month = {December},
day = {30},
}
@Misc{Jordan,
note = {Discorso in occasione del 30º anniversario del Centro di scienze economiche (WWZ) e dell’Associazione degli economisti basilesi (VBÖ)},
author = {Jordan, Thomas J.},
year = {2019},
title = {Valute, moneta e token digitali},
publisher = {University of Basel},
month = {September},
howpublished = {\url{https://www.snb.ch/it/mmr/speeches/id/ref_20190905_tjn/source/ref_20190905_tjn.it.pdf}},
}
@article{Kahn2009,
author = {Kahn, Charles M. and William Roberds},
year = {2009},
title = {{Why Pay? An Introduction to Payments Economics}},
journal = {Journal of Financial Intermediation},
number = {18},
pages = {1--23},
}
@article{Kahn2005,
author = {Kahn, Charles M. and James McAndrews and William Roberds},
year = {2005},
title = {{Money is Privacy}},
journal = {International Economic Review},
volume = {46},
number = {2},
pages = {377--399},
}
@article{Kasper,
author = {Kasper, Timo and Michael Silbermann and Christof Paar},
year = {2010},
title = {All you can eat or breaking a real-world contactless payment system},
journal = {Financial Cryptography and Data Security, Lecture Notes in Computer Science},
volume = {6052},
pages = {343--50},
}
@inproceedings{Katzenbeisser,
author = {Katzenbeisser, Stefan and Ünal Kocabaş and Vladimir Rožić and Ahmad-Reza Sadeghi and Ingrid Verbauwhede and Christian Wachsmann},
year = {2012},
title = {{PUFs: Myth, Fact or Busted? A Security Evaluation of Physically Unclonable Functions (PUFs) Cast in Silicon}},
booktitle = {\textit{Cryptographic Hardware and Embedded Systems -- CHES 2012. Lecture Notes in Computer Science}},
volume = {7428},
pages = {283--301},
}
@book{Keynes,
author = {Keynes, John Maynard},
year = {1936},
title = {The General Theory of Employment, Interest and Money},
publisher = {Macmillan},
}
@article{Kiff,
author = {Kiff, John and Jihad Alwazir and Sonja Davidovic and Aquiles Farias and Ashraf Khan and Tanai Khiaonarong and Majid Malaika and Hunter Monroe and Nobu Sugimoto and Hervé Tourpe and Peter Zhou},
year = {2020},
title = {{A Survey of Research on Retail Central Bank Digital Currency}},
journal = {IMF Working Paper},
volume = {20/104},
}
@InCollection{Kumhof,
author = {Kumhof, Michael and Clare Noone},
year = {2018},
title = {Central bank digital currencies - design principles and balance sheet implications},
publisher = {Bank of England},
series = {Staff Working Paper},
number = {725},
}
@inproceedings{Lapid,
author = {Lapid, Ben and Avishai Wool},
year = {2018},
title = {{Cache-Attacks on the ARM TrustZone Implementations of AES-256 and AES-256-GCM via GPU-Based Analysis}},
booktitle = {\textit{International Conference on Selected Areas in Cryptography. Lecture Notes in Computer Science}},
volume = {11349},
}
@article{Lerner,
author = {Lerner, Josh and Jean Tirole},
year = {2005},
title = {{The Scope of Open Source Licensing}},
journal = {Journal of Law, Economics \& Organization},
volume = {21},
pages = {20-56},
}
@misc{Libra,
author = {{Libra Association}},
year = {2020},
title = {{Libra White Paper v2.0}},
url = {\url{https://libra.org/en-US/white-paper}},
}
@inproceedings{Lim,
author = {Lim, Chae Hoon and Phil Joong Lee},
year = {1997},
title = {A key recovery attack on discrete log-based schemes using a prime order subgroup},
booktitle = {\textit{CRYPTO 1997. Lecture Notes in Computer Science}},
volume = {1294},
}
@InCollection{Lyons,
author = {Lyons, Richard K. and Ganesh Viswanath-Natraj},
year = {2020},
title = {{What Keeps Stablecoins Stable?}},
publisher = {National Bureau of Economic Research},
series = {NBER Working Paper Series},
number = {27136},
month = {May},
}
@article{Mancini-Griffoli,
author = {Mancini-Griffoli and Maria Soledad Martinez Peria and Itai Agur and Anil Ari and John Kiff and Adina Popescu and Celine Rochon},
year = {2018},
title = {{Casting Light on Central Bank Digital Currency}},
journal = {IMF Staff Discussion Notes},
volume = {18/08},
publisher = {International Monetary Fund},
}
@misc{Nakamoto,
author = {Nakamoto, Satoshi},
year = {2008},
title = {{Bitcoin: A Peer-to-Peer Electronic Cash System}},
url = {\url{https://www.bitcoin.com/bitcoin.pdf}},
}
@book{Narayanan,
author = {Narayanan, Arvind and Joseph Bonneau and Edward Felten and Andrew Miller and Steven Goldfeder},
year = {2016},
title = {Bitcoin and Cryptocurrency Technologies: A Comprehensive Introduction},
publisher = {Princeton University Press},
}
@misc{Niepelt,
author = {Niepelt, Dirk},
year = {2020},
title = {Digital money and central bank digital currency: An executive summary for policymakers},
howpublished = {\url{https://voxeu.org/article/digital-money-and-central-bank-digital-currency-executive-summary}},
}
@inproceedings{Okamoto,
author = {Okamoto, Tatsuaki},
year = {1995},
title = {{An Efficient Divisible Electronic Cash Scheme}},
booktitle = {\textit{Advances in Cryptology --- CRYPT0'95: 15th Annual International Cryptology Conference Santa Barbara, California, USA, 27--31 agosto, 1995 Proceedings}},
editor = {Ed. di Don Coppersmith},
publisher = {Springer-Verlag Berlin Heidelberg},
pages = {438--451},
}
@article{Pinto,
author = {Pinto, S. and N. Santos},
year = {2019},
title = {{Demystifying ARM TrustZone: A Comprehensive Survey}},
journal = {ACM Computing Surveys},
volume = {51},
number = {6},
month = {January},
pages = {1--31}
}
@article{Rivest,
author = {Rivest, Ronald L. and Adi Shamir and Leonard Adleman},
year = {1978},
title = {{A Method for Obtaining Digital Signatures and Public Key Cryptosystems}},
journal = {Comm. ACM},
volume = {21},
number = {2},
}
@book{Solove,
author = {Solove, Daniel J.},
year = {2011},
title = {Nothing to Hide: The false tradeoff between privacy and security},
publisher = {New Haven \& London: Yale University Press},
}
@article{Soukup,
author = {Soukup, Michael and Bruno Muff},
year = {2007},
title = {{Die Postcard lässt sich fälschen}},
journal = {Sonntagszeitung},
month = {April},
day = {22},
}
@article{Stallman,
author = {Stallman, Richard},
year = {1985},
title = {{The GNU manifesto}},
journal = {Dr. Dobb's Journal of Software Tools},
volume = {10},
number = {3},
pages = {30--35},
}
@TechReport{Riksbank,
author = {{Sveriges Riksbank}},
year = {2020},
title = {{The Riksbank's e-krona project}},
month = {February},
institution = {Sveriges Riksbank},
url = {\url{https://www.riksbank.se/globalassets/media/rapporter/e-krona/2019/the-riksbanks-e-krona-pilot.pdf}},
}
@misc{Wojtczuk,
author = {Wojtczuk, Rafal and Joanna Rutkowska},
year = {2009},
title = {{Attacking Intel Trusted Execution Technology}},
howpublished = {BlackHat-DC 2009},
}
@article{Yalta2010,
author = {Yalta, A. Talha and A. Yasemin Yalta},
year = {2010},
title = {{Should Economists Use Open Source Software for Doing Research?}},
journal = {Computational Economics},
volume = {35},
pages = {371--394},
}
@article{Yalta2008,
author = {Yalta, A. Talha and Riccardo Lucchetti},
year = {2008},
title = {{The GNU/Linux Platform and Freedom Respecting Software for Economists}},
journal = {Journal of Applied Econometrics},
volume = {23},
pages = {279-286},
}

1303
doc/cbdc-it/cbdc-it.tex Normal file
View File

File diff suppressed because it is too large Load Diff

566
doc/cbdc-it/cbdc.bib Normal file
View File

@ -0,0 +1,566 @@
@article{Adrian,
author = {Adrian, Tobias and Tommaso Mancini-Griffoli},
year = {2019},
title = {The Rise of Digital Money},
journal = {IMF Fintech Note},
volume = {19/01},
}
@article{Agarwal,
author = {Agarwal, Ruchir and Miles S. Kimball},
year = {2019},
title = {Enabling Deep Negative Rates to Fight Recessions: A Guide},
journal = {IMF Working Paper},
volume = {19/84},
}
@article{Agur,
author = {Agur, Itai and Anil Ari and Giovanni Dell'Ariccia},
year = {2019},
title = {Designing Central Bank Digital Currencies},
journal = {IMF Working Paper},
volume = {19/252},
}
@article{Allen,
author = {Allen, Sarah and Srđjan Čapkun and Ittay Eyal and Giulia Fanti and Bryan A. Ford and James Grimmelmann and Ari Juels and Kari Kostiainen and Sarah Meiklejohn and Andrew Miller and Eswar Prasad and Karl Wüst and Fan Zhang},
year = {2020},
title = {Design Choices for Central Bank Digital Currency: Policy and Technical Considerations},
journal = {NBER Working Paper},
volume = {27634},
}
@article{Alves,
author = {Alves, Tiago and Don Felton},
year = {2004},
title = {TrustZone: Integrated hardware and software security},
journal = {ARM IQ},
volume = {3},
number = {4},
pages = {18--24},
}
@article{AuerBoehme,
author = {Auer, Raphael and Rainer Böhme},
year = {2020},
title = {The technology of retail central bank digital currency},
journal = {BIS Quarterly Review},
month = {March},
pages = {85--96},
}
@article{AuerCornelli,
author = {Auer, Raphael and Giulio Cornelli and Jon Frost},
year = {2020},
title = {Taking stock: ongoing retail {CBDC} projects},
journal = {BIS Quarterly Review},
month = {March},
pages = {97--98},
}
@booklet{BIS,
author = {{Bank for International Settlements}},
year = {2018},
title = {Central Bank Digital Currencies. Joint Report of the Committee on Payments and Market Infrastructures and Markets Committee},
}
@booklet{BoE,
author = {{Bank of England}},
year = {2020},
title = {Central Bank Digital Currency: Opportunities, Challenges and Design. Discussion Paper},
month = {March},
}
@article{Baiocchi,
author = {Baiocchi, Giovanni and Walter Distaso},
year = {2003},
title = {{GRETL}: Econometric Software for the {GNU} Generation},
journal = {Journal of Applied Econometrics},
volume = {18},
pages = {105-110},
}
@article{Bech,
author = {Bech, Morten and Rodney Garratt},
year = {2017},
title = {Central bank cryptocurrencies},
journal = {BIS Quarterly Review},
month = {September},
pages = {55--70},
}
@article{Berentsen,
author = {Berentsen, Aleksander and Fabian Schär},
year = {2018},
title = {The Case for Central Bank Electronic Money and the Non-case for Central Bank Cryptocurrencies},
journal = {Federal Reserve Bank of St. Louis Review},
volume = {100},
number = {2},
pages = {97--106},
}
@article{Bernstein2020,
author = {Bernstein, Daniel J. and Tanja Lange},
year = {2020},
title = {{eBACS}: {ECRYPT} Benchmarking of Cryptographic Systems},
url = {\url{https://bench.cr.yp.to}, accessed 17 March 2020},
}
@article{Bernstein2012,
author = {Bernstein, Daniel J. and Niels Duif and Tanja Lange and Peter Schwabe and Bo-Yin Yang},
year = {2012},
title = {High-speed high-security signatures},
journal = {Journal of Cryptographic Engineering},
volume = {2},
pages = {77--89},
}
@InCollection{Bindseil,
author = {Bindseil, Ulrich},
year = {2020},
title = {Tiered {CBDC} and the financial system},
publisher = {European Central Bank},
series = {ECB Working Paper},
number = {2351},
month = {January},
}
@article{Boar,
author = {Boar, Codruta and Henry Holden and Amber Wadsworth},
year = {2020},
title = {Impending arrival - a sequel to the survey on central bank digital currency},
journal = {BIS Papers},
volume = {107},
}
@article{Boneh,
author = {Boneh, Dan},
year = {1999},
title = {Twenty Years of Attacks on the {RSA} Cryptosystem},
journal = {Notices of the AMS},
volume = {42},
number = {2},
pages = {202--213},
}
@InCollection{Bordo,
author = {Bordo, Michael D. and Andrew T. Levin},
year = {2017},
title = {Central bank digital currency and the future of monetary policy},
publisher = {National Bureau of Economic Research},
series = {NBER Working Paper Series},
number = {23711},
}
@article{Brunnermeier,
author = {Brunnermeier, Markus and Dirk Niepelt},
year = {2019},
title = {On the Equivalence of Private and Public Money},
journal = {Journal of Monetary Economics},
volume = {106},
pages = {27--41},
}
@article{Buiter,
author = {Buiter, Willem H. and Nikolaos Panigirtzoglou},
year = {2003},
title = {Overcoming the Zero Bound on Nominal Interest Rates with Negative Interest on Currency: Gesell's Solution},
journal = {The Economic Journal},
volume = {113},
number = {490},
pages = {723--746},
}
@InCollection{Bullmann,
author = {Bullmann, Dirk and Jonas Klemm and Andrea Pinna},
year = {2019},
title = {In search for stability in crypto-assets: are stablecoins the solution?},
publisher = {European Central Bank},
series = {ECB Occasional Paper Series},
number = {230},
}
@inproceedings{Camenisch2007,
author = {Camenisch, Jan and Aanna Lysyanskaya and Mira Meyerovich},
year = {2007},
title = {Endorsed E-Cash},
booktitle = {2007 IEEE Symposium on Security and Privacy (SP'07)},
month = {May},
pages = {101--115},
}
@inproceedings{Camenisch2005,
author = {Camenisch, Jan and Susan Hohenberger and Anna Lysyanskaya},
year = {2005},
title = {Compact E-Cash},
booktitle = {Advances in Cryptology -- EUROCRYPT 2005: 24th Annual International Conference on the Theory and Applications of Cryptographic Techniques},
address = {Aarhus, Denmark},
month = {May},
day = {22-26},
editor = {Ed. by Ronald Cramer},
publisher = {Springer-Verlag Berlin Heidelberg},
}
@inproceedings{Canard,
author = {Canard, Sébastien and Aline Gouget},
year = {2007},
title = {Divisible e-cash systems can be truly anonymous},
booktitle = {Annual International Conference on the Theory and Applications of Cryptographic Techniques},
pages = {482--497},
}
@misc{CCC,
author = {{CCC e.V.}},
year = {2017},
title = {Chaos Computer Club hacks e-motor charging stations},
howpublished = {34c3},
}
@article{Chapman,
author = {Chapman, James and Rodney Garratt and Scott Hendry and Andrew McCormack and Wade McMahon},
year = {2017},
title = {Project {J}asper: Are Distributed Wholesale Payment Systems Feasible Yet?},
journal = {Financial System Review},
publisher = {Bank of Canada},
month = {June},
pages = {59--69},
}
@inproceedings{Chaum1983,
author = {Chaum, David},
year = {1983},
title = {Blind signatures for untraceable payments},
booktitle = {Advances in Cryptology: Proceedings of Crypto `82},
pages = {199--203},
}
@inproceedings{Chaum1990,
author = {Chaum, David and Amos Fiat and Moni Naor},
year = {1990},
title = {Untraceable electronic cash},
booktitle = {Advances in Cryptology: Proceedings of CRYPTO '88},
pages = {319--327},
}
@inproceedings{Danezis,
author = {Danezis, George and Sarah Meiklejohn},
year = {2016},
title = {Centrally Banked Cryptocurrencies},
booktitle = {23nd Annual Network and Distributed System Security Symposium, NDSS2016},
address = {San Diego, California, USA},
month = {February},
day = {21--24},
publisher = {The Internet Society},
}
@article{Diffie,
author = {Diffie, Whitfield and Martin Hellmann},
year = {1976},
title = {New Directions in Cryptography},
journal = {IEEE Trans. on Inf. Theory, IT-22},
pages = {644--654},
}
@phdthesis{Dold,
author = {Dold, Florian},
year = {2019},
title = {The {GNU} {T}aler System: Practical and Provably Secure Electronic Payments. PhD Thesis},
school = {University of Rennes 1},
}
@article{ECB,
author = {{European Central Bank}},
year = {2019},
title = {Exploring anonymity in central bank digital currencies},
journal = {In Focus},
number = {4},
month = {December},
}
@inproceedings{Fuchsbauer,
author = {Fuchsbauer, Georg and David Pointcheval and Damien Vergnaud},
year = {2009},
title = {Transferable constant-size fair e-cash},
booktitle = {International Conference on Cryptology and Network Security},
publisher = {Springer-Verlag Berlin Heidelberg},
pages = {226--247},
}
@inproceedings{Garcia,
author = {Garcia, Flavio and Gerhard de Koning Gans and Ruben Muijrers and Peter van Rossum and Roel Verdult and Ronny Wichers Schreur and Bart Jacobs},
year = {2008},
title = {Dismantling MIFARE Classic},
booktitle = {European Symposium on Research in Computer Security},
}
@article{Garratt,
author = {Garratt, Rod and Michael Lee and Brendan Malone and Antoine Martin},
year = {2020},
title = {Token- or Account-Based? A Digital Currency Can Be Both},
journal = {Liberty Street Economics},
publisher = {Federal Reserve Bank of New York},
month = {August},
day = {12},
}
@article{Goodfriend,
author = {Goodfriend, Marvin},
year = {2000},
title = {Overcoming the Zero Bound on Interest Rate Policy},
journal = {Journal of Money, Credit, and Banking},
volume = {32},
number = {4},
pages = {1007--1035},
}
@article{Johnston,
author = {Johnston, Casey},
year = {2010},
title = {PS3 hacked through poor cryptography implementation},
journal = {Ars Technica},
month = {December},
day = {30},
}
@Misc{Jordan,
note = {Speech given at the 30th anniversary of the WWZ and VBÖ},
author = {Jordan, Thomas J.},
year = {2019},
title = {Currencies, money and digital tokens},
publisher = {University of Basel},
month = {September},
howpublished = {\url{https://www.snb.ch/en/mmr/speeches/id/ref\_20190905\_tjn/source/ref\_20190905\_tjn.en.pdf}},
}
@article{Kahn2009,
author = {Kahn, Charles M. and William Roberds},
year = {2009},
title = {Why Pay? An Introduction to Payments Economics},
journal = {Journal of Financial Intermediation},
number = {18},
pages = {1--23},
}
@article{Kahn2005,
author = {Kahn, Charles M. and James McAndrews and William Roberds},
year = {2005},
title = {Money is Privacy},
journal = {International Economic Review},
volume = {46},
number = {2},
pages = {377--399},
}
@article{Kasper,
author = {Kasper, Timo and Michael Silbermann and Christof Paar},
year = {2010},
title = {All you can eat or breaking a real-world contactless payment system},
journal = {Financial Cryptography and Data Security, Lecture Notes in Computer Science},
volume = {6052},
pages = {343--50},
}
@inproceedings{Katzenbeisser,
author = {Katzenbeisser, Stefan and Ünal Kocabaş and Vladimir Rožić and Ahmad-Reza Sadeghi and Ingrid Verbauwhede and Christian Wachsmann},
year = {2012},
title = {{PUF}s: Myth, Fact or Busted? A Security Evaluation of Physically Unclonable Functions ({PUF}s) Cast in Silicon},
booktitle = {Cryptographic Hardware and Embedded Systems -- CHES 2012. Lecture Notes in Computer Science},
volume = {7428},
pages = {283--301},
}
@book{Keynes,
author = {Keynes, John Maynard},
year = {1936},
title = {The General Theory of Employment, Interest and Money},
publisher = {Macmillan},
}
@article{Kiff,
author = {Kiff, John and Jihad Alwazir and Sonja Davidovic and Aquiles Farias and Ashraf Khan and Tanai Khiaonarong and Majid Malaika and Hunter Monroe and Nobu Sugimoto and Hervé Tourpe and Peter Zhou},
year = {2020},
title = {A Survey of Research on Retail Central Bank Digital Currency},
journal = {IMF Working Paper},
volume = {20/104},
}
@InCollection{Kumhof,
author = {Kumhof, Michael and Clare Noone},
year = {2018},
title = {Central bank digital currencies - design principles and balance sheet implications},
publisher = {Bank of England},
series = {Staff Working Paper},
number = {725},
}
@inproceedings{Lapid,
author = {Lapid, Ben and Avishai Wool},
year = {2018},
title = {Cache-Attacks on the {ARM} TrustZone Implementations of {AES}-256 and {AES}-256-{GCM} via {GPU}-Based Analysis},
booktitle = {International Conference on Selected Areas in Cryptography. Lecture Notes in Computer Science},
volume = {11349},
}
@article{Lerner,
author = {Lerner, Josh and Jean Tirole},
year = {2005},
title = {The Scope of Open Source Licensing},
journal = {Journal of Law, Economics \& Organization},
volume = {21},
pages = {20-56},
}
@misc{Libra,
author = {{Libra Association}},
year = {2020},
title = {Libra White Paper v2.0},
url = {\url{https://libra.org/en-US/white-paper}},
}
@inproceedings{Lim,
author = {Lim, Chae Hoon and Phil Joong Lee},
year = {1997},
title = {A key recovery attack on discrete log-based schemes using a prime order subgroup},
booktitle = {CRYPTO 1997. Lecture Notes in Computer Science},
volume = {1294},
}
@InCollection{Lyons,
author = {Lyons, Richard K. and Ganesh Viswanath-Natraj},
year = {2020},
title = {What Keeps Stablecoins Stable?},
publisher = {National Bureau of Economic Research},
series = {NBER Working Paper Series},
number = {27136},
month = {May},
}
@article{Mancini-Griffoli,
author = {Mancini-Griffoli, Tommaso and Maria Soledad Martinez Peria and Itai Agur and Anil Ari and John Kiff and Adina Popescu and Celine Rochon},
year = {2018},
title = {Casting Light on Central Bank Digital Currency},
journal = {IMF Staff Discussion Notes},
volume = {18/08},
publisher = {International Monetary Fund},
}
@misc{Nakamoto,
author = {Nakamoto, Satoshi},
year = {2008},
title = {Bitcoin: A Peer-to-Peer Electronic Cash System},
url = {\url{https://www.bitcoin.com/bitcoin.pdf}},
}
@book{Narayanan,
author = {Narayanan, Arvind and Joseph Bonneau and Edward Felten and Andrew Miller and Steven Goldfeder},
year = {2016},
title = {Bitcoin and Cryptocurrency Technologies: A Comprehensive Introduction},
publisher = {Princeton University Press},
}
@misc{Niepelt,
author = {Niepelt, Dirk},
year = {2020},
title = {Digital money and central bank digital currency: An executive summary for policymakers},
url = {https://voxeu.org/article/digital-money-and-central-bank-digital-currency-executive-summary},
}
@inproceedings{Okamoto,
author = {Okamoto, Tatsuaki},
year = {1995},
title = {An Efficient Divisible Electronic Cash Scheme},
booktitle = {Advances in Cryptology --- CRYPT0'95: 15th Annual International Cryptology Conference Santa Barbara, California, USA, August 27--31, 1995 Proceedings},
editor = {Ed. by Don Coppersmith},
publisher = {Springer-Verlag Berlin Heidelberg},
pages = {438--451},
}
@article{Pinto,
author = {Pinto, S. and N. Santos},
year = {2019},
title = {Demystifying {ARM} TrustZone: A Comprehensive Survey},
journal = {ACM Computing Surveys},
volume = {51},
number = {6},
month = {January},
pages = {1--31}
}
@article{Rivest,
author = {Rivest, Ronald L. and Adi Shamir and Leonard Adleman},
year = {1978},
title = {A Method for Obtaining Digital Signatures and Public Key Cryptosystems},
journal = {Comm. ACM},
volume = {21},
number = {2},
}
@book{Solove,
author = {Solove, Daniel J.},
year = {2011},
title = {Nothing to Hide: The false tradeoff between privacy and security},
publisher = {New Haven \& London: Yale University Press},
}
@article{Soukup,
author = {Soukup, Michael and Bruno Muff},
year = {2007},
title = {Die {P}ostcard lässt sich fälschen},
journal = {Sonntagszeitung},
month = {April},
day = {22},
}
@article{Stallman,
author = {Stallman, Richard},
year = {1985},
title = {The {GNU} manifesto},
journal = {Dr. Dobb's Journal of Software Tools},
volume = {10},
number = {3},
pages = {30--35},
}
@TechReport{Riksbank,
author = {{Sveriges Riksbank}},
year = {2020},
title = {The {R}iksbank's e-krona project},
month = {Feb},
institution = {Sveriges Riksbank},
url = {\url{https://www.riksbank.se/globalassets/media/rapporter/e-krona/2019/the-riksbanks-e-krona-pilot.pdf}},
}
@misc{Wojtczuk,
author = {Wojtczuk, Rafal and Joanna Rutkowska},
year = {2009},
title = {Attacking {I}ntel Trusted Execution Technology},
howpublished = {BlackHat-DC 2009},
}
@article{Yalta2010,
author = {Yalta, A. Talha and A. Yasemin Yalta},
year = {2010},
title = {Should Economists Use Open Source Software for Doing Research?},
journal = {Computational Economics},
volume = {35},
pages = {371--394},
}
@article{Yalta2008,
author = {Yalta, A. Talha and Riccardo Lucchetti},
year = {2008},
title = {The {GNU/L}inux Platform and Freedom Respecting Software for Economists},
journal = {Journal of Applied Econometrics},
volume = {23},
pages = {279-286},
}

BIN
doc/cbdc-it/diagramma1-it.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 106 KiB

BIN
doc/cbdc-it/diagramma2-it.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 119 KiB

BIN
doc/cbdc-it/graphics-it.odp Normal file
View File

Binary file not shown.

48
doc/cs/ads/abbreviation.tex Normal file
View File

@ -0,0 +1,48 @@
%!TEX root = ../dokumentation.tex
\chapter*{Abbreviations}
\begin{acronym}[YTMMM]
\acro{AES}{Advanced Encryption Standard}
\acro{AML}{Anti Money Laundering}
\acro{API}{Application Programming Interface}
\acrodefplural{API}[APIs]{Application Programming Interfaces}
\acro{BIP}{Bitcoin Improvement Proposal}
\acro{CA}{Certificate Authority}
\acro{CDH}{Computational Diffie-Hellman}
\acro{CFT}{Combating Financing of Terrorism}
\acro{CMA}{Choosen-Message Attack}
\acro{CS}{Clause Blind Schnorr Signature Scheme}
\acro{CSRF}{Client-Side Request Forgery}
\acro{CWE}{Common Weakness Enumeration}
\acro{DDH}{Decisional Diffie-Hellman}
\acro{DHKE}{Diffie-Hellman key exchange}
\acro{DLP}{Discrete Logarithm Problem}
\acro{DSA}{Digital Signature Algorithm}
\acro{ECC}{Elliptic Curve Cryptography}
\acro{ECDH}{Elliptic Curve Diffie Hellman}
\acro{EdDSA}{Edwards-curve Digital Signature Algorithm}
\acro{EUF}{Existentially Unforgeability}
\acro{FDH}{Full-Domain Hash}
\acro{GNU AGPL}{GNU Affero General Public License}
\acro{GNU GPL}{GNU General Public License}
\acro{GNU LGPL}{GNU Lesser General Public License}
\acro{IPC}{Inter Process Communication}
\acro{JSON}{JavaScript Object Notation}
\acro{KDF}{Key Derivation Function}
\acro{KYC}{Know Your Customer}
\acro{MAC}{Message Authentication Code}
\acro{NIST}{National Institute of Standards and Technology}
\acro{MK}{Master Key}
\acro{PKI}{Public Key Infrastructure}
\acro{PRF}{Pseudo Random Function}
\acro{PoS}{Point-of-Sales}
\acro{PRNG}{Pseudo Random Number Generator}
\acro{RNG}{Random Number Generator}
\acro{ROS}{Random inhomogeneities in an Overdetermined, Solvable system of linear equations}
\acro{RT}{Round-Trip}
\acro{RTT}{Round-Trip Time}
\acro{SPOF}{Single Point of Failure}
\acro{SSRF}{Server-Side Request Forgery}
\acro{Taler}{GNU Taler}
\acro{TRNG}{True Random Number Generator}
\acro{URL}{uniform resource locator}
\end{acronym}

26
doc/cs/ads/abstract.tex Normal file
View File

@ -0,0 +1,26 @@
\chapter*{Abstract}
GNU Taler is an intuitive, fast and socially responsible digital payment system implemented as free software.
While preserving the customers privacy, GNU Taler is still compliant to regulations.
\\\\
The goal of this thesis is to improve Taler's performance and provide cipher agility by adding support for Schnorr's blind signatures.
To achieve this goal, the current state in research for Schnorr signatures needs to be analyzed.
After choosing a signature scheme, it has to be integrated into the Taler protocols.
Besides implementing the redesigned protocols in Taler, an implementation of the cryptographic routines is needed.
\\\\
The paper "Blind Schnorr
Signatures and Signed ElGamal Encryption in the Algebraic Group Model" \cite{cryptoeprint:2019:877} from 2019 (updated in 2021) introducing \gls{CSBS} is used as theoretical basis for our improvements.
The paper explains why simple Blind Schnorr Signatures are broken and how the Clause Schnorr Blind Signature scheme is secured against this attack.\\
Compared to the currently used \gls{RSABS}, the new scheme has an additional request, two blinding factors instead of one and many calculations are done twice to prevent attacks.
\\\\
The Taler protocols were redesigned to support the Clause Blind Schnorr Signature scheme, including slight alterations to ensure \textit{abort-idempotency}, and then further specified.
Before starting with the implementation of the redesigned protocols, the cryptographic routines for \gls{CSBS} were implemented as part of the thesis. \\
All of the implemented code is tested and benchmarks are added for the cryptographic routines.
\\\\
Multiple results were achieved during this thesis:
The redesigned protocols Taler protocols with support for \gls{CSBS}, the implementation of the cryptographic routines, the implementation of Talers core protocols and a detailed comparison between \gls{RSABS} and \gls{CSBS}.
Overall, the \gls{CSBS} are significantly faster, require less disk space, and bandwidth and provide \textit{cipher agility} for Taler.
\section*{Acknowledgement}
We would like to kindly thank Christian Grothoff (Bern University of Applied Sciences) for his extensive advice, support and very helpful feedback during our whole thesis.\\
We also kindly thank Jeffrey Burdges (Web 3, Switzerland) for reviewing the proposal containing the redesigned protocols and giving feedback.\\
Further, we kindly thank Jacob Appelbaum (Bern University of Applied Sciences, Eindhoven University of Technology) for further results for the performance measurements of our cryptographic routines and the insightful conversations.

53
doc/cs/ads/glossary.tex Normal file
View File

@ -0,0 +1,53 @@
%!TEX root = ../thesis.tex
%
% vorher in Konsole folgendes aufrufen:
% makeglossaries makeglossaries dokumentation.acn && makeglossaries dokumentation.glo
%
%
% Glossareintraege --> referenz, name, beschreibung
% Aufruf mit \gls{...}
%
% \newglossaryentry{non-repudiation}{name={non-repudiation},plural={non-repudiation},description={After a message is signed, one can not dispute that a message was signed}}
% \newglossaryentry{sender_authenticity}{name={sender authenticity},plural={sender authenticity},description={The origin/sender of a message can not be forged}}
% \newglossaryentry{message_integrity}{name={message integrity},plural={message integrity},description={No unauthorized change to the message can be made, the message is tamperproof}}
\newglossaryentry{hkdf}{
name = {HKDF},
description = {The HMAC-based Extract-and-Expand Key Derivation Function is a function that takes potentially weak keying material as input and outputs high entropy keying material. For more information see section \ref{sec:kdf}}
}
\newglossaryentry{25519}{
name = {Curve25519},
description = {A popular elliptic curve used in many cryptographic systems based on elliptic curve cryptography. See section \ref{par:curve25519}}
}
\newglossaryentry{fdh}{
name = {FDH},
description = {A Full-Domain Hash is a hash function with an image size equal to the original gorup. See section \ref{sec:rsa-fdh}}.
}
\newglossaryentry{idempotence}{
name = {idempotence},
description = {Idempotence in the context of computer science is a property to ensure that the state of system will not change, no matter how many times the same request was made. See section \ref{abort-idempotency}}
}
\newglossaryentry{abort-idempotency}{
name = {abort-idempotency},
description = {Abort-idempotency is a special case of \gls{idempotence}. On every step in a protocol it needs to be ensured that even on an abort, the same request always receives the same response. See section \ref{abort-idempotency}}
}
\newglossaryentry{RSABS}{
name = {RSA Blind Signatures},
description = {Chaums Blind Signature Scheme based on RSA. See section \ref{sec:blind-rsa-sign}}
}
\newglossaryentry{CSBS}{
name = {Clause Blind Schnorr Signatures},
description = {A secure variant of Blind Schnorr Signature Schemes introduced in section \ref{sec:clause-blind-schnorr-sig}}
}
% \newglossaryentry{25519}{
% name = {},
% description = {}
% }

71
doc/cs/ads/header.tex Normal file
View File

@ -0,0 +1,71 @@
% Hyperlinks
\usepackage[
hidelinks,
pdfusetitle,
]{hyperref}
% Grafiken
\usepackage{graphicx}
%Bildpfad
\graphicspath{{images/}}
% Micro sign
\usepackage{siunitx}
% Farben
\usepackage{color}
\definecolor{LinkColor}{rgb}{0,0,0.2}
% Glossar
\usepackage[
nonumberlist, %keine Seitenzahlen anzeigen
%acronym, %ein Abkürzungsverzeichnis erstellen
%section, %im Inhaltsverzeichnis auf section-Ebene erscheinen
toc, %Einträge im Inhaltsverzeichnis
]{glossaries}
\makeglossaries
\input{ads/glossary}
%Nomenklatur
\usepackage{nomencl}
\makenomenclature
%PDF pages
\usepackage{pdfpages}
%Adjustbox (tikz figures of Taler)
\usepackage{adjustbox}
%BFH Boxes
% see BFH example for usage, looks nice!<<
\LoadBFHModule{listings,terminal,boxes}
%Akronyme
\usepackage[printonlyused,footnote]{acronym}
% Literaturverweise
\usepackage[
backend=biber,
style=alphabetic,
%citestyle=authoryear
]{biblatex}
\addbibresource{bibliography.bib}
\addbibresource{bibliography_projekt2.bib}
% TODOs in text
% documentation: http://tug.ctan.org/macros/latex/contrib/todonotes/todonotes.pdf
\usepackage{todonotes}
%Crypto Grafiken
\usepackage{cryptocode}
%\usepackage{amsmath}
\usepackage{listings}
\usepackage{xcolor}
\definecolor{mGreen}{rgb}{0,0.6,0}
\definecolor{mGray}{rgb}{0.5,0.5,0.5}
\definecolor{mPurple}{rgb}{0.58,0,0.82}
\definecolor{backgroundColour}{rgb}{0.95,0.95,0.92}
\definecolor{ApiColor}{HTML}{307FCB}
\definecolor{whyite}{HTML}{A1C66C} % Needs to be here due to some typo in BFH-CI stuff. Thanks BFH.

12
doc/cs/ads/history.tex Normal file
View File

@ -0,0 +1,12 @@
\chapter*{Document History}
\addcontentsline{toc}{chapter}{Document History}
%\begin{center}
\begin{tabular}{ ||l|l|l|l|| }
\hline
Version & Date & Comment & Author \\
\hline\hline
0.0.1 & 30.09.2021 & Document created & Gian Demarmels \& Lucien Heuzeveldt \\
\hline
\end{tabular}
%\end{center}

362
doc/cs/bibliography.bib Normal file
View File

@ -0,0 +1,362 @@
@misc{project-definition,
author = {Dr. Emmanuel Benoist},
title = {Adding Schnorr's blind signature in Taler},
howpublished = {\url{https://fbi.bfh.ch/fbi/2022/Studienbetrieb/BaThesisHS21/aufgabestellungen/BIE1-1-21-en.html}},
year = {2021}
}
@misc{swot-analysis,
author = {Will Kenton},
title = {Strength, Weakness, Opportunity, and Threat (SWOT) Analysis},
year = {2021},
howpublished = {\url{https://www.investopedia.com/terms/s/swot.asp}},
note = {[Online; accessed 01-October-2021]}
}
@misc{enwiki:1040250156,
author = {{Wikipedia contributors}},
title = {Project management triangle --- {Wikipedia}{,} The Free Encyclopedia},
year = {2021},
url = {https://en.wikipedia.org/w/index.php?title=Project_management_triangle&oldid=1040250156},
note = {[Online; accessed 1-October-2021]}
}
@misc{ionos:waterfall_model,
author = {ionos.com},
title = {Waterfall methodology},
year = {2019},
url = {https://www.ionos.com/digitalguide/websites/web-development/waterfall-methodology/},
note = {[Online; accessed 1-October-2021]}
}
@misc{schwab:anforderungen,
author = {Gerhard Schwab},
title = {Lerneinheit 4 - Anforderungen ermitteln},
howpublished = {BFH Moodle},
year = {2017}
}
@techreport{rfc2104,
shorthand = {RFC2104},
author = {H. Krawczyk, M.Bellare, R. Canetti},
title = {HMAC: Keyed-Hashing for Message Authentication},
howpublished = {Internet Requests for Comments},
type = {RFC},
number = 2104,
year = {1997},
issn = {2070-1721},
month = {02},
publisher = {IETF},
institution = {IETF},
url = {https://tools.ietf.org/html/rfc2104}
}
@techreport{rfc5869,
shorthand = {RFC5869},
author = {H. Krawczyk, P.Eronen},
title = {HMAC-based Extract-and-Expand Key Derivation Function (HKDF)},
howpublished = {Internet Requests for Comments},
type = {RFC},
number = 5869,
year = {2010},
issn = {2070-1721},
month = {05},
publisher = {IETF},
institution = {IETF},
url = {https://tools.ietf.org/html/rfc5869}
}
@misc{cryptoeprint:2019:877,
author = {Georg Fuchsbauer and
Antoine Plouviez and
Yannick Seurin},
title = {Blind Schnorr Signatures and Signed ElGamal Encryption in the Algebraic Group Model},
howpublished = {Cryptology ePrint Archive, Report 2019/877},
year = {2019},
note = {\url{https://ia.cr/2019/877} and \url{https://www.youtube.com/watch?v=W-uwVdGeUUs}}
}
@misc{bip:schnorr-bitc,
author = {Pieter Wuille, Jonas Nick, Tim Ruffing},
title = {Schnorr Signatures for secp256k1},
howpublished = {Bitcoin Improvement Proposal, bip-0340},
year = {2020},
note = {\url{https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki}}
}
@misc{git:secp256k1-schnorr,
author = {Bitcoin Repository},
title = {BIP-340 - Module for Schnorr signatures in libsecp256k1},
howpublished = {\url{https://github.com/bitcoin/bitcoin/tree/master/src/secp256k1}}
}
@misc{btc:releasnotes-0.21,
author = {Bitcoin.org },
title = {0.21.1 Release Notes},
howpublished = {\url{https://bitcoin.org/en/releases/0.21.1/}}
}
@inproceedings{spring:wallet-db-with-observers,
author = {Chaum, David
and Pedersen, Torben Pryds},
editor = {Brickell, Ernest F.},
title = {Wallet Databases with Observers},
booktitle = {Advances in Cryptology --- CRYPTO' 92},
year = {1993},
publisher = {Springer Berlin Heidelberg},
address = {Berlin, Heidelberg},
pages = {89--105},
abstract = {Previously there have been essentially only two models for computers that people can use to handle ordinary consumer transactions: (1) the tamper-proof module, such as a smart card, that the person cannot modify or probe; and (2) the personal workstation whose inner working is totally under control of the individual. The first part of this article argues that a particular combination of these two kinds of mechanism can overcome the limitations of each alone, providing both security and correctness for organizations as well as privacy and even anonymity for individuals.},
isbn = {978-3-540-48071-6}
}
@misc{schnorr:perfect-dl-signatures,
author = {Claus Peter Schnorr},
title = {Enhancing the Security of Perfect Blind DL-Signatures.},
howpublished = {Universität Frankfurt},
year = {2004},
note = {\url{https://www.math.uni-frankfurt.de/~dmst/teaching/SS2012/Vorlesung/EBS5.pdf}}
}
@misc{wagner:generalized-bday-prob,
author = {David Wagner},
title = {A Generalized Birthday Problem},
howpublished = {University of California Berkeley},
year = {2002},
note = {\url{https://www.iacr.org/archive/crypto2002/24420288/24420288.pdf}}
}
@inproceedings{Schnorr01securityof,
author = {Claus Peter Schnorr},
title = {Security of Blind Discrete Log Signatures against Interactive Attacks},
booktitle = {ICICS 2001, LNCS 2229},
year = {2001},
pages = {1--12},
publisher = {Springer-Verlag}
}
@misc{pic:simple-diagram,
author = {GNU Taler},
title = {Simple Taler Diagram},
year = {[Online; accessed 2-November-2021]},
note = {\url{https://taler.net/images/diagram-simple.png}}
}
@misc{pic:refresh-prot,
author = {GNU Taler},
title = {Taler Refresh protocol},
year = {[Online; accessed 2-November-2021]},
note = {\url{https://git.taler.net/marketing.git/plain/presentations/comprehensive/main.pdf}}
}
@misc{pic:taler-overview,
author = {GNU Taler},
title = {Operations},
howpublished = {\url{https://git.taler.net/marketing.git/plain/presentations/comprehensive/operations.png}},
year = {[Online; accessed 2-November-2021]},
}
@misc{pic:coin-state-machine,
author = {GNU Taler},
howpublished = {\url{https://git.taler.net/exchange.git/tree/doc/system/taler/coin.pdf}},
title = {Coin State Machine},
year = {[Online; accessed 13 January 2022]}
}
@misc{pic:deposit-state-machine,
author = {GNU Taler},
howpublished = {\url{https://git.taler.net/exchange.git/tree/doc/system/taler/deposit.pdf}},
title = {Deposit State Machine},
year = {[Online; accessed 13 January 2022]}
}
@misc{gnunet-git,
author = {GNUnet Git Repositories},
title = {gnunet.git},
howpublished = {\url{https://git.gnunet.org/gnunet.git/}}
}
@misc{libsodium:finite-field-arithmetic,
author = {libsodium documentation},
howpublished = {\url{https://doc.libsodium.org/advanced/point-arithmetic}},
title = {Finite field arithmetic}
}
@misc{bernlange:safecurves,
author = {Daniel J. Bernstein and Tanja Lange},
title = {SafeCurves: choosing safe curves for elliptic-curve cryptography.},
howpublished = {\url{https://safecurves.cr.yp.to}},
year = {accessed 17 October 2021. }
}
@misc{matt:unix-domain-sockets,
author = {Matt Lim},
title = {Getting Started With Unix Domain Sockets},
howpublished = {\url{https://medium.com/swlh/getting-started-with-unix-domain-sockets-4472c0db4eb1}},
year = {accessed 08 January 2022. }
}
@misc{rfc7748,
shorthand = {RFC7748},
series = {Request for Comments},
number = 7748,
howpublished = {RFC 7748},
publisher = {RFC Editor},
doi = {10.17487/RFC7748},
url = {https://rfc-editor.org/rfc/rfc7748.txt},
author = {Adam Langley and Mike Hamburg and Sean Turner},
title = {{Elliptic Curves for Security}},
pagetotal = 22,
year = 2016,
month = jan,
abstract = {This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the \textasciitilde{}128-bit and \textasciitilde{}224-bit security level, respectively, and are generated deterministically based on a list of required properties.}
}
@misc{ganapati:rsactftool,
author = {Ganapati},
title = {RsaCtfTool},
howpublished = {\url{https://github.com/Ganapati/RsaCtfTool}},
year = {accessed 13 January 2022. }
}
@misc{perez:stoprsa,
author = {Ben Perez},
title = {Seriously, stop using RSA},
howpublished = {\url{https://blog.trailofbits.com/2019/07/08/fuck-rsa/}},
year = {accessed 13 January 2022. }
}
@misc{geeks:rtt,
author = {preetikagupta8171},
title = {What is RTT(Round Trip Time)?},
howpublished = {\url{https://www.geeksforgeeks.org/what-is-rttround-trip-time/}},
year = {accessed 13 January 2022. }
}
@misc{madden:curve25519-clamping,
author = {Neil Madden},
howpublished = {\url{https://neilmadden.blog/2020/05/28/whats-the-curve25519-clamping-all-about/}},
title = {What’s the Curve25519 clamping all about?},
year = {2020}
}
@misc{bern:tweetnacl,
author = {Daniel J. Bernstein, Bernard van Gastel, Wesley Janssen},
title = {TweetNaCl: a crypto library in 100 tweets.},
howpublished = {\url{https://tweetnacl.cr.yp.to/papers.html}},
year = {17.09.2014}
}
@misc{taler-presentation,
author = {GNU Taler},
howpublished = {\url{https://git.taler.net/marketing.git/tree/presentations/comprehensive/main.pdf}},
title = {GNU Taler},
year = {2021}
}
@misc{cryptoeprint:2020:945,
author = {Fabrice Benhamouda and
Tancrède Lepoint and
Julian Loss and
Michele Orrù and
Mariana Raykova},
title = {On the (in)security of ROS},
howpublished = {Cryptology ePrint Archive, Report 2020/945},
year = {2020},
note = {\url{https://ia.cr/2020/945}}
}
@misc{rfc5246,
series = {Request for Comments},
number = 5246,
howpublished = {RFC 5246},
publisher = {RFC Editor},
doi = {10.17487/RFC5246},
url = {https://rfc-editor.org/rfc/rfc5246.txt},
author = {Eric Rescorla and Tim Dierks},
title = {{The Transport Layer Security (TLS) Protocol Version 1.2}},
pagetotal = 104,
year = 2008,
month = aug,
abstract = {This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. {[}STANDARDS-TRACK{]}}
}
@misc{rfc6071,
series = {Request for Comments},
number = 6071,
howpublished = {RFC 6071},
publisher = {RFC Editor},
doi = {10.17487/RFC6071},
url = {https://rfc-editor.org/rfc/rfc6071.txt},
author = {Sheila Frankel and Suresh Krishnan},
title = {{IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap}},
pagetotal = 63,
year = 2011,
month = feb,
abstract = {Over the past few years, the number of RFCs that define and use IPsec and Internet Key Exchange (IKE) has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic. This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes RFC 2411, the previous "IP Security Document Roadmap." The obsoleted IPsec roadmap (RFC 2411) briefly described the interrelationship of the various classes of base IPsec documents. The major focus of RFC 2411 was to specify the recommended contents of documents specifying additional encryption and authentication algorithms. This document is not an Internet Standards Track specification; it is published for informational purposes.}
}
@misc{enwiki:1055393696,
author = {{Wikipedia contributors}},
title = {RSA Factoring Challenge --- {Wikipedia}{,} The Free Encyclopedia},
year = {2021},
howpublished = {\url{https://en.wikipedia.org/w/index.php?title=RSA_Factoring_Challenge&oldid=1055393696}},
note = {[Online; accessed 16-January-2022]}
}
@misc{cryptoeprint:2015:625,
author = {Mike Hamburg},
title = {Ed448-Goldilocks, a new elliptic curve},
howpublished = {Cryptology ePrint Archive, Report 2015/625},
year = {2015},
note = {\url{https://ia.cr/2015/625}},
}
@misc{bern:curve25519,
author = {Daniel J. Bernstein},
title = {Curve25519: new Diffie-Hellman speed records},
howpublished = {\url{https://cr.yp.to/ecdh/curve25519-20060209.pdf}},
year = {02.09.2006}
}
@misc{yuchen:idempotence,
author = {Yuchen Z.},
title = {A Deep Dive Into Idempotence},
year = {2021},
howpublished = {\url{https://betterprogramming.pub/a-deep-dive-into-idempotence-1a39393df7e6}},
note = {[Online; accessed 16-January-2022]}
}
@misc{tibouchi:attacks-schnorr-nonce,
author = {Mehdi Tibouchi},
title = {Attacks on Schnorr signatures with biased nonces},
howpublished = {\url{https://ecc2017.cs.ru.nl/slides/ecc2017-tibouchi.pdf}},
year = {13.11.2017}
}
@article{wang:bitcoin-ecdsa-vuln,
author = {Wang, Ziyu and Yu, Hui and Zhang, Zongyang and Piao, Jiaming and Liu, Jianwei},
year = {2019},
month = {09},
pages = {},
title = {ECDSA weak randomness in Bitcoin},
volume = {102},
journal = {Future Generation Computer Systems},
doi = {10.1016/j.future.2019.08.034}
}
@misc{buchanan:ps3-ecdsa-vuln,
author = {Prof Bill Buchanan OBE},
title = {Not Playing Randomly: The Sony PS3 and Bitcoin Crypto Hacks},
howpublished = {\url{https://medium.com/asecuritysite-when-bob-met-alice/not-playing-randomly-the-sony-ps3-and-bitcoin-crypto-hacks-c1fe92bea9bc}},
year = {12.11.2018}
}
@misc{gian:nonce-sense,
author = {Gian Demarmels},
title = {Nonce-Sense - Romhack CTF Crypto Challenge},
howpublished = {\url{https://blog.c4pr1c0rn.ch/writeups/romhack_21/nonce_sence.html}},
year = {2021},
note = {[Online; accessed 19-January-2022]}
}

442
doc/cs/bibliography_projekt2.bib Normal file
View File

@ -0,0 +1,442 @@
% see here for standard templates: https://en.wikibooks.org/wiki/LaTeX/Bibliography_Management#Standard_templates
@misc{chaum-grothoff-moser:issue-cdbc,
author = {Chaum David, Grothoff Christian, Moser Thomas},
title = {How to issue a central bank digital currency},
howpublished = {\url{https://www.snb.ch/en/mmr/papers/id/working_paper_2021_03}},
year = {2021}
}
@phdthesis{dold:the-gnu-taler-system,
author = {Florian Dold},
title = {The GNU Taler System},
howpublished ={\url{https://taler.net/papers/thesis-dold-phd-2019.pdf}},
school = {Université de Rennes},
year = {2019}
}
@misc{schneier:value-privacy,
author = {Bruce Schneier},
title = {The Value of Privacy},
howpublished = {\url{https://www.schneier.com/blog/archives/2006/05/the_value_of_pr.html}},
year = {2006}
}
@misc{qualcomm:mobile-rng,
author = {Liang Kai},
title = {Guard your data with the Qualcomm Snapdragon mobile platform},
howpublished = {\url{https://www.qualcomm.com/media/documents/files/guard-your-data-with-the-qualcomm-snapdragon-mobile-platform.pdf}},
year = {2019}
}
@misc{chaum:blind-sign,
author = {Chaum David},
title = {Blind Signatures for Untraceable Payments},
howpublished = {\url{https://www.chaum.com/publications/Chaum-blind-signatures.PDF}},
year = {1983}
}
@misc{grothoff-dold:euro-bearer-online,
author = {Christian Grothoff, Florian Dold},
title = {Why a Digital Euro should be Online-first and Bearer-based},
howpublished = {\url{https://taler.net/papers/euro-bearer-online-2021.pdf}},
year = {2021}
}
@misc{website:bigcommerce-payment-fraud,
author = {BigCommerce},
title = {Payment fraud: What is it and how it can be avoided?},
howpublished = {\url{https://www.bigcommerce.com/ecommerce-answers/payment-fraud-what-it-and-how-it-can-be-avoided/}}
}
@misc{nist:recommendation-for-key-management,
author = {Elaine Barker},
title = {Recommendation for Key Management},
howpublished = {\url{https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf}},
year = {2020}
}
@misc{taler:snackautomat,
author = {Berner Fachhochschule},
title = {GNU Taler Snackautomat},
howpublished = {\url{https://www.bfh.ch/de/forschung/referenzprojekte/gnu-taler-snackautomat/}}
}
@book{modernCrypto,
author = {Nigel P. Smart},
editor = {David Basin, Kenny Paterson},
title = {Cryptography Made Simple},
publisher = {Springer International Publishing Switzerland AG},
year = {2016}
}
@inbook{Crépeau2005,
author = {Cr{\'e}peau, Claude},
title = {Cut-and-choose protocols},
publisher = {School of Computr Science, McGill University, Montréal (QC), Canada},
url = {http://crypto.cs.mcgill.ca/~crepeau/EoC/Cut&Choose.pdf}
}
% author from github: https://github.com/chaos-eng/chaos-eng.github.io
@misc{chaos-engineering,
author = {chaos-eng},
title = {PRINCIPLES OF CHAOS ENGINEERING},
howpublished = {\url{https://principlesofchaos.org/}},
year = {2019}
}
@misc{businger:public-key-crytpo,
author = {Walter Businger},
title = {Skript Public-Key Kryptographie},
year = {2021}
}
@misc{rutishauser:fuzzing,
author = {Dobin Rutishauser},
title = {Fuzzing},
howpublished = {Course material of BFH module Forensics and Code Security},
year = {2021}
}
@misc{codeblau:taler-audit,
author = {Code Blau GmbH},
title = {Report for the GNU Taler security audit in Q2/Q3 2020},
howpublished = {\url{https://taler.net/papers/codeblau-report-2020-q2.pdf}},
year = {2020}
}
@misc{pentest-execution-standard,
author = {The Penetration Testing Execution Standard},
title = {Main Page},
howpublished = {\url{http://www.pentest-standard.org/index.php/Main_Page}}
}
@misc{owasp:top-ten,
author = {OWASP Foundation},
title = {OWASP Top Ten},
howpublished = {\url{https://owasp.org/www-project-top-ten/}}
}
@misc{owasp:mobile-top-ten,
author = {OWASP Foundation},
title = {OWASP Mobile Top 10},
howpublished = {\url{https://owasp.org/www-project-mobile-top-10/}}
}
@misc{owasp:api-security-project,
author = {OWASP Foundation},
title = {OWASP API Security Project},
howpublished = {\url{https://owasp.org/www-project-api-security/}}
}
@misc{owasp:web-security-testing-guide,
author = {OWASP Foundation},
title = {OWASP Web Security Testing Guide},
howpublished = {\url{https://owasp.org/www-project-web-security-testing-guide/}}
}
@misc{owasp:mobile-security-testing-guide,
author = {OWASP Foundation},
title = {OWASP Mobile Security Testing Guide},
howpublished = {\url{https://owasp.org/www-project-mobile-security-testing-guide/}}
}
@misc{owasp:application-security-verification-standard,
author = {OWASP Foundation},
title = {OWASP Application Security Verification Standard},
howpublished = {\url{https://owasp.org/www-project-application-security-verification-standard/}}
}
@misc{owasp:mobile-application-security-verification-standard,
author = {OWASP Foundation},
title = {OWASP Mobile Application Security Verification Standard},
howpublished = {\url{https://github.com/OWASP/owasp-masvs}}
}
@misc{osstmm,
author = {ISECOM},
title = {OSSTMM 3},
howpublished = {\url{https://www.isecom.org/OSSTMM.3.pdf}}
}
@misc{emscripten,
author = {Emscripten Contributors},
title = {Emscripten documentation},
howpublished = {\url{https://emscripten.org/}}
}
@misc{emscripten:paper,
author = {Alon Zakai},
title = {Emscripten: an LLVM-to-JavaScript compiler},
howpublished = {\url{https://www.researchgate.net/publication/221320724_Emscripten_an_LLVM-to-JavaScript_compiler}},
year = {2011}
}
@misc{cwe,
author = {Common Weakness Enumeration},
title = {CWE - Common Weakness Enumeration},
howpublished = {\url{https://cwe.mitre.org/index.html}}
}
@misc{cwe:toctou,
author = {Common Weakness Enumeration},
title = {CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition},
howpublished = {\url{https://cwe.mitre.org/data/definitions/367.html}},
year = {2021}
}
@misc{cwe:c-weaknesses,
author = {Common Weakness Enumeration},
title = {CWE VIEW: Weaknesses in Software Written in C},
howpublished = {\url{https://cwe.mitre.org/data/definitions/658.html}}
}
% ---------- Taler documentation and repos
@misc{taler-documentation,
author = {Taler Systems SA},
title = {GNU Taler Documentation},
howpublished = {\url{https://docs.taler.net/}}
}
@misc{taler-documentation:backup-synchronization,
author = {Taler Systems SA},
title = {Backup and Synchronization Service API},
howpublished = {\url{https://docs.taler.net/core/api-sync.html}}
}
@misc{taler-documentation:auditor-operator-manual,
author = {Taler Systems SA},
title = {GNU Taler Auditor Operator Manual},
howpublished = {\url{https://docs.taler.net/taler-auditor-manual.html}}
}
@misc{taler-documentation:exchange-operator-manual,
author = {Taler Systems SA},
title = {GNU Taler Exchange Operator Manual},
howpublished = {\url{https://docs.taler.net/taler-exchange-manual.html}}
}
@misc{taler-documentation:merchant-backend-operator-manual,
author = {Taler Systems SA},
title = {GNU Taler Merchant Backend Operator Manual},
howpublished = {\url{https://docs.taler.net/taler-merchant-manual.html}}
}
@misc{taler-documentation:merchant-api,
author = {Taler Systems SA},
title = {GNU Taler Merchant API Tutorial},
howpublished = {\url{https://docs.taler.net/taler-merchant-api-tutorial.html}}
}
@misc{taler-documentation:back-office,
author = {Taler Systems SA},
title = {Back-office Web service manual},
howpublished = {\url{https://docs.taler.net/taler-backoffice-manual.html}}
}
@misc{taler-documentation:pos-manual,
author = {Taler Systems SA},
title = {GNU Taler Merchant POS Manual},
howpublished = {\url{https://docs.taler.net/taler-merchant-pos-terminal.html}}
}
@misc{taler-documentation:wallet-developer-manual,
author = {Taler Systems SA},
title = {GNU Taler Wallet Developer Manual},
howpublished = {\url{https://docs.taler.net/taler-wallet.html}}
}
@misc{taler-documentation:wallet-cli-manual,
author = {Taler Systems SA},
title = {GNU Taler Wallet CLI Manual},
howpublished = {\url{https://docs.taler.net/taler-wallet-cli-manual.html}}
}
@misc{taler-documentation:,
author = {Taler Systems SA},
title = {},
howpublished = {\url{}}
}
@misc{taler-documentation:,
author = {Taler Systems SA},
title = {},
howpublished = {\url{}}
}
@misc{taler-documentation:,
author = {Taler Systems SA},
title = {},
howpublished = {\url{}}
}
% see https://git.taler.net/
@misc{taler-git,
author = {GNU Taler Git Repositories},
title = {GNU Taler Git Repositories},
howpublished = {\url{https://git.taler.net/}}
}
@misc{taler-git:exchange,
author = {GNU Taler Git Repositories},
title = {exchange.git},
howpublished = {\url{https://git.taler.net/exchange.git/}}
}
@misc{taler-git:merchant,
author = {GNU Taler Git Repositories},
title = {merchant.git},
howpublished = {\url{https://git.taler.net/merchant.git/}}
}
@misc{taler-git:wallet-core,
author = {GNU Taler Git Repositories},
title = {wallet-core.git},
howpublished = {\url{https://git.taler.net/wallet-core.git/}}
}
@misc{taler-git:auditor,
author = {GNU Taler Git Repositories},
title = {auditor.git},
howpublished = {\url{https://git.taler.net/auditor.git/}}
}
@misc{taler-git:backoffice,
author = {GNU Taler Git Repositories},
title = {backoffice.git},
howpublished = {\url{https://git.taler.net/backoffice.git/}}
}
@misc{taler-git:android,
author = {GNU Taler Git Repositories},
title = {taler-android.git},
howpublished = {\url{https://git.taler.net/taler-android.git}}
}
@misc{taler-git:ios,
author = {GNU Taler Git Repositories},
title = {taler-ios.git},
howpublished = {\url{https://git.taler.net/taler-ios.git/}}
}
@misc{taler-git:django-payments,
author = {GNU Taler Git Repositories},
title = {django-payments-taler.git},
howpublished = {\url{https://git.taler.net/django-payments-taler.git/}}
}
@misc{taler-git:woocommerce,
author = {GNU Taler Git Repositories},
title = {woocommerce-taler.git},
howpublished = {\url{https://git.taler.net/woocommerce-taler.git/}}
}
@misc{taler-git:saleor,
author = {GNU Taler Git Repositories},
title = {saleor-frontend.git},
howpublished = {\url{https://git.taler.net/saleor-frontend.git/}}
}
@misc{taler-git:merchant-demos,
author = {GNU Taler Git Repositories},
title = {taler-merchant-demos.git},
howpublished = {\url{https://git.taler.net/taler-merchant-demos.git/}}
}
% ---------- Wikipedia
@misc{dewiki:205456999,
author = {Wikipedia},
title = {Know your customer --- Wikipedia{,} Die freie Enzyklopädie},
year = {2020},
url = {\url{https://de.wikipedia.org/w/index.php?title=Know_your_customer&oldid=205456999}},
note = {[Online; Stand 3. April 2021]}
}
@misc{enwiki:1013094030,
author = {{Wikipedia contributors}},
title = {EdDSA --- {Wikipedia}{,} The Free Encyclopedia},
year = {2021},
howpublished = {\url{https://en.wikipedia.org/w/index.php?title=EdDSA&oldid=1013094030}},
note = {[Online; accessed 22-April-2021]}
}
@misc{enwiki:1020240018,
author = {{Wikipedia contributors}},
title = {Birthday problem --- {Wikipedia}{,} The Free Encyclopedia},
year = {2021},
howpublished = {\url{https://en.wikipedia.org/w/index.php?title=Birthday_problem&oldid=1020240018}},
note = {[Online; accessed 28-April-2021]}
}
@misc{enwiki:1019272750,
author = {{Wikipedia contributors}},
title = {Birthday attack --- {Wikipedia}{,} The Free Encyclopedia},
year = {2021},
howpublished = {\url{https://en.wikipedia.org/w/index.php?title=Birthday_attack&oldid=1019272750}},
note = {[Online; accessed 24-April-2021]}
}
@misc{enwiki:blind-sign,
author = {{Wikipedia contributors}},
title = {Blind signature --- {Wikipedia}{,} The Free Encyclopedia},
year = {2021},
howpublished = {\url{https://en.wikipedia.org/w/index.php?title=Blind_signature&oldid=1001105629}},
note = {[Online; accessed 12-April-2021]}
}
@misc{enwiki:1024158358,
author = "{Wikipedia contributors}",
title = "Scalability --- {Wikipedia}{,} The Free Encyclopedia",
year = "2021",
howpublished = "\url{https://en.wikipedia.org/w/index.php?title=Scalability&oldid=1024158358}",
note = "[Online; accessed 17-June-2021]"
}
@misc{enwiki:1024197377,
author = "{Wikipedia contributors}",
title = "Chaos engineering --- {Wikipedia}{,} The Free Encyclopedia",
year = "2021",
howpublished = "\url{https://en.wikipedia.org/w/index.php?title=Chaos_engineering&oldid=1024197377}",
note = "[Online; accessed 17-June-2021]"
}
@misc{enwiki:1026754635,
author = "{Wikipedia contributors}",
title = "Replay attack --- {Wikipedia}{,} The Free Encyclopedia",
year = "2021",
howpublished = "\url{https://en.wikipedia.org/w/index.php?title=Replay_attack&oldid=1026754635}",
note = "[Online; accessed 17-June-2021]"
}
% ---------- RFCs
@misc{rfc8032,
series = {Request for Comments},
number = 8032,
howpublished = {RFC 8032},
publisher = {RFC Editor},
doi = {10.17487/RFC8032},
url = {https://rfc-editor.org/rfc/rfc8032.txt},
author = {Simon Josefsson and Ilari Liusvaara},
title = {{Edwards-Curve Digital Signature Algorithm (EdDSA)}},
pagetotal = 60,
year = 2017,
month = jan,
abstract = {This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.},
}
@misc{rfc6265,
series = {Request for Comments},
number = 6265,
howpublished = {RFC 6265},
publisher = {RFC Editor},
doi = {10.17487/RFC6265},
url = {https://rfc-editor.org/rfc/rfc6265.txt},
author = {Adam Barth},
title = {{HTTP State Management Mechanism}},
pagetotal = 37,
year = 2011,
month = apr,
abstract = {This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. {[}STANDARDS-TRACK{]}},
}

72
doc/cs/content/1_introduction.tex Normal file
View File

@ -0,0 +1,72 @@
\chapter{Introduction}
\section{Motivation}
Public key cryptography based on elliptic curves allows smaller key sizes compared to other cryptographic systems.
While still providing equivalent security, the smaller key size leads to huge performance benefits.
\\
Blind Signatures are one of the key components upon which Taler's privacy is built upon.
Our thesis adds support for a modern cryptographic scheme called the Clause Blind Schnorr Signature scheme \cite{cryptoeprint:2019:877}.\\
Additionally to the benefits of ellicptic curve cryptography, adding a second blind signature scheme makes Taler independent of a single cryptographic scheme and thus provides \textit{cipher agility}.
\section{Goals}
\label{sec:goals}
The project definition is as follows \cite{project-definition}:
The students will implement the blind Schnorr signature inside Taler.
Taler is a system for the management of virtual money.
Taler is based on coins that need to be signed by an exchange (for instance a bank).
In the actual version of the system, coins are signed by the exchange using Schaum's bind-signature protocol.
This allows users to have signed coins, without the exchange knowing what it signed.
This step is fundamental for the privacy protection of the system.
\\The students have to insert the Schnorr blind signature algorithm inside the protocol for the creation of coins.
But they also need to change the Taler subsystems where the verification of the signature is done.
\\The actual Taler system allows people to let an exchange sign a coin for which they do not have the private key.
This is a security issue (for misuse of coins on the dark-net for instance).
An optional task for the project is to prevent a user to let an exchange sign a public key when the client does not have access to the corresponding private key.
\\Here is a list of the tasks that the students must do:
\begin{itemize}
\item Design a protocol integrating Schnorr blind signature in the creation of Taler coins.
\item Implement the protocol inside the exchange application and the wallet app.
\item Analyze the different Taler subsystems to find where the blind signature is verified.
\item Replace verification of the blind signature everywhere it occurs.
\item Compare both blind signature systems (Schaum's and Schnorr's), from the point of view of security, privacy protection, speed, \dots
\item Write tests for the written software.
\item Conduct tests for the written software.
\item Transfer the new software the Taler developers team
\end{itemize}
Here is a list of optional features:
\begin{itemize}
\item Design a protocol, such that the exchange can verify that the user knows the private key corresponding to the coin that is to be signed.
\item Implement that protocol.
\end{itemize}
\section{Scope}
\label{sec:scope}
In scope are all necessary changes on the protocol(s) and components for the following tasks:
\begin{itemize}
\item Research the current state of Blind Schnorr Signature schemes
\item Redesign the Taler protocols to support Blind Schnorr signatures
\item Add support for a Blind Schnorr Signature Scheme in the exchange, merchant, wallet-core, wallet web-extension and optionally on the android mobile wallet
\item design and implement a protocol where the user proves to the exchange the knowledge of the coin that is to be signed (optional)
\end{itemize}
Out of scope is production readyness of the implementation.
This is because changes in the protocos and code need to be thoroughly vetted to ensure that no weaknesses or security vulnerabilities were introduced.
Such an audit is out of scope for the thesis and is recommended to be performed in the future.
The iOS wallet will not be considered in this work.
\\
It is not unusual that a scope changes when a project develops.
Due to different reasons, the scope needed to be shifted.
Since there are no libraries supporting \gls{CSBS}, the signature scheme has to be implemented and tested before integrating it into Taler.
While this is still reasonable to do in this project, it will affect the scope quite a bit.
The analysis of the optional goal showed, that a good solution that aligns with Taler's goals and properties needs more research and is a whole project by itself.
Scope changes during the project:
\begin{itemize}
\item \textbf{Added:} Implement the cryptographic routines in GNUnet
\item \textbf{Removed: } design and implement a protocol where the user proves to the exchange the knowledge of the coin that is to be signed (optional)
\item \textbf{Adjusted: } Focus is on the implementation of the exchange protocols (Withdraw, Spend, Refresh and cryptographic utilities)
\item \textbf{Adjusted: } Implementation of the refresh protocol and wallet-core are nice-to-have goals
\item \textbf{Removed: } The Merchant and the android wallet implementations are out of scope
\end{itemize}

1467
doc/cs/content/3_preliminaries.tex Normal file
View File

File diff suppressed because it is too large Load Diff

458
doc/cs/content/4_1_design.tex Normal file
View File

@ -0,0 +1,458 @@
\chapter{Protocol Design}
\label{chap:design}
This chapter describes the necessary changes on the protocol level to implement a Blind Schnorr Signature Scheme to Taler.
\section{Analysis of Current Protocols}
The blind RSA signature scheme is only used for coin signatures.
Note that we omitted protocols (or parts of them) where the coin signature is transmitted, but no other actions using it is performed.
\\\\
\label{abort-idempotency}
An important property to mention here is \textit{\gls{abort-idempotency}}.
\Gls{idempotence} in the context of computer science is a property to ensure that the state of a system will not change, no matter how many times the same request was made.
A more in-depth explanation is given within the cited source \cite{yuchen:idempotence}.\\
\textit{\gls{abort-idempotency}} goes a bit further.
When the protocol is aborted at any stage, for example due to power cuts or network issues, the protocol still needs to ensure that the same response is sent for the same request.
This is especially challenging when dealing with random values as we will see in the redesigned protocols in the following sections.
For \gls{RSABS} it is inherently easier to provide \textit{\gls{abort-idempotency}} since signature creation only needs one round-trip and requires less random values.
The following protocols currently use \gls{RSABS}:
\begin{itemize}
\item \textbf{Withdraw Protocol:}
The customer uses the blind signature scheme to blind the coins before transmitting them to the exchange, which blindly signs it (standard RSA signature) and the returns the signatures.
After the customer receives the signatures, he unblinds and stores them together with the coins.
\\ Components:
\begin{itemize}
\item Customer
\item Exchange
\end{itemize}
\item \textbf{Deposit Protocol:}
During the Deposit, the exchange verifies the coin signature derived using the blind RSA signature scheme.
\\ Components:
\begin{itemize}
\item Exchange
\end{itemize}
\item \textbf{Refresh Protocol:}
The refresh protocol is used to derive a new coin from an old one which was partially spent.
Parts of the protocol are similar to the withdraw protocol, but it is more complex due to the added DH lock and cut-and-choose.
\\ Components:
\begin{itemize}
\item Customer
\item Exchange
\end{itemize}
\item \textbf{Tipping:}
Tipping is a variation of the withdraw protocol where the message containing the blinded planchets is transmitted to the merchant, who signs them using his reserve private, key and returns the signatures back to the customer.
Here, the details from the withdraw protocol apply.
\\ Components:
\begin{itemize}
\item Customer
\item Exchange
\end{itemize}
\item \textbf{Payback Protocol:}
The payback protocol distinguishes three different cases, which either use the refresh protocol or disclose either the withdraw transcript or refresh protocol transcript to the exchange.
\\ Components:
\begin{itemize}
\item Customer
\item Exchange
\end{itemize}
\end{itemize}
\section{Protocol Changes}
The goal of the thesis is to add support for the Clause Blind Schnorr Signature scheme to Taler, besides the existing \gls{RSABS} implementation (see section \ref{sec:blind-rsa-sign}).
For the design of the \gls{CSBS} the existing protocols with \gls{RSABS} were redesigned.
The goal of the blind signature is to keep the exchange from knowing which coin a user withdraws and thus preventing the exchange linking a coin to a user.
The biggest impact is on the withdrawal and refresh protocols, but all protocols that include some operation around denomination signatures are affected.
During the thesis the protocols will be redesigned, implemented and the differences to the current version will be outlined.
These results will be delivered to the Taler team.
Feedback is very important when (re)designing protocols.
For that reason the redesigned protocols were discussed and reviewed with Christian Grothoff multiple times.
As signature scheme the Clause Blind Schnorr Signature Scheme described in section \ref{sec:clause-blind-schnorr-sig} was chosen for multiple reasons.
First of all it is currently considered to be secure (see \cite{cryptoeprint:2019:877}).
Schnorr Signatures on \gls{25519} are much shorter than RSA signatures.
This should provide notable performance improvements in speed and storage, and therefore scales better.
The paper describes a security analysis of the Blind Schnorr Signature scheme and introduces a modification (the "clause" part in the name) that is resistant to Wagner's algorithm (which solves ROS problem).
\Gls{25519} \cite{bern:curve25519} will be used for the implementation because it is a widely accepted curve (see \cite{bernlange:safecurves}, \cite{rfc7748}) and is already used by Taler (Taler uses Ed25519 which is built upon \gls{25519}).
\subsection{Withdraw Protocol}
\label{sec:withdraw-protocol-schnorr}
The modified protocol using the Clause Blind Schnorr Signature Scheme is described in figures \ref{fig:withdrawal-process-schnorr-1} and \ref{fig:withdrawal-process-schnorr-2}.
The proposed change introduces an additional round trip.
It must be prevented that the exchange has to track sessions or persist values during the first stage \ref{fig:withdrawal-process-schnorr-1}, while still ensuring \gls{abort-idempotency}.
In order to ensure \textit{\gls{abort-idempotency}}, the exchange has to generate the same $R_0,R_1$ for the same withdrawal request, while $r_0,r_1$ still needs to be unpredictable for the customer.
For this reason a withdrawal-nonce combined with a \gls{hkdf} comes into play.
The redesigned protocol makes extensive use of \gls{hkdf}'s functionality as \ac{PRNG} and one-way function, thus random becomes \textit{unpredictable}.
In the beginning of the protocol, the customer generates a coin key pair.
Its private key is used to generate the withdraw-nonce $n_w$ and the blinding factors $\alpha_0, \alpha_1, \beta_0, \beta_1$.
The exchange uses the withdraw nonce together with the reserve key and a long-term secret to generate $r_0, r_1$.
The coin and denomination private keys can be used as long-term secrets due to the one-way property of the \gls{hkdf}.
Another question evolved around which key to use for the derivation of $ r_0, r_1 $.
Obvious options are the denomination key or the exchange's online signing key.
The denomination key was chosen because it has the payback protocol in place that would handle coin recovery in case of a key compromise and subsequent revocation.
\begin{figure}[htp]
\begin{equation*}
\resizebox{1.0\textwidth}{!}{$\displaystyle
\begin{array}{ l c l }
% preliminaries
\text{Customer} & & \text{Exchange}
\\ \text{knows:} & & \text{knows:}
\\ \text{reserve keys } w_s, W_p & & \text{reserve public key } W_p
\\ \text{denomination public key } D_p & & \text{denomination keys } d_s, D_p
\\ & &
\\\text{generate withdraw secret:}
\\ \omega := randombytes(32)
\\ \text{persist } \langle \omega, D_p \rangle
\\ n_w := \text{HKDF}(256, \omega,\text{"n"})
\\ & \xrightarrow[\rule{2.5cm}{0pt}]{n_w, D_p} &
% generate R
\\ & & \text{verify if } D_p \text{ is valid}
\\ & & r_0 := \text{HKDF}(256,n_w || d_s, \text{"r0"})
\\ & & r_1 := \text{HKDF}(256,n_w || d_s, \text{"r1"})
\\ & & R_0 := r_0G
\\ & & R_1 := r_1G
\\ & \xleftarrow[\rule{2.5cm}{0pt}]{R_0, R_1} &
\\ \text{derive coin key pair}:
\\ c_s := \text{HKDF}(256, \omega || R_0 || R_1,\text{"cs"})
\\ C_p := \text{Ed25519.GetPub}(c_s)
% blinding
\\ \text{blind:} & &
\\ b_s := \text{HKDF}(256, \omega || R_0 || R_1,\text{"b-seed"})
\\ \alpha_0 := \text{HKDF}(256, b_s, \text{"a0"})
\\ \alpha_1 := \text{HKDF}(256, b_s, \text{"a1"})
\\ \beta_0 := \text{HKDF}(256, b_s, \text{"b0"})
\\ \beta_1 := \text{HKDF}(256, b_s, \text{"b1"})
\\ R'_0 := R_0 + \alpha_0 G + \beta_0 D_p & &
\\ R'_1 := R_1 + \alpha_1 G + \beta_1 D_p & &
\\ c'_0 := H(R'_0, C_p) & &
\\ c'_1 := H(R'_1, C_p) & &
\\ c_0 := c'_0 + \beta_0 \mod p & &
\\ c_1 := c'_1 + \beta_1 \mod p & &
\\
\\ & \textit{Continued in figure \ref{fig:withdrawal-process-schnorr-2}} &
\end{array}$
}
\end{equation*}
\caption{Withdrawal process using Clause Blind Schnorr Signatures part 1}
\label{fig:withdrawal-process-schnorr-1}
\end{figure}
\begin{figure}[htp]
\begin{equation*}
\resizebox{1.0\textwidth}{!}{$\displaystyle
\begin{array}{ l c l }
% preliminaries
\text{Customer} & & \text{Exchange}
\\ \text{knows:} & & \text{knows:}
\\ \text{reserve keys } w_s, W_p & & \text{reserve public key } W_p
\\ \text{denomination public key } D_p & & \text{denomination keys } d_s, D_p
\\
\\ & \textit{Continuation of figure \ref{fig:withdrawal-process-schnorr-1}} &
\\
% sign with reserve sk
\\ \text{sign with reserve private key:} & &
\\ \rho_W := \langle n_w, D_p, c_0, c_1 \rangle & &
\\ \sigma_W := \text{Ed25519.Sign}(w_s, \rho_W) & &
\\ & \xrightarrow[\rule{2.5cm}{0pt}]{W_p, \sigma_W, \rho_W} &
\\ & & \langle n_w, D_p, c_0, c_1 \rangle := \rho_W
% checks done by the exchange
\\ & & \text{verify if } D_p \text{ is valid}
\\ & & \text{check } \text{Ed25519.Verify}(W_p, \rho_W, \sigma_W)
\\ & & b := \text{HKDF}(1,n_w || d_s, \text{"b"})
\\ & & s \leftarrow \text{GetWithdraw}(n_w, D_p)
\\ & & \textbf{if } s = \bot
\\ & & r_b := \text{HKDF}(256,n_w || d_s, \text{"r}b\text{"})
% sign coin
\\ & & s := r_b + c_b d_s \mod p
% the following db operations are atomic
\\ & & \text{decrease balance if sufficient and}
\\ & & \text{persist } \langle n_w, D_p, s \rangle
\\ & & \textbf{endif}
\\ & \xleftarrow[\rule{2.5cm}{0pt}]{b,s} &
% verify signature
\\ \text{verify signature:}& &
\\ \textbf{check if } sG = R_b + c_b D_p & &
% unblind signature
\\ \text{unblind:}& &
\\ s' := s + \alpha_b \mod p & &
\\ \text{verify signature:}& &
\\ \textbf{check if } s'G = R'_b + c'_b D_p & &
\\ \sigma_C := \langle R'_b, s' \rangle & &
\\ \text{resulting coin: } c_s, C_p, \sigma_C, D_p & &
\end{array}$
}
\end{equation*}
\caption{Withdrawal process using Clause Blind Schnorr Signatures part 2}
\label{fig:withdrawal-process-schnorr-2}
\end{figure}
\subsection{Deposit Protocol}
The deposit protocol remains unchanged, except for the verification of the coin signature.
To verify the signature, the exchange has to check if the following equation holds:
\begin{align*}
s'G & = R' + c' D_p
\\ &= R' + H(R', C_p) D_p
\end{align*}
$ s', R' $ together form the signature, $ D_p $ is the denomination public key and $ C_p $ is the coin public key.
Further details regarding the verification process can be found in section \ref{sec:blind-schnorr-sig}.
\subsection{Refresh Protocol}
The refresh protocol blindly signs the new derived coins.
The replacement of \gls{RSABS} with the Clause Blind Schnorr Signature Scheme (see \ref{sec:clause-blind-schnorr-sig}) makes the refresh protocol a bit more complex.
\subsubsection{RefreshDerive Schnorr}
The RefreshDerive protocol is described in figure \ref{fig:refresh-derive-schnorr}.
For this protocol, the main change is that more values need to be derived somehow.
These blinding factors are also derived from $x$.
Then the challenges $\overline{c_0}$ and $\overline{c_1}$ are generated as in the Clause Blind Schnorr Signature Scheme.
\begin{figure}[htp]
\centering
\fbox{%
\procedure[codesize=\small]{$\text{RefreshDerive}(t, D_{p(t)}, C_p, R_0, R_1)$}{%
T := \text{Curve25519.GetPub}(t) \\
x := \textrm{ECDH-EC}(t, C_p) \\
c'_s := \text{HKDF}(256, x, \text{"c"}) \\
C_p' := \text{Ed25519.GetPub}(c'_s) \\
b_s := \text{HKDF}(256, x || R_0 || R_1,\text{"b-seed"}) \\
\alpha_0 := \text{HKDF}(256, b_s, \text{"a0"}) \\
\alpha_1 := \text{HKDF}(256, b_s, \text{"a1"}) \\
\beta_0 := \text{HKDF}(256, b_s, \text{"b0"}) \\
\beta_1 := \text{HKDF}(256, b_s, \text{"b1"}) \\
R'_0 = R_0 + \alpha_0 G + \beta_0 D_p \\
R'_1 = R_1 + \alpha_1 G + \beta_1 D_p \\
c'_0 = H(R'_0, C_p') \\
c'_1 = H(R'_1, C_p') \\
\overline{c_0} = c'_0 + \beta_0 \mod p \\
\overline{c_1} = c'_1 + \beta_1 \mod p \\
\pcreturn \langle T, c'_s, C_p', \overline{c_0}, \overline{c_1} \rangle
}
}
\caption[RefreshDerive algorithm]{The RefreshDerive replaced with Schnorr blind signature details. As before the uses the seed $s$ on the dirty coin for generating the new coin.
The new coin needs to be signed later on with the denomination key.}
\label{fig:refresh-derive-schnorr}
\end{figure}
\subsubsection{Refresh Protocol}
\label{sec:refresh-protocol}
In the commit phase (see figure \ref{fig:refresh-commit-part1}) there needs to be requested an $R_0$ and $R_1$ before deriving the new coins.
There now needs to be calculated two different commit hashes, one for $\overline{c_0}$ and one for $\overline{c_1}$.
The exchange needs to additionally generate a random $b \leftarrow \{0,1\}$ to choose a $\overline{c_b}$.
The reveal phase (see figure \ref{fig:refresh-commit-part2}) now is continued only with the chosen $\overline{c_b}$.
In the reveal phase, the RSA signing and unblinding is exchanged with Schnorr's blind signature counterparts.
\begin{figure}[htp]
\begin{equation*}
\resizebox{1.0\textwidth}{!}{$\displaystyle
\begin{array}{ l c l }
% preliminaries
\text{Customer} & & \text{Exchange}
\\ \text{knows:} & & \text{knows:}
\\ \text{denomination public key } D_p & & \text{old denomination keys } d_{s(0)} D_{p(0)}
\\ \text{coin}_0 = \langle D_{p(0)}, c_s^{(0)}, C_p^{(0)}, \sigma_c^{(0)} \rangle && \text{new denomination keys } d_s, D_P
% request r
\\ & &
\\ \omega := randombytes(32)
\\ \text{persist } \langle \omega, D_p \rangle
%\\ s_w := \text{HKDF}(256, c_s^{(0)},\text{"n"})
\\ n_r := \text{HKDF}(256, \omega,\text{"n"})
% sign with reserve sk
\\ & \xrightarrow[\rule{2.5cm}{0pt}]{n_r, D_p} &
% generate R
\\ & & \text{verify if } D_p \text{ is valid}
\\ & & r_0 := \text{HKDF}(256,n_r || d_s, \text{"r0"})
\\ & & r_1 := \text{HKDF}(256,n_r || d_s, \text{"r1"})
\\ & & R_0 := r_0G
\\ & & R_1 := r_1G
\\ & \xleftarrow[\rule{2cm}{0pt}]{R_0, R_1} &
% refresh request
\\ \textbf{for } i = 1, \dots, \kappa: % generate k derives
%\\ s_i \leftarrow \{0,1\}^{256} % seed generation
\\ t_i := \text{HKDF}(256, \omega || R_0 || R_1,\text{"t} i \text{"} ) % seed generation
\\ X_i := \text{RefreshDerive}(t_i, D_p, C_p^{(0)}, R_0, R_1)
\\ (T_i, c_s^{(i)}, C_p^{(i)}, \overline{c_0}, \overline{c_1}):= X_i
\\ \textbf{endfor}
\\ h_T := H(T_1, \dots, T_k)
\\ h_{\overline{c_0}} := H(\overline{c_{0_1}},\dots, \overline{c}_{0_k})
\\ h_{\overline{c_1}} := H(\overline{c_{1_1}},\dots, \overline{c}_{1_k})
\\ h_{\overline{c}} := H(h_{\overline{c_0}}, h_{\overline{c_1}})
\\ h_C := H(h_T, h_{\overline{c}})
\\ \rho_{RC} := \langle h_C, D_p, \text{ } D_{p(0)}, C_p^{(0)}, \sigma_C^{(0)} \rangle
\\ \sigma_{RC} := \text{Ed25519.Sign}(c_s^{(0)}, \rho_{RC})
\\ \text{Persist refresh-request}
\\ \langle \omega, R_0, R_1, \rho_{RC}, \sigma_{RC} \rangle
\\
\\ & \textit{Continued in figure \ref{fig:refresh-commit-part2}} &
\end{array}$
}
\end{equation*}
\caption{Refresh protocol (commit phase part 1) using Clause Blind Schnorr Signatures}
\label{fig:refresh-commit-part1}
\end{figure}
\begin{figure}[htp]
\begin{equation*}
\resizebox{1.0\textwidth}{!}{$\displaystyle
\begin{array}{ l c l }
\text{Customer} & & \text{Exchange}
\\ & \textit{Continuation of}
\\ & \textit{figure \ref{fig:refresh-commit-part1}}
\\
\\ & \xrightarrow[\rule{2cm}{0pt}]{\rho_{RC}, \sigma_{RC}} &
% Exchange checks refresh request
\\ & & \langle h_C, D_p, D_{p(0)}, C_p^{(0)}, \sigma_C^{(0)} \rangle := \rho_{RC}
\\ & & \textbf{check} \text{ Ed25519.Verify}(C_p^{(0)}, \sigma_{RC}, \rho_{RC})
\\
\\ & & \gamma \leftarrow \text{GetOldRefresh}(\rho_{RC})
\\ & & \textbf{Comment: }\text{GetOldRefresh}(\rho_{RC} \mapsto
\\ & & \{\bot, \gamma \})
\\ & & \pcif \gamma = \bot
\\ & & v := \text{Denomination}(D_p)
\\ & & \textbf{check } \text{IsOverspending}(C_p^{(0)}, D_ {p(0)}, v)
\\ & & \text{verify if } D_p \text{ is valid}
\\ & & \textbf{check } \text{Schnorr.Verify}(D_{p(0)}, C_p^{(0)}, \sigma_C^{(0)})
\\ & & \text{MarkFractionalSpend}(C_p^{(0)}, v)
\\ & & \gamma \leftarrow \{1, \dots, \kappa\}
\\ & & \text{Persist refresh-record } \langle \rho_{RC},\gamma \rangle
\\ & \xleftarrow[\rule{2cm}{0pt}]{\gamma} &
% Check challenge and send challenge response (reveal not selected msgs)
\\ \textbf{check } \text{IsConsistentChallenge}(\rho_{RC}, \gamma)
\\ \textbf{Comment: } \text{IsConsistentChallenge}\\(\rho_{RC}, \gamma) \mapsto \{ \bot,\top \}
\\
\\ \text{Persist refresh-challenge} \langle \rho_{RC}, \gamma \rangle
\\ S := \langle t_1, \dots, t_{\gamma-1}, t_{\gamma+1}, \dots,t_\kappa \rangle % all seeds without the gamma seed
\\ \rho_L := \langle C_p^{(0)}, D_p, T_{\gamma}, \overline{c_0}_\gamma, \overline{c_1}_\gamma, n_r \rangle
\\ \rho_{RR} := \langle \rho_L, S \rangle
\\ \sigma_{L} := \text{Ed25519.Sign}(c_s^{(0)}, \rho_{L})
\\ & \xrightarrow[\rule{2.5cm}{0pt}]{\rho_{RR},\rho_L, \sigma_{L}} &
\\
\\ & \textit{Continued in} &
\\ & \textit{figure \ref{fig:refresh-reveal-part1}} &
\end{array}$
}
\end{equation*}
\caption{Refresh protocol (commit phase part 2) using Clause Blind Schnorr Signatures}
\label{fig:refresh-commit-part2}
\end{figure}
\begin{figure}[htp]
\begin{equation*}
\resizebox{1.0\textwidth}{!}{$\displaystyle
\begin{array}{ l c l }
% preliminaries
\text{Customer} & & \text{Exchange}
\\ & \textit{Continuation of}
\\ & \textit{figure \ref{fig:refresh-commit-part2}}
\\
\\ & \xrightarrow[\rule{2.5cm}{0pt}]{\rho_{RR},\rho_L, \sigma_{L}} &
% check revealed msgs and sign coin
\\ & & \langle C_p^{(0)}, D_p, T_{\gamma}, \overline{c_0}_\gamma, \overline{c_1}_\gamma, n_r \rangle := \rho_L
\\ & & \langle T'_\gamma, \overline{c_0}_\gamma, \overline{c_1}_\gamma, S \rangle := \rho_{RR}
\\ & & \langle t_1,\dots,t_{\gamma-1},t_{\gamma+1},\dots,t_\kappa \rangle := S
\\ & & \textbf{check } \text{Ed25519.Verify}(C_p^{(0)}, \sigma_L, \rho_L)
\\ & & b := \text{HKDF}(1,n_r || d_{s(i)}, \text{"b"})
\\ & & \textbf{for } i = 1,\dots, \gamma-1, \gamma+1,\dots, \kappa
\\ & & X_i := \text{RefreshDerive}(t_i, D_p, C_p^{(0)} \\ &&, R_0, R_1)
\\ & & \langle T_i, c_s^{(i)}, C_p^{(i)}, \overline{c_1}_i, \overline{c_2}_i \rangle := X_i
\\ & & \textbf{endfor}
\\ & & h_T' = H(T_1,\dots,T_{\gamma-1},T'_{\gamma},T_{\gamma+1},\dots,T_\kappa)
\\ & & h_{\overline{c_0}}' := H(\overline{c_{0_1}},\dots, \overline{c}_{0_k})
\\ & & h_{\overline{c_1}}' := H(\overline{c_{1_1}},\dots, \overline{c}_{1_k})
\\ & & h_{\overline{c}}' := H(h_{\overline{c_0}}, h_{\overline{c_1}})
\\ & & h_C' = H(h_T', h_{\overline{c}}')
\\ & & \textbf{check } h_C = h_C'
\\ & & r_b := \text{HKDF}(256,n_r || d_s, \text{"r}b\text{"})
\\ & & \overline{s}_{C_p}^{(\gamma)} = r_b + \overline{c_{b_\gamma}} d_s \mod p
\\ & & \text{persist } \langle \rho_L, \sigma_L \rangle
\\ & \xleftarrow[\rule{2.5cm}{0pt}]{b, \overline{s}_C^{(\gamma)}} &
% Check coin signature and persist coin
% unblind signature
\\ \text{unblind:}& &
\\ s_C'^{(\gamma)} := \overline{s}_C^{(\gamma)} + \alpha_b \mod p & &
\\ \text{verify signature:}& &
\\ \textbf{check if } \overline{s'}_C^{(\gamma)}G \equiv R'_b + \overline{c'_0}_\gamma D_p & &
\\ \sigma_C^{(\gamma)} := \langle s_{C}'^{(\gamma)},R_b' \rangle
\\ \text{Persist coin} \langle D_p, c_s^{(\gamma)}, C_p^{(\gamma)}, \sigma_C^{(\gamma)} \rangle
\end{array}$
}
\end{equation*}
\caption{Refresh protocol (reveal phase) using Clause Blind Schnorr Signatures}
\label{fig:refresh-reveal-part1}
\end{figure}
\newpage
\subsubsection{Linking Protocol}
\label{sec:refresh-link}
The beginning of the linking protocol (see figure \ref{fig:refresh-link}) is the same as in the current protocol.
After the customer received the answer $L$ the only difference is in obtaining the coin.
To re-obtain the derived coin, the same calculations as in \ref{fig:refresh-derive-schnorr} are made.
\begin{figure}[htp]
\begin{equation*}
\resizebox{1.0\textwidth}{!}{$\displaystyle
\begin{array}{ l c l }
% preliminaries
\text{Customer} & & \text{Exchange}
\\ \text{knows:} & & \text{knows:}
\\ \text{coin}_0 = \langle D_{p(0)}, c_s^{(0)}, C_p^{(0)}, \sigma_{C}^{(0)} \rangle
\\ & \xrightarrow[\rule{2.5cm}{0pt}]{C_{p(0)}} &
\\ & & L := \text{LookupLink}(C_{p(0)})
\\ & & \textbf{Comment: } \text{LookupLink}(C_p^{(0)}) \mapsto
\\ & & \{\langle \rho_L^{(i)}, \sigma_L^{(i)}, \overline{\sigma}_C^{(i)}, b \rangle\}
%\\ & & \{\langle C_{p(0)}, D_{p(t)},\overline{\sigma}_C^{(i)}, b^{(i)}, R_b^{(i)}\rangle\}
\\ & \xleftarrow[\rule{2.5cm}{0pt}]{L} &
\\ \textbf{for } \langle \rho_L^{(i)}, \overline{\sigma}_L^{(i)}, \overline{\sigma}_C^{(i)}, b \rangle\ \in L
%\\ & & \langle C_p^{(0)}, D_{p(t)}, T_{\gamma}, \overline{c_0}_\gamma, \overline{c_1}_\gamma, n_r \rangle := \rho_L
\\ \langle \hat{C}_p^{(i)}, D_p^{(i)}, T_\gamma^{(i)}, \overline{c_0}_\gamma^{(i)}, \overline{c_1}_\gamma^{(i)}, n_r \rangle := \rho_L^{(i)}
\\ \langle \overline{s}_C^{(i)}, R_b^{(i)} \rangle := \overline{\sigma}_C^{(i)}
\\ \textbf{check } \hat{C}_p^{(i)} \equiv C_p^{(0)}
\\ \textbf{check } \text{Ed25519.Verify}(C_p^{(0)}, \rho_{L}^{(i)}, \sigma_L^{(i)})
\\ \langle \overline{s}_C^{(i)}, R_b^{(i)} \rangle := \sigma_C^{(i)}
\\ x_i := \text{ECDH}(c_s^{(0)}, T_{\gamma}^{(i)})
\\ c_s^{(i)} := \text{HKDF}(256, x, \text{"c"})
\\ C_p^{(i)} := \text{Ed25519.GetPub}(c_s^{(i)})
\\ b_s^{(i)} := \text{HKDF}(256, x_i || R_0^{(i)} || R_1^{(i)},\text{"b-seed"})
\\ \alpha_b := \text{HKDF}(256, b_s^{(i)}, \text{"a}b\text{"})
\\ \beta_b := \text{HKDF}(256, b_s^{(i)}, \text{"b}b\text{"})
\\ {R'}_b^{(i)} = R_b^{(i)} + \alpha_b G + \beta_b D_p^{(i)}
\\ c'_b = H(R'_b, C_p^{(i)})
\\ c_b = c'_b + \beta_b \mod p
\\ s_C'^{(i)} := \overline{s}_C^{(i)} + \alpha_b \mod p
\\ \sigma_C^{(i)} := \langle s_C'^{(i)}, R_b' \rangle
\\ \textbf{check } s'{_C^{(i)}}G \equiv {R'}_b^{(i)} + c'_b D_p^{(i)}
\\ \text{(Re-)obtain coin} \langle D_p^{(i)},c_s^{(i)}, C_p^{(i)}, \sigma_C^{(i)} \rangle
\end{array}$
}
\end{equation*}
\caption{Linking protocol using Clause Blind Schnorr Signatures}
\label{fig:refresh-link}
\end{figure}
\subsection{Tipping}
Tipping remains unchanged, except for the content of the message $ \rho_W = D_p, c_0, c_1 $ signed by the merchant using its reserve private key.
\subsection{Payback Protocol}
The payback protocol distinguishes three different cases, which all depend on the state of a coin whose denomination key has been revoked.
The following listing outlines the necessary changes on the protocol, please refer to Dold's documentation section 2.2.1 \cite{dold:the-gnu-taler-system} for details regarding the different cases.
\begin{itemize}
\item \textbf{The revoked coin has never been seen by the exchange}:
\\The withdraw transcript (and verification) must be adjusted in order for the exchange to be able to retrace the blinding.
\item \textbf{The coin has been partially spent}:
\\In this case the refresh protocol will be invoked on the coin.
The necessary changes are outlined in \ref{sec:refresh-protocol}.
\item \textbf{The revoked coin has never been seen by the exchange and resulted from a refresh operation}:
\\The refresh protocol transcript and its blinding factors must be adjusted to consider the changes in the blind signature scheme.
\end{itemize}

790
doc/cs/content/4_2_specification.tex Normal file
View File

@ -0,0 +1,790 @@
\chapter{Protocol Specification}
\label{chap:spec}
The proposed Taler protocols using the Clause Blind Schnorr Signature Scheme will be implemented as an additional option besides the existing \gls{RSABS} variant of the protocol as suggested by Christian Grothoff.
A Taler Exchange operator should be able to configure whether he wants to use \gls{RSABS} or \gls{CSBS}.
\\This variant allows to choose the signature scheme globally or per denomination.
Furthermore, it allows a change of signature scheme in a non-breaking way by revoking (or letting expire) a denomination and offering new denominations with the other scheme.
\\
The following key points are specified in this chapter:
\begin{itemize}
\item Architecture of the different components
\item Explain and specify needed changes
\item Data strucutures
\item Public \acp{API}
\item Persistence
\item Used libraries
\end{itemize}
\section{Architecture}
Before specifying the implementation of the different protocols, a deeper understanding of the technical architecture of Talers components is needed.
this section introduces the architecture of the exchange and wallet components and explains where the needed changes need to be implemented on a high-level.
\subsection{Exchange}
An introduction to the exchange can be found in section \ref{sec:exchange}.
An exchange operator needs to run and maintain some additional services besides Taler's exchange.
Although this is not directly relevant for the implementation, it helps to better understand the environment in which the exchange runs.
The perspective of an exchange operator can be seen in figure \ref{fig:taler:exchange-operator-architecture}.
\begin{figure}[h!]
\begin{adjustbox}{max totalsize={.9\textwidth}{.7\textheight},center}
\begin{tikzpicture}
\tikzstyle{def} = [node distance= 5em and 6.5em, inner sep=1em, outer sep=.3em];
\node (origin) at (0,0) {};
\node (exchange) [def,above=of origin,draw]{Exchange};
\node (nexus) [def, draw, below right=of exchange] {Nexus};
\node (corebanking) [def, draw, below left=of nexus] {Core Banking};
\node (nginx) [def, draw, above=of exchange]{Nginx};
\node (postgres) [def, draw, below left=of exchange]{Postgres};
\node (postgres-nexus) [def, draw, below right=of nexus]{Postgres};
\tikzstyle{C} = [color=black, line width=1pt]
\draw [<-, C] (exchange) -- (nginx) node [midway, above, sloped] (TextNode) {REST API};
\draw [<-, C] (postgres) -- (exchange) node [midway, above, sloped] (TextNode) {SQL};
\draw [<-, C] (postgres-nexus) -- (nexus) node [midway, above, sloped] (TextNode) {SQL};
\draw [<-, C] (nexus) -- (exchange) node [midway, above, sloped] (TextNode) {Internal REST API};
\draw [<-, C] (corebanking) -- (nexus) node [midway, above, sloped] (TextNode) {EBICS/FinTS};
\end{tikzpicture}
\end{adjustbox}
\caption{Taler exchange operator architecture (source: \cite{taler-presentation})}
\label{fig:taler:exchange-operator-architecture}
\end{figure}
The software architecture of the exchange can be seen in figure \ref{fig:taler:exchange-architecture}.
The API runs under the httpd service, where the API endpoints need to be adjusted/added to incorporate the changes of this thesis.
The httpd server has no access to the private keys of the denomination and online signing keys.
Only the corresponding security module can perform operations requiring the private key.
Further the keys are also managed by these security modules.
To support \gls{CSBS} a new security module, which performs signature operations, is added.
To persist the new data structures, the postgres helpers need to be adjusted to serialize/deserialize the new \gls{CSBS} data structures.
More details on what changes are needed in these places is discussed in the following sections.
\begin{figure}[h!]
\begin{center}
\begin{tikzpicture}
\tikzstyle{def} = [node distance=2em and 2.5em, inner sep=1em, outer sep=.3em];
\node (origin) at (0,0) {};
\node [blue] (httpd) [def,above=of origin,draw]{httpd};
\node (secmod-rsa) [def, draw, right=of httpd] {secmod-rsa};
\node (secmod-eddsa) [def, draw, left=of httpd] {secmod-eddsa};
\node [blue](postgres) [def, draw, below=of httpd]{Postgres};
\node [mGreen] (secmod-cs) [def, draw, left=of postgres]{secmod-cs};
\node (aggregator) [def, draw, right=of postgres]{aggregator};
\node (transfer) [def, draw, below left=of postgres]{transfer};
\node (wirewatch) [def, draw, below right=of postgres]{wirewatch};
\node (nexus) [def, draw, below=of postgres]{Nexus};
\tikzstyle{C} = [color=black, line width=1pt]
\draw [<->, C] (httpd) -- (postgres) node [midway, above, sloped] (TextNode) {};
\draw [<->, C] (httpd) -- (secmod-rsa) node [midway, above, sloped] (TextNode) {};
\draw [<->, C] (httpd) -- (secmod-eddsa) node [midway, above, sloped] (TextNode) {};
\draw [<->, C] (httpd) -- (secmod-cs) node [midway, above, sloped] (TextNode) {};
\draw [<->, C] (aggregator) -- (postgres) node [midway, above, sloped] (TextNode) {};
\draw [<->, C] (wirewatch) -- (postgres) node [midway, above, sloped] (TextNode) {};
\draw [<->, C] (transfer) -- (postgres) node [midway, above, sloped] (TextNode) {};
\draw [->, C] (transfer) -- (nexus) node [midway, above, sloped] (TextNode) {};
\draw [<-, C] (wirewatch) -- (nexus) node [midway, above, sloped] (TextNode) {};
\end{tikzpicture}
\end{center}
\caption{Taler exchange architecture (source: \cite{taler-presentation})}
\label{fig:taler:exchange-architecture}
\end{figure}
\subsection{Wallet}
The architecture of the wallet implementation (as seen in figure \ref{fig:taler:wallet-architecture}) is quite straightforward.
To add support for \gls{CSBS} in the wallet, the cryptographic routines need to be reimplemented in Typescript.
Taler uses tweetnacl \cite{bern:tweetnacl} which provides functionality for the group operations.
There are existing \gls{hkdf} and \gls{fdh} implementations, that can be reused.\\
Furthermore, the Taler protocols need to be adjusted to support \gls{CSBS} in the wallet-core.
\begin{figure}[h!]
\begin{center}
\begin{tikzpicture}
\tikzstyle{def} = [node distance= 5em and 4.5em, inner sep=1em, outer sep=.3em];
\node (origin) at (0,0) {};
\node (gui) [def,above=of origin,draw]{wallet-gui};
\node [blue](core) [def,below=of gui,draw]{wallet-core};
\node (sync) [def, draw, below left=of core] {Sync};
\node (taler) [def, draw, below right=of core] {Taler};
\node (anastasis) [def, draw, below=of core] {Anastasis};
\tikzstyle{C} = [color=black, line width=1pt]
\draw [<->, C] (gui) -- (core) node [midway, above, sloped] (TextNode) {};
\draw [<->, C] (core) -- (sync) node [midway, above, sloped] (TextNode) {Backup};
\draw [<->, C] (core) -- (taler) node [midway, above, sloped] (TextNode) {Payment};
\draw [<->, C] (core) -- (anastasis) node [midway, above, sloped] (TextNode) {Key Escrow};
\end{tikzpicture}
\end{center}
\caption{Taler wallet architecture (source: \cite{taler-presentation})}
\label{fig:taler:wallet-architecture}
\end{figure}
\section{Persistence}
The Clause Blind Schnorr Signature scheme is quite different to \gls{RSABS}.
Despite the differences, the database model does not need to be changed.
The only change needed an additional type field, specifying whether RSA or CS is used as signature algorithm.
To persist the new structs introduced with the support for \gls{CSBS}, only the postgres helpers need to support serialization and deserialization of the new structs.
\section{Testing}
We will partially use test-driven development, meaning that we will write tests (at least for the known good case) before implementing functions, and extend them during and after development.
This allows us to check the functionality (code section, function(s)) during development, while being able to extend testing whenever we identify new test cases during development.
Test cases can be used to verify different aspects of a functionality.
These are the ones we will focus on.
\begin{itemize}
\item \textbf{Known good}:
Known good cases test whether a functionality works as expected.
They are the most useful during development, because they indicate whether the code is working as expected.
\item \textbf{Known Bad}:
Known bad cases test whether functionality that is known not to work behaves as expected.
\item \textbf{Determinism}:
This case type checks whether the same input leads to the same output.
It is important for code that must work deterministic (same output), non-deterministic (e.g. random output) or based on a state that impacts the functionality.
\item \textbf{Performance testing}:
Performance testing is used to gather timing information that can be used to identify functionality with long duration, or to compare performance between different implementations or major changes.
We will restrict performance testing to the comparison of the Blind RSA Signature Scheme and the Clause Blind Schnorr Signature Scheme.
\end{itemize}
\section{Signature Scheme Operations in GNUnet}
\label{sec:specification-signature-scheme}
The signature scheme operations implemented are needed in all other parts of the implementation.
Taler's cryptographic primitives (e.g. \gls{RSABS}, \gls{hkdf}, hash functions) are mostly implemented in GNUnet utils, therefore the Clause Blind Schnorr Signature routines will be implemented in GNUnet too.
It is important to provide a clear API for the cryptographic routines and to test them thoroughly.
Libsodium will be used for finite field arithmetic (\cite{libsodium:finite-field-arithmetic}) and for other functionality when available (e.g. for key generation).
Thus, a widely used and well tested cryptographic library is used for group operations.
For \acl{FDH} and \gls{hkdf} existing implementations provided by GNUnet are used.
The \gls{hkdf} is used with SHA-512 for the extraction phase and SHA-256 for the expansion phase.
\subsection{Data Structures}
Libsodium represents Ed25519 points and scalars as 32-byte char arrays.
To provide a more user-friendly \ac{API}, structs were created to represent each type.
For example \texttt{struct GNUNET\_CRYPTO\_CsPrivateKey} or \texttt{struct GNUNET\_CRYPTO\_RSecret}
The main reason is to increase readability and to prevent misusage of the \ac{API}.
Unlike RSA, our \gls{CSBS} on Ed25519 data structures have a fixed sizes.
The different data structures can be found in table \ref{tab:datastruct-crypto}.
\begin{table}[ht]
\centering
\resizebox{0.95\textwidth}{!}{\begin{minipage}{\textwidth}
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{lll}
\rowcolor{BFH-tablehead}
\textbf{Values} & \textbf{Data Structure} & \textbf{Data Type} \\\hline
Curve25519 Scalar & {\small GNUNET\_CRYPTO\_Cs25519Scalar} & 32 byte char array\\\hline
Curve25519 Point & {\small GNUNET\_CRYPTO\_Cs25519Point} & 32 byte char array\\\hline
Private Key & {\small GNUNET\_CRYPTO\_CsPrivateKey} & {\small GNUNET\_CRYPTO\_Cs25519Scalar}\\\hline
Public Key & {\small GNUNET\_CRYPTO\_CsPublicKey} & {\small GNUNET\_CRYPTO\_Cs25519Point}\\\hline
$\alpha, \beta$ & {\small GNUNET\_CRYPTO\_CsBlindingSecret} & {\footnotesize 2x GNUNET\_CRYPTO\_Cs25519Scalar}\\\hline
$r$ & {\small GNUNET\_CRYPTO\_CsRSecret} & {\small GNUNET\_CRYPTO\_Cs25519Scalar}\\\hline
$R$ & {\small GNUNET\_CRYPTO\_CsRPublic} & {\small GNUNET\_CRYPTO\_Cs25519Point}\\\hline
$c$ & {\small GNUNET\_CRYPTO\_CsC} & {\small GNUNET\_CRYPTO\_Cs25519Scalar}\\\hline
$s$ & {\small GNUNET\_CRYPTO\_CsBlindS} & {\small GNUNET\_CRYPTO\_Cs25519Scalar}\\\hline
$s'$ & {\small GNUNET\_CRYPTO\_CsS} & {\small GNUNET\_CRYPTO\_Cs25519Scalar}\\\hline
$\sigma := \langle s',R' \rangle$ & {\small GNUNET\_CRYPTO\_CsSignature} & {\small GNUNET\_CRYPTO\_Cs25519Scalar}\\
& & {\small GNUNET\_CRYPTO\_Cs25519Point}\\\hline
Nonce & {\small GNUNET\_CRYPTO\_CsNonce} & 32 byte char array\\\hline
\end{tabular}
\caption{Data structures for cryptographic routines}
\label{tab:datastruct-crypto}
\end{minipage}}
\end{table}
\subsection{Library API}
The public \ac{API} and related data structures are specified in the C header file \url{src/include/gnunet_crypto_lib.h} in the GNUnet repository \cite{gnunet-git}.
It was developed in multiple iterations based on feedback from Christian Grothoff.
The complete C header \ac{API} can be found in the repository.
This section provides an overview of the implemented crypto API.
Some design decisions need to be explained further:
\begin{itemize}
\item In order to prevent misusage of our implementation and increase readability, the functions that represent different stages in the signature scheme takes different data types as in- and output.
Internally most variables are either scalars or curve points (except for nonces, secrets and messages).
\item Operations that are performed twice in the Clause Blind Schnorr Signature Scheme (e.g. derivation of $ r $) do not have to be called twice.
Instead, the API returns an array of two instead of a single value.\\
For these functions, we also optimized the \gls{hkdf} (as proposed by Christian Grothoff).
Instead of calling \gls{hkdf} twice (with different salts, e.g. "r0" and "r1"), we call it one time (e.g. with salt "r") and double the output length.
\item The cryptographic hash function used to derive $ c' $ (hash of $ R' $ and message) must map the results into the main subgroup for scalars, meaning that it has to be a \gls{fdh} (see \ref{sec:rsa-fdh}).
\end{itemize}
The following API examples should provide an overview on how the API works and how to use it.
First of all the API must provide functionality to create a \gls{25519} keypair as in listing \ref{lst:crypto-keypair-api}
\begin{lstlisting}[style=bfh-c,language=C, caption={GNUnet create keypair API}, label={lst:crypto-keypair-api}]
/**
* Create a new random private key.
*
* @param[out] priv where to write the fresh private key
*/
void
GNUNET_CRYPTO_cs_private_key_generate (
struct GNUNET_CRYPTO_CsPrivateKey *priv);
/**
* Extract the public key of the given private key.
*
* @param priv the private key
* @param[out] pub where to write the public key
*/
void
GNUNET_CRYPTO_cs_private_key_get_public (
const struct GNUNET_CRYPTO_CsPrivateKey *priv,
struct GNUNET_CRYPTO_CsPublicKey *pub);
\end{lstlisting}
The signer needs an API to generate his secret $r$ and calculate his public point $R$.
As specified in the redesign of the protocols, the r must not be chosen randomly because we need to provide \textit{\gls{abort-idempotency}}. However, the secret $r$ still needs to be \textit{unpredictable} and look random to the client.
The r\_derive API derives such a secret $r$ from a nonce and a long-term secret with \gls{hkdf}.
Further, the API ensures that a caller must generate two secret $r$ as in the Clause Blind Schnorr Signature scheme. This should discourage people from using the unsecure Blind Schnorr Signature scheme. See \ref{lst:crypto-rderive-api}.
\begin{lstlisting}[style=bfh-c,language=C, caption={GNUnet r derive API}, label={lst:crypto-rderive-api}]
/**
* Derive a new secret r pair r0 and r1.
* In original papers r is generated randomly
* To provide abort-idempotency, r needs to be derived but still needs to be UNPREDICTABLE
* To ensure unpredictability a new nonce should be used when a new r needs to be derived.
* Uses HKDF internally.
* Comment: Can be done in one HKDF shot and split output.
*
* @param nonce is a random nonce
* @param lts is a long-term-secret in form of a private key
* @param[out] r array containing derived secrets r0 and r1
*/
void
GNUNET_CRYPTO_cs_r_derive (const struct GNUNET_CRYPTO_CsNonce *nonce,
const struct GNUNET_CRYPTO_CsPrivateKey *lts,
struct GNUNET_CRYPTO_CsRSecret r[2]);
/**
* Extract the public R of the given secret r.
*
* @param r_priv the private key
* @param[out] r_pub where to write the public key
*/
void
GNUNET_CRYPTO_cs_r_get_public (const struct GNUNET_CRYPTO_CsRSecret *r_priv,
struct GNUNET_CRYPTO_CsRPublic *r_pub);
\end{lstlisting}
Same as the r\_derive, the blinding secrets are also derived and not generated randomly.
The blinding secrets are generated by a client who provides a secret as seed to derive the secrets from as in listing \ref{lst:crypto-blinding-secrets-api}.
\begin{lstlisting}[style=bfh-c,language=C, caption={GNUnet blinding secrets derive API}, label={lst:crypto-blinding-secrets-api}]
/**
* Derives new random blinding factors.
* In original papers blinding factors are generated randomly
* To provide abort-idempotency, blinding factors need to be derived but still need to be UNPREDICTABLE
* To ensure unpredictability a new nonce has to be used.
* Uses HKDF internally
*
* @param secret is secret to derive blinding factors
* @param secret_len secret length
* @param[out] bs array containing the two derivedGNUNET_CRYPTO_CsBlindingSecret
*/
void
GNUNET_CRYPTO_cs_blinding_secrets_derive (
const struct GNUNET_CRYPTO_CsNonce *blind_seed,
struct GNUNET_CRYPTO_CsBlindingSecret bs[2]);
\end{lstlisting}
Further the Clause Blind Schnorr API provides an API to calculate the two blinded c of the message with the two public $R$, the blinding factors and the public key as in listing \ref{lst:crypto-calc-c-api}.
\begin{lstlisting}[style=bfh-c,language=C, caption={GNUnet calculate blinded c API}, label={lst:crypto-calc-c-api}]
/**
* Calculate two blinded c's
* Comment: One would be insecure due to Wagner's algorithm solving ROS
*
* @param bs array of the two blinding factor structs each containing alpha and beta
* @param r_pub array of the two signer's nonce R
* @param pub the public key of the signer
* @param msg the message to blind in preparation for signing
* @param msg_len length of message msg
* @param[out] blinded_c array of the two blinded c's
*/
void
GNUNET_CRYPTO_cs_calc_blinded_c (
const struct GNUNET_CRYPTO_CsBlindingSecret bs[2],
const struct GNUNET_CRYPTO_CsRPublic r_pub[2],
const struct GNUNET_CRYPTO_CsPublicKey *pub,
const void *msg,
size_t msg_len,
struct GNUNET_CRYPTO_CsC blinded_c[2]);
\end{lstlisting}
The sign function in our API is called sign\_derive, since we derive $b \in \{0,1\}$ from the long-term secret and then calculate the signature scalar of $c_b$.
See listing \ref{lst:crypto-sign-api}.
\begin{lstlisting}[style=bfh-c,language=C, caption={GNUnet sign API}, label={lst:crypto-sign-api}]
/**
* Sign a blinded c
* This function derives b from a nonce and a longterm secret
* In original papers b is generated randomly
* To provide abort-idempotency, b needs to be derived but still need to be UNPREDICTABLE.
* To ensure unpredictability a new nonce has to be used for every signature
* HKDF is used internally for derivation
* r0 and r1 can be derived prior by using GNUNET_CRYPTO_cs_r_derive
*
* @param priv private key to use for the signing and as LTS in HKDF
* @param r array of the two secret nonce from the signer
* @param c array of the two blinded c to sign c_b
* @param nonce is a random nonce
* @param[out] blinded_signature_scalar where to write the signature
* @return 0 or 1 for b (see Clause Blind Signature Scheme)
*/
int
GNUNET_CRYPTO_cs_sign_derive(
const struct GNUNET_CRYPTO_CsPrivateKey *priv,
const struct GNUNET_CRYPTO_CsRSecret r[2],
const struct GNUNET_CRYPTO_CsC c[2],
const struct GNUNET_CRYPTO_CsNonce *nonce,
struct GNUNET_CRYPTO_CsBlindS *blinded_signature_scalar);
\end{lstlisting}
The API for the unblind operation can be called with the blinding secrets and the signature scalar received from the signer as in listing \ref{lst:crypto-unblind-api}.
\begin{lstlisting}[style=bfh-c,language=C, caption={GNUnet unblind API}, label={lst:crypto-unblind-api}]
/**
* Unblind a blind-signed signature using a c that was blinded
*
* @param blinded_signature_scalar the signature made on the blinded c
* @param bs the blinding factors used in the blinding
* @param[out] signature_scalar where to write the unblinded signature
*/
void
GNUNET_CRYPTO_cs_unblind (
const struct GNUNET_CRYPTO_CsBlindS *blinded_signature_scalar,
const struct GNUNET_CRYPTO_CsBlindingSecret *bs,
struct GNUNET_CRYPTO_CsS *signature_scalar);
\end{lstlisting}
The verify API takes the message and its signature with the public key and returns GNUNET\_OK for a valid signature and GNUNET\_SYSERR otherwhise.
See listing \ref{lst:crypto-verify-api}.
\begin{lstlisting}[style=bfh-c,language=C,, caption={GNUnet verify API}, label={lst:crypto-verify-api}]
/**
* Verify whether the given message corresponds to the given signature and the
* signature is valid with respect to the given public key.
*
* @param sig signature that is being validated
* @param pub public key of the signer
* @param msg is the message that should be signed by @a sig (message is used to calculate c)
* @param msg_len is the message length
* @returns #GNUNET_YES on success, #GNUNET_SYSERR if signature invalid
*/
enum GNUNET_GenericReturnValue
GNUNET_CRYPTO_cs_verify (const struct GNUNET_CRYPTO_CsSignature *sig,
const struct GNUNET_CRYPTO_CsPublicKey *pub,
const void *msg,
size_t msg_len);
\end{lstlisting}
\subsection{Testing}
For digital signature schemes, the most important test case is the \textit{known good} case where a signature is created and successfully validated.
This test case already tests very much in a digital signature scheme.
When the signature creation or verification has a bug, a test will not succeed, because the mathematic operations need to be correct to be validated correctly.
The cryptographic operations are further tested for deterministicy (where it applies), meaning that multiple function calls with the same input must lead to the same output.
Since libsodium is used for the finite field arithmetic operations and is a well tested library, many cryptographic tests are already done in libsodium.
The performance is measured in a benchmark to see how performant \gls{CSBS} are in comparison to the RSA Blind Signature Scheme.
\section{Taler Cryptographic Utilities}
Taler provides utility functions to support cryptographic operations.\\
This chapter provides an overview of these utility functions and about the functionality they provide.
\subsection{Planchet Creation}
In crypto.c many utility functions are provided to create planchets (for planchet details see \ref{fig:coin:states}), blinding secrets and much more.
One difference between \gls{RSABS} and \gls{CSBS} is, that the coin private key and RSA blinding secret can be created at the same point in time, since the RSA blinding secret is created randomly.
However, for Clause Blind Schnorr secrets an additional step is needed, the public $R_0$ and $R_1$ are required to calculate the blinding seed to derive the secrets.
A planchet in the Clause Blind Schnorr Signature Scheme can be created as followed (implementation details ommited).
\begin{enumerate}
\item Create planchet with new \ac{EdDSA} private key
\item Derive withdraw nonce
\item Request public $R_0, R_1$ from signer
\item Derive blinding seed
\item Prepare (blind) the planchet
\end{enumerate}
After the planchet is created, it is sent to the exchange to be signed.
\subsection{Taler CS Security Module}
The exchange segregates access to the private keys with separate security module processes.
The security module has sole access to the private keys of the online signing keys and thus, only a security module can create signatures.
The different \textit{taler-exchange-secmod} processes (separated by signature scheme) are managing the exchanges online signing keys. The RSA denomination keys for example are managed with \textit{taler-exchange-secmod-rsa}.
Now a new \textit{taler-exchange-secmod-cs} needs to be created for managing the \gls{CSBS} denomination keys.
These security modules run on the same machine as the httpd process and they use UNIX Domain Sockets as method for \acl{IPC}.
A short introduction about UNIX Domain Sockets can be found in the blog post \cite{matt:unix-domain-sockets}.
Furthermore, the security modules are used to protect the online signing keys by performing the actual signing operations in the dedicated taler-secmod-cs process.
This abstraction makes it harder for an attacker who has already compromised the http daemon to gain access to the private keys.
However, such an attacker would still be able to sign arbitrary messages (see \cite{taler-documentation:exchange-operator-manual}).
A crypto helper exists for each security module, these functions can be called inside the exchange for operations requiring the private online signing keys.
The new Clause Schnorr security module and corresponding crypto helper provides the following functionality:
\begin{itemize}
\item Private Key Management and creation
\item Request public $R_0, R_1$
\item Request a signature of a $c_0,c_1$ pair
\item Revoke an online signing key
\end{itemize}
\subsection{Testing}
All of the operations have tests and are included in unit tests.
As a template for testing, the existing RSA tests were used and adjusted for \gls{CSBS}.
\section{Denomination Key Management}
Since we introduce a type of denomination keys, related operations like connection to the \gls{CSBS} security module, making the denominations available for customers, persisting them in the database and offline signing using the exchange's offline signature key have to be extended to incorporate the \acl{CS}.
The exchange offline signer requests the future, not yet signed keys by calling GET \url{/management/keys} as described in table \ref{tab:management-keys-get}. \\\\
\framebox[1.1\width]{\color{blue}\texttt{GET /management/keys}}
\begin{table}[ht]
\centering
\resizebox{0.9\textwidth}{!}{\begin{minipage}{\textwidth}
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{ll}
\rowcolor{BFH-tablehead}
\textbf{Field} & \textbf{Value} \\
future\_denoms & Information about denomination keys \\
future\_signkeys & Information about exchange online signing keys \\
master\_pub & Exchange's master public key \\
denom\_secmod\_public\_key & RSA security module public key \\
denom\_secmod\_cs\_public\_key & \gls{CSBS} security module public key \\
signkey\_secmod\_public\_key & Online singing security module public key \\
\end{tabular}
\caption{GET \url{/management/keys} response data}
\label{tab:management-keys-get}
\end{minipage}}
\end{table}
It then signs the keys and returns them using POST on the same \ac{URL} with the data described in table \ref{tab:management-keys-post}. \\\\
\framebox[1.1\width]{\color{blue}\texttt{POST /management/keys}}
\begin{table}[ht]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{ll}
\rowcolor{BFH-tablehead}
\textbf{Field} & \textbf{Value} \\
denom\_sigs & Denomination key signatures \\
signkey\_sigs & Online signing key signatures \\
\end{tabular}
\caption{POST \url{/management/keys} response data}
\label{tab:management-keys-post}
\end{table}
Wallets can then call GET \url{/keys} to obtain the current denominations and other information, the response is described in table \ref{tab:keys-get}. \\\\
\framebox[1.1\width]{\color{blue}\texttt{GET /keys}}
\begin{table}[ht]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{ll}
\rowcolor{BFH-tablehead}
\textbf{Field} & \textbf{Value} \\
version & Exchange's protocol version \\
currency & Currency \\
master\_public\_key & Exchange's master public key \\
reserve\_closing\_delay & Delay before reserves are closed \\
signkeys & Exchange's online signing public keys \\
recoup & Revoked keys \\
denoms & List of denominations \\
auditors & Auditors for this exchange \\
list\_issue\_date & Timestamp \\
eddsa\_pub & Exchange's online signing public key \\
eddsa\_sig & Signature (use "eddsa\_pub" for verification) \\
\end{tabular}
\caption{GET \url{/keys} response data}
\label{tab:keys-get}
\end{table}
\section{New Endpoint for $R$}
The withdraw and refresh protocols using the Claude Blind Schnorr Signature Scheme introduce an additional round trip.
In this round trip, the customer requests two $ R $ from the exchange.
The exchange uses a secret $ r $ to calculate $ R := rG $.
\\
In contrast to the plain Clause Blind Schnorr Signature Scheme (see \ref{sec:clause-blind-schnorr-sig}), $ r $ isn't generated randomly but instead derived using a \gls{hkdf} with a nonce from the customer and a denomination private key (secret only known by the exchange).
This still ensures that the private $ r $ can't be anticipated, but has multiple advantages regarding \gls{abort-idempotency}.
\Gls{abort-idempotency} means that a withdraw or refresh operation can be aborted in any step and later tried again (using the same values) without yielding a different result.
The challenge for $ r, R $ regarding \gls{abort-idempotency} is to ensure that the same $ r $ is used during the complete signature creation process.
The only drawback of this process is that we have to ensure that the same nonce and secret aren't used for different withdraw- or refresh-operations.
This is done during signature creation and will be described in the withdraw protocol section \ref{sec:specification-withdraw}.
\subsection{Public APIs and Data Structures}
This is a new functionality, meaning a new endpoint accessible to customers has to be introduced.
It will be made available in the exchange HTTP server under \framebox[1.1\width]{\color{blue}\texttt{POST /csr}} and will take the input parameters described in table \ref{tab:csr-request-data} (as \ac{JSON}).
\begin{table}[ht]
\centering
\resizebox{0.9\textwidth}{!}{\begin{minipage}{\textwidth}
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{lll}
\rowcolor{BFH-tablehead}
\textbf{Field} & \textbf{Type} & \textbf{Value} \\
nonce & String & 32 Bytes encoded in Crockford base32 Hex \\
denom\_pub\_hash & String & Denomination Public Key encoded in Crockford base32 Hex \\
\end{tabular}
\caption{POST \url{/csr} request data}
\label{tab:csr-request-data}
\end{minipage}}
\end{table}
The exchange will then check the denomination and return one of these HTTP status codes:
\begin{itemize}
\item \textbf{200 (HTTP\_OK)}: Request Successful
\item \textbf{400 (BAD\_REQUEST)}: Invalid input parameters
\item \textbf{404 (NOT\_FOUND)}: Denomination unknown or not Clause Schnorr
\item \textbf{410 (GONE)}: Denomination revoked/expired
\item \textbf{412 (PRECONDITION\_FAILED)}: Denomination not yet valid
\end{itemize}
When the request was successful, the exchange returns the data described in table \ref{tab:csr-response-data} (as \ac{JSON}).
\begin{table}[ht]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{lll}
\rowcolor{BFH-tablehead}
\textbf{Field} & \textbf{Type} & \textbf{Value} \\
r\_pub\_0 & String & 32 Bytes encoded in Crockford base32 Hex \\
r\_pub\_1 & String & 32 Bytes encoded in Crockford base32 Hex \\
\end{tabular}
\caption{POST \url{/csr} response data}
\label{tab:csr-response-data}
\end{table}
\subsection{Persistence}
This API does not persist anything.
This is because the resulting $R_0, R_1$ are derived and can be derived in a later step.
\section{Withdraw Protocol}
\label{sec:specification-withdraw}
The withdraw protocol has been introduced in section \ref{sec:withdrawal}.
For the \acl{CS} necessary adjustments are described in section \ref{sec:withdraw-protocol-schnorr}.
\subsection{Public APIs and Data Structures}
\label{sec:specification-withdraw-public-api}
The existing endpoint is available under \texttt{POST /reserves/[reserve]/withdraw} where "reserve" is the reserve public key encoded as Crockford base32.
It takes the following input parameters described in table \ref{tab:withdraw-request-data} as JSON.\\\\
\framebox[1.1\width]{\color{blue}\texttt{POST /reserves/[reserve]/withdraw}}
\begin{table}[ht]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{ll}
\rowcolor{BFH-tablehead}
\textbf{Field} & \textbf{Value} \\
denom\_pub\_hash & Denomination Public Key \\
coin\_ev & RSA blinded coin public key \\
reserve\_sig & Signature over the request using the reserve's private key \\
\end{tabular}
\caption{Withdraw request data}
\label{tab:withdraw-request-data}
\end{table}
In order to facilitate parsing, Christian Grothoff suggested to include the cipher type in the "coin\_ev" field, thus creating a nested \ac{JSON} (as described in table \ref{tab:withdraw-coin-ev-rsa}).
\begin{table}[ht]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{lll}
\rowcolor{BFH-tablehead}
\textbf{Field} & \textbf{Type} & \textbf{Value} \\
cipher & Integer & Denomination cipher: 1 stands for RSA \\
rsa\_blinded\_planchet & String & RSA blinded coin public key \\
\end{tabular}
\caption{Withdraw "coin\_ev" field (RSA)}
\label{tab:withdraw-coin-ev-rsa}
\end{table}
For the Clause Schnorr implementation, the field "rsa\_blinded\_planchet" will be replaced with the necessary values as described in table \ref{tab:withdraw-coin-ev-cs}.
\begin{table}[ht]
\centering
\resizebox{0.85\textwidth}{!}{\begin{minipage}{\textwidth}
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{lll}
\rowcolor{BFH-tablehead}
\textbf{Field} & \textbf{Type} & \textbf{Value} \\
cipher & Integer & Denomination cipher: 2 stands for \gls{CSBS} \\
cs\_nonce & String & 32 Bytes encoded in Crockford base32 Hex \\
cs\_blinded\_c0 & String & 32 Bytes encoded in Crockford base32 Hex \\
cs\_blinded\_c1 & String & 32 Bytes encoded in Crockford base32 Hex \\
\end{tabular}
\caption{Withdraw "coin\_ev" field (\gls{CSBS})}
\label{tab:withdraw-coin-ev-cs}
\end{minipage}}
\end{table}
The exchange will then process the withdraw request and return one of these HTTP status codes:
\begin{itemize}
\item \textbf{200 (HTTP\_OK)}: Request Successful
\item \textbf{400 (BAD\_REQUEST)}: Invalid input parameters (can also happen if denomination cipher doesn't match with cipher in "coin\_ev")
\item \textbf{403 (FORBIDDEN)}: Signature contained in "reserve\_sig" invalid
\item \textbf{404 (NOT\_FOUND)}: Denomination unknown
\item \textbf{410 (GONE)}: Denomination revoked/expired
\item \textbf{412 (PRECONDITION\_FAILED)}: Denomination not yet valid
\end{itemize}
When the request was successful, the exchange returns the RSA signature as JSON (described in table \ref{tab:withdraw-response-rsa}).
\begin{table}[ht]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{lll}
\rowcolor{BFH-tablehead}
\textbf{Field} & \textbf{Type} & \textbf{Value} \\
cipher & Integer & Denomination cipher: 1 stands for RSA \\
blinded\_rsa\_signature & String & RSA signature \\
\end{tabular}
\caption{Withdraw response (RSA)}
\label{tab:withdraw-response-rsa}
\end{table}
Table \ref{tab:withdraw-response-cs} describes the response for \gls{CSBS}.
\begin{table}[ht]
\centering
\resizebox{0.85\textwidth}{!}{\begin{minipage}{\textwidth}
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{lll}
\rowcolor{BFH-tablehead}
\textbf{Field} & \textbf{Type} & \textbf{Value} \\
cipher & Integer & Denomination cipher: 2 stands for \gls{CSBS} \\
b & Integer & \gls{CSBS} signature session identifier (either 0 or 1) \\
s & String & signature scalar (32 Bytes encoded in Crockford base32 Hex) \\
\end{tabular}
\caption{Withdraw response (\gls{CSBS})}
\label{tab:withdraw-response-cs}
\end{minipage}}
\end{table}
\subsection{Persistence}
Persistence for withdrawing is implemented in the function \texttt{postgres\_do\_withdraw} in \texttt{src/exchangedb/plugin\_exchangedb\_postgres.c}
For \gls{CSBS}, persisting the blinded signature must be implemented.
\section{Deposit Protocol}
For the deposit protocol (described in section \ref{sec:deposit-protocol}) only the handling and verification of \gls{CSBS} signatures has to be added.
\subsection{Public APIs and Data Structures}
Deposit is an existing endpoint available under \texttt{POST /coins/[coin public key]/deposit} where "coin public key" is encoded as Crockford base32.
Additional parameters are passed as JSON (as described in table \ref{tab:spend-request}).\\\\
\framebox[1.1\width]{\color{blue}\texttt{POST /coins/[coin public key]/deposit}}
\begin{table}[ht]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{ll}
\rowcolor{BFH-tablehead}
\textbf{Field} & \textbf{Value} \\
% cipher & Denomination cipher: 2 stands for \gls{CSBS} \\
% b & \gls{CSBS} signature session identifier (either 0 or 1) \\
% s & signature scalar (32 Bytes encoded in Crockford base32 Hex) \\
merchant\_payto\_uri & Account that is credited \\
wire\_salt & Salt used by the merchant \\
contribution & Amount to use for payment (for one specific coin) \\
denom\_pub\_hash & Denomination public key hash \\
ub\_sig & (unblinded) denomination signature of coin \\
merchant\_pub & Merchant public key \\
h\_contract\_terms & Contract terms hash \\
coin\_sig & Deposit permission signature \\
timestamp & Timestamp of generation \\
refund\_deadline (optional) & Refund deadline \\
wire\_transfer\_deadline (optional) & Wire transfer deadline \\
\end{tabular}
\caption{Spend request}
\label{tab:spend-request}
\end{table}
Relevant field for the \gls{CSBS} implementation is the field "ub\_sig" containing the unblinded denomination signature of the coin.
For RSA, the (nested) \ac{JSON} is described in table \ref{tab:spend-request-ubsig-rsa}.
\begin{table}[ht]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{lll}
\rowcolor{BFH-tablehead}
\textbf{Field} & \textbf{Type} & \textbf{Value} \\
cipher & Integer & Denomination cipher: 1 stands for RSA \\
rsa\_signature & String & Unblinded RSA signature \\
\end{tabular}
\caption{ub\_sig (RSA)}
\label{tab:spend-request-ubsig-rsa}
\end{table}
Table \ref{tab:spend-request-ubsig-cs} describes the values in "ub\_sig" required for \gls{CSBS}.
\begin{table}[ht]
\centering
\resizebox{0.85\textwidth}{!}{\begin{minipage}{\textwidth}
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{lll}
\rowcolor{BFH-tablehead}
\textbf{Field} & \textbf{Type} & \textbf{Value} \\
cipher & Integer & Denomination cipher: 2 stands for \gls{CSBS} \\
cs\_signature\_r & String & Curve point $ R' $ (32 Bytes encoded in Crockford base32 Hex) \\
cs\_signature\_s & String & Signature scalar (32 Bytes encoded in Crockford base32 Hex) \\
\end{tabular}
\caption{ub\_sig (\gls{CSBS})}
\label{tab:spend-request-ubsig-cs}
\end{minipage}}
\end{table}
\subsection{Persistence}
Persistence is handled in the functions \texttt{postgres\_insert\_deposit} and\\ \texttt{postgres\_have\_deposit} located in \url{src/exchangedb/plugin_exchangedb_postgres.c}.
However, these functions are not containing \gls{CSBS}-specific persistence.
\\What needs to be adjusted however, is the function \texttt{postgres\_ensure\_coin\_known} called by the function \texttt{TEH\_make\_coin\_known} (located in \url{src/exchange/taler-exchange-httpd_db.c}).
% \section{Tipping}
% \subsection{Public APIs and Data Structures}
% \subsection{Code Location}
% \subsection{Persistence}
% \subsection{Used Libraries}
% \section{Payback Protocol}
% \subsection{Public APIs and Data Structures}
% \subsection{Code Location}
% \subsection{Persistence}
% \subsection{Used Libraries}
% sollte ein Product Backlog das Ziel dieser Phase sein?

333
doc/cs/content/4_3_implementation.tex Normal file
View File

@ -0,0 +1,333 @@
\chapter{Implementation}
\label{chap:implement}
This chapter gives an overview on the implementation challenges and discusses special parts in the implementation.
\section{Signature Scheme Operations}
The signature scheme operations are implemented in the GNUnet core repository \cite{gnunet-git} (and have been merged into the master branch).
This would allow other GNUnet projects to use our implementation of the Clause Blind Schnorr Signature Scheme.
The implementation is done in multiple locations:
\begin{itemize}
\item \texttt{src/include/gnunet\_crypto\_lib.h}:
This header file is included when using GNUnet's cryptography implementation.
\item \texttt{src/util/crypto\_cs.c}:
The functions specified in \texttt{gnunet\_crypto\_lib.h} will be implemented here.
\item \texttt{src/util/test\_crypto\_cs.c}:
The test cases for the signature scheme will be implemented here.
\item \texttt{src/util/perf\_crypto\_cs.c}:
This file houses the implementation of a small program that will be used to compare the performance against the blind RSA Signature Scheme.
\end{itemize}
The specification explaining the \ac{API} can be found in section \ref{sec:specification-signature-scheme}. There are two internal functions that have to be explained further in this section.
The \texttt{map\_to\_scalar\_subgroup} function clamps scalars, which is necessary for values that are derived using a \gls{hkdf}.
It sets the three least significant bits to zero (making the scalar a multiple of 8), sets the most significant bit to zero and the second-most significant bit to one.
This process is further described in \cite{rfc7748} and \cite{madden:curve25519-clamping}.
\begin{lstlisting}[style=bfh-c, language=C, caption={Function map\_to\_scalar\_subgroup - Crypto API}, label={lst:map-to-scalar}]
static void
map_to_scalar_subgroup (struct GNUNET_CRYPTO_Cs25519Scalar *scalar)
{
scalar->d[0] &= 248;
scalar->d[31] &= 127;
scalar->d[31] |= 64;
}
\end{lstlisting}
Another important function is the \gls{fdh} (see \ref{sec:schnorr-sig}) used to map the message to a scalar.
GNUnet provides a \gls{fdh} function, which expects libgcrypt's multi precision format.
A conversion function is provided by GNUnet, which requires the data to be in big endian format.
Since libsodium uses a little endian representation, the conversion process must include endianness conversion.
The complete \gls{fdh} including the required conversions is implemented in the function described in listing \ref{lst:cs-fdh}.
\begin{lstlisting}[style=bfh-c, language=C, caption={Function cs\_full\_domain\_hash - Crypto API}, label={lst:cs-fdh}]
static void
cs_full_domain_hash (const struct GNUNET_CRYPTO_CsRPublic *r_dash,
const void *msg,
size_t msg_len,
const struct GNUNET_CRYPTO_CsPublicKey *pub,
struct GNUNET_CRYPTO_CsC *c)
{
...
\end{lstlisting}
Last but not least, the implementation has one notable performance improvement not mentioned in the redesigned protocols.
In various steps \gls{hkdf} is used multiple times in a row.
For example to derive the four blinding secrets $\alpha_0, \alpha_1, \beta_0, \beta_1$.
The derivation can be done in one \gls{hkdf} call with bigger output size, 128 bit in this case.
The output then can be split in four parts and then mapped to the ed25519 subgroup.
This can be done secure, because as explained in \autoref{sec:kdf} a \gls{hkdf} output is truly random.
\section{Taler Cryptographic Utilities}
\begin{bfhNoteBox}
Implementation is done in Taler's exchange.
From here on the implementation can be found in the exchange git repository \cite{taler-git:exchange}.
\end{bfhNoteBox}
The cryptographic utilities of Taler can be found in \texttt{src/util}.
The implementation is done in various locations:
\begin{itemize}
\item \texttt{src/include/taler\_crypto\_lib.h}: This header file is included when using Taler's cryptography implementation.
The different data structures and functionality are defined here.
\item \texttt{src/util/denom.c}: Implement denomination utility functions for \gls{CSBS} cases
\item \texttt{src/util/crypto.c}: Adjust all utility functions to support \gls{CSBS}.
crypto.c contains many cryptographic utility functions, for example to create planchets or blinding factors.
\item \texttt{src/util/test\_crypto.c}: Functionality tests for crypto.c and denom.c
\item \texttt{src/include/taler\_signatures.h}: In this header file message formats and signature constants are defined (not modified)
\item \texttt{src/util/secmod\_signatures.c}: Utility functions for Taler security module signatures
\end{itemize}
The security module \texttt{taler-secmod-cs} is implemented here:
\begin{itemize}
\item \texttt{src/util/taler-exchange-secmod-cs.c}: Standalone process to perform private key Clause Blind Schnorr signature operations.
\item \texttt{src/util/taler-exchange-secmod-cs.h}: Specification of \ac{IPC} messages for the CS secmod process
\item \texttt{src/util/taler-exchange-secmod-cs.conf}: Configuration file for the secmod process
\item \texttt{src/util/secmod\_common.c} and \texttt{src/util/secmod\_common.h}: Common functions for the exchange's security modules (not modified)
\end{itemize}
The corresponding crypto helper, that talks with the security module, and its tests \& benchmarks are implemented here:
\begin{itemize}
\item \texttt{src/util/crypto\_helper\_cs.c}: Utility functions to communicate with the security module
\item \texttt{src/util/crypto\_helper\_common.c}: and \texttt{crypto\_helper\_common.h}: Common functions for the exchange security modules (not modified)
\item \texttt{src/util/test\_helper\_cs.c}: Tests and benchmarks for the \gls{CSBS} crypto helper
\end{itemize}
% Crypto API offene Punkte:
%Input-Validierung von Punkten und Skalar
% Clamping beschreiben: https://neilmadden.blog/2020/05/28/whats-the-curve25519-clamping-all-about/
% Testing: inverse operations, blinded signature test
\section{Denomination Key Management}
For the implementation, the \gls{CSBS} security module had to be connected to the key handling and the \gls{CSBS} denominations had to be integrated:
\begin{itemize}
\item \url{src/exchange/taler-exchange-httpd_keys.h} and \\
\url{src/exchange/taler-exchange-httpd_keys.c}: Integrate \gls{CSBS} secmod and denomination key management
\item \url{src/exchange-tools/taler-exchange-offline.c}: Implement \gls{CSBS} case for offline signing of denomination keys
\item \url{src/include/taler_exchange_service.h}: \\
Add \gls{CSBS} secmod public key to struct\\TALER\_EXCHANGE\_FutureKeys
\item \url{src/json/json_helper.c}: Implement CS case in function parse\_denom\_pub (used in taler-exchange-offline.c)
\item \url{src/json/json_pack.c}: Implement \gls{CSBS} case in function TALER\_JSON\_pack\_denom\_pub (used in taler-exchange-httpd\_keys.c)
\item \url{src/pq/pq_query_helper.c}: Implement \gls{CSBS} case in function qconv\_denom\_pub
\item \url{src/pq/pq_result_helper.c}: Implement \gls{CSBS} case in function extract\_denom\_pub
\end{itemize}
In order for the tests to pass, the following changes had to be implemented:
\begin{itemize}
\item \url{src/lib/exchange_api_management_get_keys.c}: Add denom\_secmod\_cs\_public\_key JSON parsing, implement \gls{CSBS} case \\in function TALER\_EXCHANGE\_ManagementGetKeysHandle
\item \url{src/testing/.gitignore}: Add paths where \gls{CSBS} keys are stored (secmod-helper)
\item \url{src/testing/test_auditor_api.conf}: Add section taler-exchange-secmod-cs
\item \url{src/testing/test_exchange_api_keys_cherry_picking.conf}: Add section taler-exchange-secmod-cs
\item \url{src/testing/testing_api_helpers_exchange.c}: Add \gls{CSBS} secmod start and stop logic
\end{itemize}
\section{New Endpoint for $R$}
The new endpoint is available in the exchange's HTTP server under \url{/csr}.
It parses and checks the input, passes the request for derivation of the two $ R $'s down to the \gls{CSBS} security module and returns them to the requestor.
The implementation can be found in:
\begin{itemize}
\item \url{src/exchange/taler-exchange-httpd.c}:
Definition for the new endpoint, calls the function that handles \url{/csr} requests
\item \url{src/exchange/taler-exchange-httpd_responses.h} and \\
\url{src/exchange/taler-exchange-httpd_responses.c}: \\
Added function TEH\_RESPONSE\_reply\_invalid\_denom\_cipher\_for\_operation that indicates a failure when the endpoint is called for a non-\gls{CSBS} denomination
\item \url{src/exchange/taler-exchange-httpd_csr.h} and \\
\url{src/exchange/taler-exchange-httpd_csr.c}: \\
Implementation of the request handler for the new endpoint
\item \url{src/exchange/taler-exchange-httpd_keys.h} and \\
\url{src/exchange/taler-exchange-httpd_keys.c}: \\
Additional function TEH\_keys\_denomination\_cs\_r\_pub that passes down the request to derive the $ R $ to the taler-exchange-secmod-cs helper
\end{itemize}
The tests that check the functionality of the procotols are defined in \url{src/testing/} and use code that calls the \ac{API} (located in \url{src/lib/}).
Since the new endpoint is used during withdrawing coins, testing for the \url{/csr} endpoint is integrated in these protocol tests.
Therefore, a call to the endpoint was implemented and later integrated into the calls to the withdraw-\ac{API}.
Code for calling the endpoint is located in these files:
\begin{itemize}
\item \url{src/include/taler_exchange_service.h}: \\
Header describing functions and data structures used in withdraw and refresh testing:
\begin{itemize}
\item struct TALER\_EXCHANGE\_CsRHandle: Handle containing request information
\item struct TALER\_EXCHANGE\_CsRResponse: Response details
\item function TALER\_EXCHANGE\_CsRCallback: Callback function to deliver the results (used in withdraw and refresh)
\item function TALER\_EXCHANGE\_csr: Used to call endpoint
\item function TALER\_EXCHANGE\_csr\_cancel: Used to free dynamically allocated resources
\end{itemize}
\item \url{src/lib/exchange_api_csr.c}: Implementation of \url{/csr} request
\end{itemize}
\section{Withdraw Protocol}
\label{sec:withdraw-protocol-impl}
Since this is an existing endpoint, it was adjusted to support \gls{CSBS}.
Mainly, the in- and output-handling had to be adjusted as described in section \ref{sec:specification-withdraw-public-api}, additional cipher checks for the denomination were added and the \gls{CSBS} for persisting the request in the database was implemented.
\\\\
An interesting part of the implementation is the check whether a nonce was already used for this denomination or not (step: $s \leftarrow \text{GetWithdraw}(n_w, D_p)$).
This step ensures that the same signature will always be returned for a certain nonce.
Using the same nonce for the same denomination twice without this check would lead to the same random value $r$.
This is due to derivation of $r := \text{HKDF}(256,n_w || d_s, \text{"r"})$.
An attacker could then immediately recover the secret key by the following equation: $(h' - h) * x \mod q = s -s' \mod q$ \cite{tibouchi:attacks-schnorr-nonce}.
There are popular examples of this vulnerability in Sony Playstation 3's or Bitcoins ECDSA implementation \cite{buchanan:ps3-ecdsa-vuln} \cite{wang:bitcoin-ecdsa-vuln}.
More details on how such a vulnerability can be exploited can be found in one of the author's blog posts \cite{gian:nonce-sense}.\\
The designed Taler protocols using \gls{CSBS} are preventing this attack by checking the nonce and return the previously generated signature.
Additionally the denomination's public key is included in this check to prevent another issue explained in section \ref{sec:taler-vuln}.\\
The check is implemented by persisting a hash value over $n_w$ and $D_p$.
On every withdrawal \texttt{check\_request\_idempotent()} is called, which checks whether the persisted hash matches with the current $n_w, D_p$ pair.
\begin{itemize}
\item \url{src/exchange/taler-exchange-httpd_withdraw.c}: Implementation of \gls{CSBS} case for withdraw endpoint
\item \url{src/exchange/taler-exchange-httpd_keys.c}: Implement \gls{CSBS} case in function \\
TEH\_keys\_denomination\_sign (passes the signature creation down to the crypto helpers)
\item \url{src/include/taler_json_lib.h} and \url{src/json/json_helper.c}: \\
Add function TALER\_JSON\_spec\_blinded\_planchet
\item \url{src/json/json_pack.c}: \\
Implement \gls{CSBS} case in function\\ TALER\_JSON\_pack\_blinded\_denom\_sig
\item \url{src/pq/pq_query_helper.c}: implement \gls{CSBS} case in functions qconv\_denom\_sig and qconv\_blinded\_denom\_sig
\item \url{src/pq/pq_result_helper.c}: Implement \gls{CSBS} case in function extract\_blinded\_denom\_sig
\end{itemize}
For testing, the \gls{CSBS}-related data structures and procedures as well as the request to the additional endpoint \url{/csr} (before performing the actual withdrawal) were integrated:
\begin{itemize}
\item \url{src/testing/test_exchange_api.c}: Add additional tests for \gls{CSBS} withdraw
\item \url{src/include/taler_testing_lib.h}: Specification for functions \\
TALER\_TESTING\_cmd\_withdraw\_cs\_amount and \\
TALER\_TESTING\_cmd\_withdraw\_cs\_amount\_reuse\_key, add denomination cipher parameter to function TALER\_TESTING\_find\_pk
\item \url{src/testing/testing_api_cmd_withdraw.c}: add functions \\
TALER\_TESTING\_cmd\_withdraw\_cs\_amount and \\
TALER\_TESTING\_cmd\_withdraw\_cs\_amount\_reuse\_key, implement \gls{CSBS}-specific logic for withdraw
\item \url{src/testing/testing_api_helpers_exchange.c}:
add cipher parameter to function TALER\_TESTING\_find\_pk
\item \url{src/lib/exchange_api_withdraw.c}: Implement \gls{CSBS}-specific withdraw logic, integrate \url{/csr} request
\item \url{src/lib/exchange_api_withdraw2.c}: implement \gls{CSBS} case
\item \url{src/include/taler_json_lib.h} and \url{src/json/json_pack.c}: \\
Add function TALER\_JSON\_pack\_blinded\_planchet
\item \url{src/json/json_helper.c} implement \gls{CSBS} case in function parse\_blinded\_denom\_sig
\end{itemize}
\section{Deposit Protocol}
For deposit, only few changes were necessary because some of the required functionality has already been added for the previously implemented protocols, and only the coin signature verification is \gls{CSBS}-specific in this protocol.
\begin{itemize}
\item \url{/src/exchange/taler-exchange-httpd_deposit.c}: Add check whether denomination cipher and denomination signature cipher are equal
\item \url{/src/json/json_helper.c}: Implement \gls{CSBS} case in function parse\_denom\_sig
\item \url{/src/pq/pq_result_helper.c}: Implement \gls{CSBS} case in function extract\_denom\_sig
\end{itemize}
Tests for deposit are implemented here:
\begin{itemize}
\item \url{/src/testing/test_exchange_api.c}: Add tests (see "struct TALER\_TESTING\_Command\ spend\_cs[]") that spend \gls{CSBS} coins withdrawn in tests added for withdrawal
\item \url{/src/json/json_pack.c}: Implement \gls{CSBS} case in function TALER\_JSON\_pack\_denom\_sig
\end{itemize}
\section{Fixing a Minor Security Issue in Taler's RSA Blind Signature Protocols}
\label{sec:taler-vuln}
While implementing the nonce check in the \gls{CSBS} protocol (see section \ref{sec:withdraw-protocol-impl}), a minor security issue in Taler's current RSA Blind Signature implementation was detected and fixed.
The issue was only in the implementation of the current RSA Blind Signature protocols, the fix for this scenario was already implemented in \gls{CSBS} since the beginning.
\subsection{Security Issue}
\label{sec:taler-vuln-desc}
The redesigned \gls{CSBS} protocols already include the denomination key in the nonce check, which fixes this issue (see \ref{sec:withdraw-protocol-schnorr}).
In the case of \gls{RSABS}, the current protocol includes an \gls{idempotence} check by persisting the hash value of the blinded coin $m'$.
On a withdrawal/refresh the \gls{idempotence} check compares if the hash value of $m'$ was seen in the past and returns the 'old' signature on a match.
This could lead to the following scenario:
\begin{enumerate}
\item A broken wallet withdraws a coin with denomination $D_{p_{(1)}}$.
\item The wallet sends a request to withdraw the same coin for denomination $D_{p_{(2)}}$.
\item The exchange returns the signature for the denomination $D_{p_{(1)}}$ due to the \gls{idempotence} check.
\item Since the exchange returned an invalid signature, the customer can file a complaint at the auditor.
\item The auditor then has to investigate why the exchange returned invalid signatures.
\item The auditor can disprove the complaint by querying the persisted hash used for the \gls{idempotence} check.
With the associated denomination public key that is also persisted, the auditor can successfully verify the signature and thus prove that the exchange operated honestly.
\end{enumerate}
Including the denomination public key into the persisted hash for the \gls{idempotence} check solves this issue.
If a broken wallet now sends the same coin for more than one denomination, the exchange returns valid signatures in both cases.\\
While this is still an issue, this case is already handled nicely in Taler since this situation could also occur if a broken value tries to withdraw the same coin with two different blinding factors.
\subsection{Impact}
The impact of this security vulnerability is considered as very low.
An auditor investigating such an issue can simply retrace what happened by checking the persisted hash and associated denomination.
The impact of the issue is, that an auditor needs to investigate an issue, which can be prevented inside the protocol.
\\
In the previous section the client was considered a broken wallet.
While this could be done on purpose by malicious a customer, there is no real motivation for abusing this issue due the easy detection of an auditor.
\subsection{Fix}
Listing \ref{lst:rsa-idempotence} shows the code of calculating the hash for the idempotency check in the RSA case before it was fixed.
By trying to implement the \gls{CSBS} case, the question came up why the RSA case has not included the denomination key into the check.
After discussing this issue with Christian Grothoff, the conclusion was to include the denomination public key to prevent the discussed issue.
\begin{lstlisting}[style=bfh-c,language=C, caption={Idempotency check on RSA}, label={lst:rsa-idempotence}]
enum GNUNET_GenericReturnValue
TALER_coin_ev_hash (const struct TALER_BlindedPlanchet *blinded_planchet,
struct TALER_BlindedCoinHash *bch)
{
switch (blinded_planchet->cipher)
{
case TALER_DENOMINATION_RSA:
GNUNET_CRYPTO_hash (
blinded_planchet->details.rsa_blinded_planchet.blinded_msg,
blinded_planchet->details.rsa_blinded_planchet.blinded_msg_size,
&bch->hash);
return GNUNET_OK;
case TALER_DENOMINATION_CS:
...
\end{lstlisting}
The issue is fixed by adding a hash of the current denomination key into the calculation of the hash used in the \gls{idempotence} check.
The applied fix can be seen in listing \ref{lst:fixed-idempotence}.
\begin{lstlisting}[style=bfh-c,language=C, caption={Fixed idempotency check}, label={lst:fixed-idempotence}]
enum GNUNET_GenericReturnValue
TALER_coin_ev_hash (const struct TALER_BlindedPlanchet *blinded_planchet,
const struct TALER_DenominationHash *denom_hash,
struct TALER_BlindedCoinHash *bch)
{
switch (blinded_planchet->cipher)
{
case TALER_DENOMINATION_RSA:
{
struct GNUNET_HashContext *hash_context;
hash_context = GNUNET_CRYPTO_hash_context_start ();
GNUNET_CRYPTO_hash_context_read (hash_context,
&denom_hash->hash,
sizeof(denom_hash->hash));
GNUNET_CRYPTO_hash_context_read (hash_context,
blinded_planchet->details.
rsa_blinded_planchet.blinded_msg,
blinded_planchet->details.
rsa_blinded_planchet.blinded_msg_size);
GNUNET_CRYPTO_hash_context_finish (hash_context,
&bch->hash);
return GNUNET_OK;
}
case TALER_DENOMINATION_CS:
{
struct GNUNET_HashContext *hash_context;
hash_context = GNUNET_CRYPTO_hash_context_start ();
GNUNET_CRYPTO_hash_context_read (hash_context,
&denom_hash->hash,
sizeof(denom_hash->hash));
GNUNET_CRYPTO_hash_context_read (hash_context,
&blinded_planchet->details.
cs_blinded_planchet.nonce,
sizeof (blinded_planchet->details.
cs_blinded_planchet.nonce));
GNUNET_CRYPTO_hash_context_finish (hash_context,
&bch->hash);
return GNUNET_OK;
}
default:
GNUNET_break (0);
return GNUNET_SYSERR;
}
}
\end{lstlisting}

5
doc/cs/content/4_execution.tex Normal file
View File

@ -0,0 +1,5 @@
\input{content/4_1_design.tex}
\input{content/4_2_specification.tex}
\input{content/4_3_implementation.tex}

317
doc/cs/content/5_discussion.tex Normal file
View File

@ -0,0 +1,317 @@
\chapter{Discussion}
\label{chap:disc}
This chapter analyses the \acl{CS} implementation and compares it to the existing implementation with \gls{RSABS}.
The comparison will include the schemes itself, performance comparisons and a discussion on the security assumptions.
For the performance comparison CPU usage, latency, bandwidth and storage space are compared.
\section{Cipher Agility}
One of the benefits of having another blind signature scheme in Taler is \textit{cipher agility}.
Cipher agility means that one scheme can substitute another, for example if one scheme gets compromised in the future.
Cipher agility is considered harmful in certain situations.
TLS 1.2 \cite{rfc5246} and IPSEC/IKEv2 \cite{rfc6071} are good examples on how dangerous cipher agility inside protocols can be.
There are many ways these protocols can be set up insecure.
\\\\
Taler's protocols are built around blind signature schemes.
Therefore it is crucial to have an additional secure blind signature scheme that works with all Taler protocols.
As described in section \ref{sec:blind-sign-schemes}, blind signature schemes can vary and may be complex to substitute.
The \gls{CSBS} implementation provides such an alternative and thus \textit{cipher agility}.
\section{Scheme Comparison}
\label{chap:disc-scheme-comp}
Both schemes are explained in the preliminaries chapter (\gls{RSABS} in section \ref{fig:rsa-fdh-blind-sign} and \gls{CSBS} in \ref{fig:clause-blind-schnorr-sign-scheme}).
\\
There are multiple differences worth mentioning.
The first difference is that Schnorr signatures are inherently randomized.
This is also where the additional step in Schnorr signatures comes from.
A random number is chosen by the signer for every signature. \\
In \gls{CSBS} two blinding secrets are used instead of one in \gls{RSABS}.
On top of that, \gls{CSBS} needs to do most computations for signature creation twice, due to the \ac{ROS} problem (see \ref{par:ros-problem}).
\\\\
\textit{\Gls{abort-idempotency}} is a very important property for Taler.
Ensuring \gls{abort-idempotency} with the \gls{CSBS} scheme is harder than it was with RSA, due to the many random elements in the scheme ($r_0, r_1, \alpha_0, \alpha_1, \beta_0, \beta_1, b$).
The reason that these values are chosen randomly is the need for \textit{unpredictability}.\\
In the protocols (see chapter \ref{chap:design}) \gls{hkdf} is extensively used to derive these values instead of randomly generating them.
That way, the values are still \textit{unpredictable} (due to \gls{hkdf} properties), but now the protocols also ensure \textit{\gls{abort-idempotency}}.
In comparison to the RSA Blind Signature scheme, this is a clever and elegant solution, but the protocol complexity is increased.
\\\\
One could now think that RSA would be much simpler to implement, since the scheme looks easier and more accessible for many.
This can go horribly wrong and many developers still underestimate implementing RSA.
There are a lot of attacks on RSA, some examples are listed on the famous tool RsaCtfTool \cite{ganapati:rsactftool}.
Ben Perez made a popular talk and blog post, about why one should stop using RSA and should preferably use libsodium and \ac{ECC} \cite{perez:stoprsa}.
Using \gls{RSABS} in Taler is still a reasonable and fine choice.
Taler uses libgcrypt, a well-known and tested library.
\\
To conclude, the \gls{CSBS} protocols might be more complex to understand than the RSA Blind Signature protocols.
One has to keep in mind that implementing RSA correctly is hard.
\\
Another difference worth mentioning is, that the \gls{CSBS} scheme does not need scheme specific configurations, whereas RSA needs a key size specified.
This is because the implemented \gls{CSBS} version only supports \gls{25519}.
\\\\
Furthermore, both schemes provide \textit{perfect blindness}, see paragraph \ref{par:prop-blindness-rsa} for RSA and paragraph \ref{par:prop-blindness-cs} for \gls{CSBS}.
\section{Performance Comparison}
\label{sec:disc-perf-comp}
This section compares how the two schemes perform regarding CPU usage, latency, bandwidth and space.
Clause Schnorr has fixed key sizes with 256 bits (32 bytes), which we compare against different RSA key sizes (1024, 2048, 3072 and 4096 bits).
In terms of security, \gls{CSBS} 256 bit keys could be compared to 3072 bit RSA keys (see \url{https://www.keylength.com/} for more information).
\subsection{CPU Usage}
Various benchmarks were made on different CPU architectures.
This section discusses the main results, detailed information about the performance comparison can be found in appendix \ref{chap:app-perf}.
We thank the Taler team for providing measurements from additional systems and architectures.
Table \ref{tab:comp-cs-vs-rsa-3072} shows how \gls{CSBS} compares to RSA 3072.
RSA 3072 was chosen for comparison, since they both provide a comparable level of security.
Both provide about 128 bits of security, which means that roughly $2^{128}$ attempts in average are needed for a successful brute-force attack.\\
The table shows that \gls{CSBS} has better performance compared to RSA 3072 in all operations.
The biggest difference can be seen in the key generation.
In RSA, two random primes are needed, whereas \ac{DLP} algorithms like \gls{CSBS} only need to generate a random value.
Since key generation is done rarely compared to the other operations, the time needed for key generation does not matter that much.\\
Furthermore, the blinding in \gls{CSBS} is still faster than blinding in RSA, although in the \gls{CSBS} case the calculation is done twice. Also the derivation of $r_0,r_1$, the generation of $R_0,R_1$ and the derivation of $\alpha_0, \beta_0, \alpha_1, \beta_1$ is included in the measurement for the blinding operation of \gls{CSBS}.
Signing and blinding operations are much faster in \gls{CSBS}, also \gls{CSBS} signature verification is faster than RSA 3072.
\begin{bfhBox}[BFH-MediumBlue]{Setup}
CPU: 8-core AMD Ryzen 7 PRO 5850U \\
OS: Ubuntu 21.10 Linux 5.13.0-25-generic \#26-Ubuntu SMP Fri Jan 7 15:48:31 UTC 2022 x86\_64 x86\_64 x86\_64 GNU/Linux \\
libsodium version: 1.0.18-1build1 \\
libgcrypt version: 1.8.7-5ubuntu2 \\\\
Benchmarks with other hardware setups can be found in appendix \ref{chap:app-perf}.
\end{bfhBox}
\begin{table}[h]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{llr}
\rowcolor{BFH-tablehead}
\textbf{Signature Scheme} & \textbf{Operation} & \textbf{Speed} \\\hline
CS & 10x key generation & 0.204 ms \\\hline
RSA 3072 bit & 10x key generation & 2684 ms \\\hline
\hline
CS & 10x derive $R_0, R_1$ \& blinding & 3.870 ms \\\hline
RSA 3072 bit & 10x blinding & 5 ms \\\hline
\hline
CS & 10x signing & 0.077 ms \\\hline
RSA 3072 bit & 10x signing & 86 ms \\\hline
\hline
CS & 10x unblinding & 0.001 ms \\\hline
RSA 3072 bit & 10x unblinding & 24 ms \\\hline
\hline
CS & 10x verifying & 1.358 ms \\\hline
RSA 3072 bit & 10x verifying & 3.075 ms \\\hline
\end{tabular}
\caption{Comparison on CS vs. RSA 3072}
\label{tab:comp-cs-vs-rsa-3072}
\end{table}
Table \ref{tab:comp-cs-vs-rsa-1024} shows a comparison between \gls{CSBS} and RSA 1024 bit.
RSA 1024 is in some situations faster than the \gls{CSBS} implementation.
Note that 1024 bit keys are not recommended for many use cases, but the highest currently known RSA factorization done is 829 bits \cite{enwiki:1055393696}.
The following section \ref{sec:disc-risk} explains the risk running RSA 1024 or \gls{CSBS} denominations further.\\
The blind and unblind operations are running in a wallet implementation, therefore the comparison with RSA 1024 is very interesting for devices with less CPU power.
Comparison of such hardware can be found in appendix \ref{chap:app-perf}, these comparison results come to the same conlcusion.\\
Although RSA 1024 bit is much faster in the blinding operation, \gls{CSBS} still perform better when calculating the blinding and unblinding operations together.
\gls{CSBS} unblinding computes only an addition of two scalars $s + \alpha \mod p$, while RSA computes $s * r^{-1}$.
To conclude, \gls{CSBS} are faster than RSA 1024 bit and provide a better level of security.
This can be especially useful for wallets running on devices with less CPU power.
The verification on RSA 1024 is faster than \gls{CSBS}.
Therefore, it has to be further investigated which algorithm would overall perform better for the exchange or merchants.
While RSA 1024 bit can compete in certain operations, \gls{CSBS} provide a better level of security and are still faster in most operations.
\begin{table}[h]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{llr}
\rowcolor{BFH-tablehead}
\textbf{Signature Scheme} & \textbf{Operation} & \textbf{Speed} \\\hline
CS & 10x key generation & 0.204 ms \\\hline
RSA 1024 bit & 10x key generation & 126 ms \\\hline
\hline
CS & 10x derive $R_0, R_1$ \& blinding & 3.870 ms \\\hline
RSA 1024 bit & 10x blinding & 1.282 ms \\\hline
\hline
CS & 10x signing & 0.077 ms \\\hline
RSA 1024 bit & 10x signing & 7 ms \\\hline
\hline
CS & 10x unblinding & 0.001 ms \\\hline
RSA 1024 bit & 10x unblinding & 2.991 ms \\\hline
\hline
CS & 10x verifying & 1.358 ms \\\hline
RSA 1024 bit & 10x verifying & 0.876 ms \\\hline
\end{tabular}
\caption{Comparison on CS vs RSA 1024}
\label{tab:comp-cs-vs-rsa-1024}
\end{table}
\subsection{Disk Space}
\begin{bfhWarnBox}
These are theoretical calculations, implementations may choose to persist additional values.
\end{bfhWarnBox}
\gls{CSBS} save disk space due to the much smaller key sizes.
Even more disk space is saved by deriving values with the \gls{hkdf}, these values do not have to be stored.
\\
Table \ref{tab:comp-sign-space} shows the disk space comparison of signatures, the private keys alone need even less space with 256 bits per key.
\\
The wallet saves a lot of disk space by deriving most of the values.
In the \gls{CSBS} case a wallet must at least persist the private key $c_s$, $R_0, R_1, s', D_p$, each being 256 bits (32 bytes).
A wallet needs to persist 150 bytes per coin in total.
In the RSA Blind Signature case the wallet persists $c_s$, $b$, $\sigma_c$, $D_p$.
\\Note: for refreshed coins an additional 32 byte value is persisted as seed.\\
$c_s$ is still a 32 byte value in the RSA case, the other values depend on the RSA key size. (32 byte + 3 * \textit{rsa\_keysize}).
The disk space comparison for a wallet can be found in \ref{tab:comp-wallet-space}.
\begin{table}[ht]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{lccr}
\rowcolor{BFH-tablehead}
\textbf{Signature Scheme} & \textbf{Disk Space} & \textbf{Factor} & \textbf{Disk Space 1M signatures}\\\hline
CS & 512 bits & 1x & 64 MB\\\hline
RSA 1024 bit & 1024 bits & 2x & 128 MB \\\hline
RSA 2048 bit & 2048 bits & 4x & 256 MB\\\hline
RSA 3072 bit & 3072 bits & 6x & 384 MB\\\hline
RSA 4096 bit & 4096 bits & 8x & 512 MB\\\hline
\end{tabular}
\caption{Comparison disk space signatures}
\label{tab:comp-sign-space}
\end{table}
\begin{table}[ht]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{lccr}
\rowcolor{BFH-tablehead}
\textbf{Signature Scheme} & \textbf{Disk Space} & \textbf{Factor} & \textbf{Disk Space 1M coins}\\\hline
CS 256 bits & 150 bytes & 1x & 150 MB\\\hline
RSA 1024 bit & 416 bytes & 2.7x & 416 MB \\\hline
RSA 2048 bit & 800 bits & 5.3x & 800 MB\\\hline
RSA 3072 bit & 1184 bits & 7.9x & 1184 MB\\\hline
RSA 4096 bit & 1568 bits & 10.4x & 1568 MB\\\hline
\end{tabular}
\caption{Comparison disk space wallet}
\label{tab:comp-wallet-space}
\end{table}
\subsection{Bandwidth}
\begin{bfhWarnBox}
These are theoretical calculations, implementations may choose to persist additional values.
\end{bfhWarnBox}
The reasons that \gls{CSBS} use less bandwidth is mostly because the signature/key sizes are much smaller.
The bandwith improvements for the \texttt{/keys} API is the same as specified in the table with disk space comparison \ref{tab:comp-sign-space}.
For \gls{CSBS} many calculations are performed twice, therefore also two values are submitted.
Table \ref{tab:comp-band-withd} compares the bandwidth used in a withdrawal.
The 32 byte values $2 * n_w, 2 * D_p, R_0, R_1, s,W_p, c_0, c_1, \sigma_W$ as well as an integer $b$ are transmitted for \gls{CSBS}.\\
For RSA, the values $D_p, m', \sigma'_c$ have the same size as the key size.
Additionally, the 32 byte values $W_p, \sigma_W$ are transmitted.
\\\\
In the refresh protocol the only difference is an additional hash ($h_{C_0}, h_{C_1}$ instead of only $h_C$) sent in the commit phase.
Depending on the hash size another 32 byte (or 64 byte) value is transmitted.
\begin{table}[ht]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{lccr}
\rowcolor{BFH-tablehead}
\textbf{Signature Scheme} & \textbf{Bandwith used} & \textbf{Factor} & \textbf{1M coins}\\\hline
CS 256 bits & 356 bytes & 1x & 324 MB\\\hline
RSA 1024 bit & 448 bytes & 1.3x & 448 MB \\\hline
RSA 2048 bit & 832 bits & 2.5x & 832 MB\\\hline
RSA 3072 bit & 1216 bits & 3.75x & 1216 MB\\\hline
RSA 4096 bit & 1600 bits & 4.9x & 1600 MB\\\hline
\end{tabular}
\caption{Bandwith comparison withdrawal}
\label{tab:comp-band-withd}
\end{table}
\subsection{Latency}
This section the notion of \acl{RTT} (see \cite{geeks:rtt}) is used.
There are many factors that influence the measurement of a \acl{RTT}.
Following factors can bring huge changes in the value of \ac{RTT}s.
\begin{itemize}
\item Distance
\item Transmission medium
\item Network hops
\item Traffic levels
\item Server response time
\end{itemize}
All of these factors will vary in reality and are independent of the scheme.\\
The important comparison here is the number of \ac{RT}s as in table \ref{tab:comp-rtt}.
\begin{table}[ht]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{lc}
\rowcolor{BFH-tablehead}
\textbf{Signature Scheme} & \textbf{Number of RTs} \\\hline
RSA Blind Signatures & 1\\\hline
Clause Blind Schnorr Signatures & 2\\\hline
\end{tabular}
\caption{Comparison of Round-Trips}
\label{tab:comp-rtt}
\end{table}
While creating \gls{RSABS} have one \ac{RT}, \gls{CSBS} need an additional \ac{RT} for requesting the public $R_0, R_1$.
This means that the time spend for withdrawing is almost \textbf{doubled} (the $ R $ request doesn't have any persistence and therefore requires less time) in comparison to RSA.
A coin should not be spent immediately after withdrawal or refresh.
Otherwise, an adversary could deanonymize a customer by correlating the timestamps.
The additional \ac{RT} is a drawback of \gls{CSBS} compared to RSA, but negligible due to the fact that a coin must not be spent immediately.
\section{Security Assumptions}
\label{sec:disc-sec-assumptions}
This section discusses the differences regarding the security assumptions of the schemes.
This section should not explain nor analyze the security assumptions, instead the section focuses on explaining what these assumptions mean and what should be kept in mind about them.
Read section \ref{sec:sign-schemes} and it's references for more information on the assumptions.
RSA's security assumptions are well known since quite a long time and a lot of research is done.
Despite being a lot of attacks \cite{ganapati:rsactftool} \cite{perez:stoprsa}, RSA is still considered a secure scheme after decades.\\
For Schnorr Signatures the \acl{DLP} (see \autoref{sec:dlp}) needs to be hard.
Also the \ac{DLP} is well-known and is being researched since decades.\\
However, with Blind Schorr Signatures an additional assumption needs to hold; the \ac{ROS} problem.
Compared to the other assumptions, \ac{ROS} is relatively new and still a recent research topic.
A recent paper from 2020 on the (in)security of ROS \cite{cryptoeprint:2020:945} broke many schemes relying on ROS being hard, including Schnorr Blind signatures.
The paper on which we rely on (updated in 2021) with the Clause Blind Schnorr Signature Scheme \cite{cryptoeprint:2019:877} is considered secure at the time of writing.\\
\section{Risk}
\label{sec:disc-risk}
As introduced in \autoref{sec:disc-sec-assumptions}, \gls{CSBS} rely on an additional assumption currently being researched.
Compared to other schemes, the chosen \gls{CSBS} are very new (published in 2019, updated in 2021).
While every scheme could potentially be broken, older ones already went through a lot of research and their assumptions are well-known.
Therefore, the risk that a vulnerability in \gls{CSBS} will be discovered is probably higher than a newly discovered vulnerability breaking RSA.
Unpredictability of $ r $ is a key aspect of the signature creation process of \gls{CSBS}.
The redesigned Taler protocols solve this by persisting the nonce and denomination key (described in \autoref{sec:withdraw-protocol-impl}) and checking for reuse of this combination before signature creation.
If this process is malfunctioning (broken implementation, faulty database) or can be circumvented in any way, recovery of a denomination private key is possible.
An exchange operator can still consider using \gls{CSBS} as denomination scheme, as there are multiple benefits (see \autoref{sec:disc-perf-comp}).
The financial loss in the worst case can be calculated and capped by the validity of a denomination key.
If a vulnerability in the \gls{CSBS} would be detected, an exchange operator could revoke the corresponding denomination keys and change the scheme to \gls{RSABS}.
The wallets can then follow the refund protocol to get the money back.
\section{Comparison Conclusion}
\label{sec:disc-comp-conclusion}
A detailed comparison of the two blind signature schemes was made.
This last section interprets the results and concludes the comparison.
\gls{CSBS} on \gls{25519} provide the same security level as \gls{RSABS} with 3072 bit key sizes.
The implementation of \gls{CSBS} is the clear winner in all performance comparisons with RSA 3072 bits.
1024 bit RSA is faster than the \gls{CSBS} implementation in certain operations.
The \gls{CSBS} implementation still offers better performance for wallets with less CPU power and provides a much higher level of security (comparable to RSA 3072).
As further comparisons show, RSA scales very bad the larger the keys get and \gls{CSBS} performs much better overall.
As discussed in the risk section \ref{sec:disc-risk}, \gls{CSBS} have an additional security assumption, which is still a recent research topic.
\gls{CSBS} provide various benefits and the risk can be calculated and capped.
An exchange operator who is aware of the discussed risk can use \gls{CSBS} safely.
\gls{CSBS} are best suited for denominations with low value, where many coins are being withdrawn/refreshed.

70
doc/cs/content/6_conclusion.tex Normal file
View File

@ -0,0 +1,70 @@
\chapter{Conclusion}
This section provides a summary of this work, presents the results and gives an outlook on future work.
\section{Summary}
In the beginning of the project good knowledge on the current state in research about Blind Schnorr signatures was needed.
Therefore, various papers were read and then the paper "Blind Schnorr Signatures and Signed ElGamal Encryption in the Algebraic Group Model" \cite{cryptoeprint:2019:877} was chosen as basis for the redesign of the Taler protocols.\\
The next step was to analyze the current Taler protocols and understand the required properties including \textit{\gls{abort-idempotency}}.\\
With the gathered knowledge (see chapter \ref{chap:preliminaries}) the Taler protocols were redesigned to support \gls{CSBS} (see chapter \ref{chap:design}).
These redesigned protocols were then further specified (chapter \ref{chap:spec}) and then implemented (chapter \ref{chap:implement}).
The implementation includes the main protocols, key management, cryptographic utilities in Taler and the \gls{CSBS} cryptographic routines.\\
The \gls{CSBS} scheme was analyzed and compared in detail to the RSA Blind Signature scheme (see \ref{chap:disc}).
\section{Results}
The thesis provides several results to add support for Schnorr's blind signature in Taler, including:
\begin{itemize}
\item Redesigned Taler protocols to support \gls{CSBS}
\item Implementation of cryptographic routines
\item Implementation of Taler protocols in Exchange
\begin{itemize}
\item Key Management and security module
\item Cryptographic utilities
\item Withdraw protocol
\item Deposit protocol
\end{itemize}
\item Comparison and Analysis
\begin{itemize}
\item Performance (speed, space, latency \& bandwith)
\item Security
\item Scheme Comparison
\end{itemize}
\item Fixing a minor security issue in Taler's current protocols
\end{itemize}
The code is tested, and those tests are integrated in the existing testing framework.
Benchmarks are added for the cryptographic routines and the security module.
\section{Future Work}
Like in any other project, there is always more that could be done.
This section provides an outlook on what can be done in future work.
\begin{itemize}
\item Implement wallet
\item Implementing remaining \gls{CSBS} protocols (refresh, tipping protocol, refund etc.)
\item Implementing merchant
\item Security audit of CS implementation
\item Find a solution for withdraw loophole
\item Evaluating \& implementing \gls{CSBS} on other curves
\end{itemize}
There are some remaining protocols to implement, which were out of scope for this thesis.
To run \gls{CSBS} in production, these protocols have to be implemented too.
Further, the merchant needs to support \gls{CSBS} too.
The merchant implementation can be done fast, as the merchant only verifies denomination signatures in most cases. \\
Currently, the exchange runs both security modules, the \gls{CSBS} and the RSA security modules.
To reduce unnecessary overhead, this should be changed so that only one security has to be running.
To run \gls{CSBS} in production a security audit from an external company is recommended (as done for other parts in the exchange, see \cite{codeblau:taler-audit}).
A security audit should always be made when implementing big changes like these.\\
As mentioned in the scope section, the optional goal to find and implement a good solution for the withdraw loophole was dropped.
This was due to the scope shift and because the analysis of the problem showed that finding a good solution needs more research and is a whole project in itself (see \ref{sec:scope} for more information).\\
Furthermore, \gls{CSBS} could be implemented on other curves.
For example Curve448 \cite{cryptoeprint:2015:625} could be used, as it provides 224 bits of security, wheras \gls{25519} \cite{bern:curve25519} provides about 128 bits of security.
Curve secp256k1 could further improve \gls{CSBS} performance.
While providing support for Curve448 should not be problematic, a potential implementation for secp256k1 needs further analysis (see \cite{bernlange:safecurves} and \cite{bip:schnorr-bitc} for more information).
\section{Personal Conclusion}
This thesis includes understanding, analyzing, integrating and implementing a recent academic paper \cite{cryptoeprint:2019:877} containing a modern cryptographic scheme.
Furthermore, the implementation is done in Taler, an intuitive and modern solution for a social responsible payment system with high ethical standards.
Although there was a lot of work, we enjoyed working on such a modern and very interesting topic.
Especially the first successful signature verification and the signature scheme performance benchmarks motivated us to push the implementation and integration into Taler forward.\\
We are happy to provide an implementation of a modern scheme and making it available as free software.

677
doc/cs/content/appendix.tex Normal file
View File

@ -0,0 +1,677 @@
\appendix
\chapter{Installation}
These installation instructions are meant to run the code developed within this thesis for development- and review-purposes.
For a comprehensive installation instruction follow the Taler documentation
\cite{taler-documentation}.
\begin{bfhNoteBox}
These instructions are used and tested on Ubuntu 21.10.
\end{bfhNoteBox}
\section{Dependencies and Setup}
The following dependencies need to be installed for GNUnet and Taler Exchange:
\setupLinuxPrompt{student}
\begin{ubuntu}
sudo apt update
sudo apt install git curl build-essential gcc automake make \ texinfo autoconf uncrustify libtool pkgconf gettext gnutls-bin \ libcurl4-gnutls-dev libgcrypt20-dev libidn2-dev libjansson-dev \ libnss3-dev sqlite pipenv libltdl-dev libsodium-dev libpq-dev \ autopoint libunistring-dev libextractor-dev libpng-dev \ libpulse-dev libsqlite3-dev recutils python3-jinja2 sqlite yapf3 \ postgresql libpq-dev wget libmicrohttpd-dev
export LD\_LIBRARY\_PATH=/usr/local/lib
\end{ubuntu}
\begin{bfhBox}[BFH-MediumBlue]{Install in a container}
The installation can also be done in a docker or podman container with the ubuntu:21.10 image:
\setupLinuxPrompt{student}
\begin{ubuntu}
podman run -it --name talertest ubuntu:21.10
\end{ubuntu}
\end{bfhBox}
\section{Install GNUnet Core}
GNUnet core is both a dependency of the Taler exchange and where we implemented the Clause Blind Schnorr Signature Scheme.
\setupLinuxPrompt{student}
\begin{ubuntu}
git clone https://git.gnunet.org/gnunet.git
cd gnunet
./bootstrap
./configure --enable-benchmarks --prefix=/usr/local
make
make install
make check # Run optionally to verify installation and run tests
\end{ubuntu}
To run benchmarks run:
\setupLinuxPrompt{student}
\begin{ubuntu}
./src/util/perf_crypto_cs
./src/util/perf_crypto_rsa
\end{ubuntu}
\section{Install Taler Exchange}
\begin{bfhWarnBox}
Ensure that the current user has privileges in postgresql.
One possible way to do this is:\\
(where [user] has to be replaced with the name of the system user running the tests)
\setupLinuxPrompt{student}
\begin{ubuntu}
service postgresql start
sudo su
su - postgres
psql
CREATE ROLE [user] LOGIN SUPERUSER;
CREATE DATABASE [user] OWNER [user];
exit
\end{ubuntu}
\end{bfhWarnBox}
The Taler exchange can be installed as followed:
\setupLinuxPrompt{student}
\begin{ubuntu}
service postgresql start
createdb talercheck
git clone https://git.taler.net/exchange.git
cd exchange
./bootstrap
./configure --with-gnunet=/usr/local --prefix=/usr/local
./make
./make install
./make check # Run optionally to verify installation and run tests
\end{ubuntu}
To execute the security module benchmarks run:
\setupLinuxPrompt{student}
\begin{ubuntu}
cd src/util
./test_helper_cs
./test_helper_rsa
\end{ubuntu}
\chapter{Performance Measurements}
\label{chap:app-perf}
\section{AMD Ryzen 7 PRO 5850U (Notebook)}
Detailed comparison of each operation can be found in table \ref{tab:comp-sign-amd-ryzen-7}.
\begin{bfhBox}[BFH-MediumBlue]{Setup}
CPU: 8-core AMD Ryzen 7 PRO 5850U \\
Architecture: amd64 \\
OS: Ubuntu 21.10 Linux 5.13.0-25-generic \#26-Ubuntu SMP Fri Jan 7 15:48:31 UTC 2022 x86\_64 x86\_64 x86\_64 GNU/Linux \\
libsodium:amd64 version: 1.0.18-1build1 \\
libgcrypt:amd64 version: 1.8.7-5ubuntu2
\end{bfhBox}
\begin{table}[h]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{llr}
\rowcolor{BFH-tablehead}
\textbf{Signature Scheme} & \textbf{Operation} & \textbf{Speed} \\\hline
CS & 10x key generation & 0.204 ms \\\hline
RSA 1024 bit & 10x key generation & 126 ms \\\hline
RSA 2048 bit & 10x key generation & 903 ms \\\hline
RSA 3072 bit & 10x key generation & 2684 ms \\\hline
RSA 4096 bit & 10x key generation & 10 000 ms \\\hline
\hline
CS & 10x r0, r1 derive and R1,R2 calculation & 0.444 ms \\\hline
CS & 10x derivation of blinding secrets & 0.094 ms \\\hline
CS & 10x blinding & 3.332 ms \\\hline
RSA 1024 bit & 10x blinding & 1.282 ms \\\hline
RSA 2048 bit & 10x blinding & 3.012 ms \\\hline
RSA 3072 bit & 10x blinding & 5 ms \\\hline
RSA 4096 bit & 10x blinding & 9 ms \\\hline
\hline
CS & 10x signing & 0.077 ms \\\hline
RSA 1024 bit & 10x signing & 7 ms \\\hline
RSA 2048 bit & 10x signing & 34 ms \\\hline
RSA 3072 bit & 10x signing & 86 ms \\\hline
RSA 4096 bit & 10x signing & 183 ms \\\hline
\hline
CS & 10x unblinding & 0.001 ms \\\hline
RSA 1024 bit & 10x unblinding & 2.991 ms \\\hline
RSA 2048 bit & 10x unblinding & 10 ms \\\hline
RSA 3072 bit & 10x unblinding & 24 ms \\\hline
RSA 4096 bit & 10x unblinding & 44 ms \\\hline
\hline
CS & 10x verifying & 1.358 ms \\\hline
RSA 1024 bit & 10x verifying & 0.876 ms \\\hline
RSA 2048 bit & 10x verifying & 1.836 ms \\\hline
RSA 3072 bit & 10x verifying & 3.075 ms \\\hline
RSA 4096 bit & 10x verifying & 5 ms \\\hline
\end{tabular}
\caption{Comparison on AMD Ryzen 7}
\label{tab:comp-sign-amd-ryzen-7}
\end{table}
\section{Intel(R) Core(TM) i7-8565U}
Detailed comparison of each operation can be found in table \ref{tab:comp-sign-intel-i7}.
\begin{bfhBox}[BFH-MediumBlue]{Setup}
CPU: 8-core Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz \\
Architecture: amd64 \\
OS: Ubuntu 21.10 Linux 5.13.0-25-generic \#26-Ubuntu SMP Fri Jan 7 15:48:31 UTC 2022 x86\_64 x86\_64 x86\_64 GNU/Linux \\
libsodium:amd64 version: 1.0.18-1build1 \\
libgcrypt:amd64 version: 1.8.7-5ubuntu2
\end{bfhBox}
\begin{table}[ht]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{llr}
\rowcolor{BFH-tablehead}
\textbf{Signature Scheme} & \textbf{Operation} & \textbf{Speed} \\\hline
CS & 10x key generation & 1.05 ms \\\hline
RSA 1024 bit & 10x key generation & 189 ms \\\hline
RSA 2048 bit & 10x key generation & 1555 ms \\\hline
RSA 3072 bit & 10x key generation & 5000 ms \\\hline
RSA 4096 bit & 10x key generation & 11 000 ms \\\hline
\hline
CS & 10x r0, r1 derive and R1,R2 calculation & 2.261 ms \\\hline
CS & 10x derivation of blinding secrets & 0.521 ms \\\hline
CS & 10x blinding & 13 ms \\\hline
RSA 1024 bit & 10x blinding & 2.6 ms \\\hline
RSA 2048 bit & 10x blinding & 4.12 ms \\\hline
RSA 3072 bit & 10x blinding & 7 ms \\\hline
RSA 4096 bit & 10x blinding & 11 ms \\\hline
\hline
CS & 10x signing & 0.405 ms \\\hline
RSA 1024 bit & 10x signing & 9 ms \\\hline
RSA 2048 bit & 10x signing & 44 ms \\\hline
RSA 3072 bit & 10x signing & 108 ms \\\hline
RSA 4096 bit & 10x signing & 216 ms \\\hline
\hline
CS & 10x unblinding & 0.005 ms \\\hline
RSA 1024 bit & 10x unblinding & 3.353 ms \\\hline
RSA 2048 bit & 10x unblinding & 12 ms \\\hline
RSA 3072 bit & 10x unblinding & 27 ms \\\hline
RSA 4096 bit & 10x unblinding & 47 ms \\\hline
\hline
CS & 10x verifying & 4.413 ms \\\hline
RSA 1024 bit & 10x verifying & 1.202 ms \\\hline
RSA 2048 bit & 10x verifying & 2.304 ms \\\hline
RSA 3072 bit & 10x verifying & 4.094 ms \\\hline
RSA 4096 bit & 10x verifying & 6 ms \\\hline
\end{tabular}
\caption{Comparison on Intel(R) Core(TM) i7-8565U}
\label{tab:comp-sign-intel-i7}
\end{table}
\section{AMD Ryzen Threadripper 1950X 16-Core Processor}
Detailed comparison of each operation can be found in table \ref{tab:comp-sign-amd-threadripper}.
\begin{bfhBox}[BFH-MediumBlue]{Setup}
CPU: AMD Ryzen Threadripper 1950X 16-Core Processor \\
Architecture: amd64 \\
OS: Linux 5.13.0-trunk-amd64 \#1 SMP Debian 5.13.12-1~exp1
(2021-08-20) x86\_64 GNU/Linux \\
libsodium:amd64 version: 1.9.4-5 \\
libgcrypt:amd64 version: 1.0.18-1
\end{bfhBox}
\begin{table}[ht]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{llr}
\rowcolor{BFH-tablehead}
\textbf{Signature Scheme} & \textbf{Operation} & \textbf{Speed} \\\hline
CS & 10x key generation & 0.442 ms \\\hline
RSA 1024 bit & 10x key generation & 145 ms \\\hline
RSA 2048 bit & 10x key generation & 1167 ms \\\hline
RSA 3072 bit & 10x key generation & 6000 ms \\\hline
RSA 4096 bit & 10x key generation & 11 000 ms \\\hline
\hline
CS & 10x r0, r1 derive and R1,R2 calculation & 1.043 ms \\\hline
CS & 10x derivation of blinding secrets & 0.242 ms \\\hline
CS & 10x blinding & 7 ms \\\hline
RSA 1024 bit & 10x blinding & 2.258 ms \\\hline
RSA 2048 bit & 10x blinding & 4.744 ms \\\hline
RSA 3072 bit & 10x blinding & 9 ms \\\hline
RSA 4096 bit & 10x blinding & 14 ms \\\hline
\hline
CS & 10x signing & 0.270 ms \\\hline
RSA 1024 bit & 10x signing & 10 ms \\\hline
RSA 2048 bit & 10x signing & 47 ms \\\hline
RSA 3072 bit & 10x signing & 119 ms \\\hline
RSA 4096 bit & 10x signing & 248 ms \\\hline
\hline
CS & 10x unblinding & 0.003 ms \\\hline
RSA 1024 bit & 10x unblinding & 4.086 ms \\\hline
RSA 2048 bit & 10x unblinding & 14 ms \\\hline
RSA 3072 bit & 10x unblinding & 34 ms \\\hline
RSA 4096 bit & 10x unblinding & 60 ms \\\hline
\hline
CS & 10x verifying & 2.392 ms \\\hline
RSA 1024 bit & 10x verifying & 1.137 ms \\\hline
RSA 2048 bit & 10x verifying & 2.797 ms \\\hline
RSA 3072 bit & 10x verifying & 5 ms \\\hline
RSA 4096 bit & 10x verifying & 7 ms \\\hline
\end{tabular}
\caption{Comparison on AMD Ryzen Threadripper 1950X}
\label{tab:comp-sign-amd-threadripper}
\end{table}
\section{Intel(R) Xeon(R) CPU E5-2630}
Detailed comparison of each operation can be found in table \ref{tab:comp-sign-intel-xeon}.
\begin{bfhBox}[BFH-MediumBlue]{Setup}
CPU: Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz \\
Architecture: amd64 \\
OS: Linux 5.10.0-8-amd64 \#1 SMP Debian 5.10.46-4 (2021-08-03) x86\_64\\
libsodium:amd64 version: 1.0.18-1\\
libgcrypt:amd64 version: 1.8.7-6
\end{bfhBox}
\begin{table}[ht]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{llr}
\rowcolor{BFH-tablehead}
\textbf{Signature Scheme} & \textbf{Operation} & \textbf{Speed} \\\hline
CS & 10x key generation & 0.606 ms \\\hline
RSA 1024 bit & 10x key generation & 329 ms \\\hline
RSA 2048 bit & 10x key generation & 3210 ms \\\hline
RSA 3072 bit & 10x key generation & 12 000 ms \\\hline
RSA 4096 bit & 10x key generation & 40 000 ms \\\hline
\hline
CS & 10x r0, r1 derive and R1,R2 calculation & 1.527 ms \\\hline
CS & 10x derivation of blinding secrets & 0.329 ms \\\hline
CS & 10x blinding & 9 ms \\\hline
RSA 1024 bit & 10x blinding & 4.026 ms \\\hline
RSA 2048 bit & 10x blinding & 9 ms \\\hline
RSA 3072 bit & 10x blinding & 18 ms \\\hline
RSA 4096 bit & 10x blinding & 27 ms \\\hline
\hline
CS & 10x signing & 0.274 ms \\\hline
RSA 1024 bit & 10x signing & 21 ms \\\hline
RSA 2048 bit & 10x signing & 96 ms \\\hline
RSA 3072 bit & 10x signing & 237 ms \\\hline
RSA 4096 bit & 10x signing & 482 ms \\\hline
\hline
CS & 10x unblinding & 0.004 ms \\\hline
RSA 1024 bit & 10x unblinding & 7 ms \\\hline
RSA 2048 bit & 10x unblinding & 25 ms \\\hline
RSA 3072 bit & 10x unblinding & 58 ms \\\hline
RSA 4096 bit & 10x unblinding & 99 ms \\\hline
\hline
CS & 10x verifying & 4.334 ms \\\hline
RSA 1024 bit & 10x verifying & 2.190 ms \\\hline
RSA 2048 bit & 10x verifying & 5 ms \\\hline
RSA 3072 bit & 10x verifying & 11 ms \\\hline
RSA 4096 bit & 10x verifying & 14 ms \\\hline
\end{tabular}
\caption{Comparison on Intel(R) Xeon(R) CPU E5-2630}
\label{tab:comp-sign-intel-xeon}
\end{table}
\section{Intel(R) Pentium(R) 3558U}
Detailed comparison of each operation can be found in table \ref{tab:comp-sign-intel-pentium}.
\begin{bfhBox}[BFH-MediumBlue]{Setup}
CPU: Intel(R) Pentium(R) 3558U @ 1.70GHz \\
Architecture: amd64 \\
OS: Linux 5.10.0-8-amd64 \#1 SMP Debian 5.10.46-3 (2021-07-28) x86\_64\\
libsodium:amd64 version: 1.0.18-1\\
libgcrypt:amd64 version: 1.8.7-6
\end{bfhBox}
\begin{table}[ht]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{llr}
\rowcolor{BFH-tablehead}
\textbf{Signature Scheme} & \textbf{Operation} & \textbf{Speed} \\\hline
CS & 10x key generation & 0.53 ms \\\hline
RSA 1024 bit & 10x key generation & 524 ms \\\hline
RSA 2048 bit & 10x key generation & 3357 ms \\\hline
RSA 3072 bit & 10x key generation & 15 000 ms \\\hline
RSA 4096 bit & 10x key generation & 37 000 ms \\\hline
\hline
CS & 10x r0, r1 derive and R1,R2 calculation & 1.375 ms \\\hline
CS & 10x derivation of blinding secrets & 0.349 ms \\\hline
CS & 10x blinding & 8 ms \\\hline
RSA 1024 bit & 10x blinding & 4.86 ms \\\hline
RSA 2048 bit & 10x blinding & 11 ms \\\hline
RSA 3072 bit & 10x blinding & 19 ms \\\hline
RSA 4096 bit & 10x blinding & 31 ms \\\hline
\hline
CS & 10x signing & 0.283 ms \\\hline
RSA 1024 bit & 10x signing & 26 ms \\\hline
RSA 2048 bit & 10x signing & 117 ms \\\hline
RSA 3072 bit & 10x signing & 292 ms \\\hline
RSA 4096 bit & 10x signing & 571 ms \\\hline
\hline
CS & 10x unblinding & 0.003 ms \\\hline
RSA 1024 bit & 10x unblinding & 8 ms \\\hline
RSA 2048 bit & 10x unblinding & 30 ms \\\hline
RSA 3072 bit & 10x unblinding & 67 ms \\\hline
RSA 4096 bit & 10x unblinding & 111 ms \\\hline
\hline
CS & 10x verifying & 3.769 ms \\\hline
RSA 1024 bit & 10x verifying & 2.616 ms \\\hline
RSA 2048 bit & 10x verifying & 6 ms \\\hline
RSA 3072 bit & 10x verifying & 11 ms \\\hline
RSA 4096 bit & 10x verifying & 17 ms \\\hline
\end{tabular}
\caption{Comparison on Intel(R) Pentium(R) 3558U}
\label{tab:comp-sign-intel-pentium}
\end{table}
\section{arm64}
Detailed comparison of each operation can be found in table \ref{tab:comp-sign-arm64}.
\begin{bfhBox}[BFH-MediumBlue]{Setup}
CPU: 8-core arm64\\
Architecture: ARM64 \\
OS: Linux ten64 5.11.0-31-generic \#33+testsfp1 SMP Mon Aug 23 16:07:41 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux \\
libsodium:arm64 version: 1.8.7-2ubuntu2.1 \\
libgcrypt:arm64 version: 1.0.18-1
\end{bfhBox}
\begin{table}[ht]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{llr}
\rowcolor{BFH-tablehead}
\textbf{Signature Scheme} & \textbf{Operation} & \textbf{Speed} \\\hline
CS & 10x key generation & 2.896 ms \\\hline
RSA 1024 bit & 10x key generation & 839 ms \\\hline
RSA 2048 bit & 10x key generation & 8000 ms \\\hline
RSA 3072 bit & 10x key generation & 17 000 ms \\\hline
RSA 4096 bit & 10x key generation & 82 000 ms \\\hline
\hline
CS & 10x r0, r1 derive and R1,R2 calculation & 6 ms \\\hline
CS & 10x derivation of blinding secrets & 0.713 ms \\\hline
CS & 10x blinding & 23 ms \\\hline
RSA 1024 bit & 10x blinding & 11 ms \\\hline
RSA 2048 bit & 10x blinding & 28 ms \\\hline
RSA 3072 bit & 10x blinding & 51 ms \\\hline
RSA 4096 bit & 10x blinding & 81 ms \\\hline
\hline
CS & 10x signing & 0.321 ms \\\hline
RSA 1024 bit & 10x signing & 57 ms \\\hline
RSA 2048 bit & 10x signing & 263 ms \\\hline
RSA 3072 bit & 10x signing & 685 ms \\\hline
RSA 4096 bit & 10x signing & 1385 ms \\\hline
\hline
CS & 10x unblinding & 0.006 ms \\\hline
RSA 1024 bit & 10x unblinding & 23 ms \\\hline
RSA 2048 bit & 10x unblinding & 79 ms \\\hline
RSA 3072 bit & 10x unblinding & 171 ms \\\hline
RSA 4096 bit & 10x unblinding & 296 ms \\\hline
\hline
CS & 10x verifying & 11ms \\\hline
RSA 1024 bit & 10x verifying & 5 ms \\\hline
RSA 2048 bit & 10x verifying & 15 ms \\\hline
RSA 3072 bit & 10x verifying & 27 ms \\\hline
RSA 4096 bit & 10x verifying & 45 ms \\\hline
\end{tabular}
\caption{Comparison on arm64}
\label{tab:comp-sign-arm64}
\end{table}
\section{AMD Ryzen Embedded R1606G}
Detailed comparison of each operation can be found in table \ref{tab:comp-sign-amd-embedded}.
\begin{bfhBox}[BFH-MediumBlue]{Setup}
CPU: 4-core AMD Ryzen Embedded R1606G with Radeon Vega Gfx\\
Architecture: amd64 \\
OS: Linux computer 5.13.0-25-generic \#26-Ubuntu SMP Fri Jan 7 15:48:31 UTC 2022 x86\_64 x86\_64 x86\_64 GNU/Linux\\
libsodium:amd64 version: 1.8.7-5ubuntu2 \\
libgcrypt:amd64 version: 1.0.18-1build1
\end{bfhBox}
\begin{table}[ht]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{llr}
\rowcolor{BFH-tablehead}
\textbf{Signature Scheme} & \textbf{Operation} & \textbf{Speed} \\\hline
CS & 10x key generation & 2.373 ms \\\hline
RSA 1024 bit & 10x key generation & 184 ms \\\hline
RSA 2048 bit & 10x key generation & 2132 ms \\\hline
RSA 3072 bit & 10x key generation & 8000 ms \\\hline
RSA 4096 bit & 10x key generation & 21 000 ms \\\hline
\hline
CS & 10x r0, r1 derive and R1,R2 calculation & 1.09 ms \\\hline
CS & 10x derivation of blinding secrets & 0.43 ms \\\hline
CS & 10x blinding & 6 ms \\\hline
RSA 1024 bit & 10x blinding & 3.886 ms \\\hline
RSA 2048 bit & 10x blinding & 7 ms \\\hline
RSA 3072 bit & 10x blinding & 14 ms \\\hline
RSA 4096 bit & 10x blinding & 23 ms \\\hline
\hline
CS & 10x signing & 0.379 ms \\\hline
RSA 1024 bit & 10x signing & 15 ms \\\hline
RSA 2048 bit & 10x signing & 71 ms \\\hline
RSA 3072 bit & 10x signing & 177 ms \\\hline
RSA 4096 bit & 10x signing & 357 ms \\\hline
\hline
CS & 10x unblinding & 0.001 ms \\\hline
RSA 1024 bit & 10x unblinding & 6 ms \\\hline
RSA 2048 bit & 10x unblinding & 24 ms \\\hline
RSA 3072 bit & 10x unblinding & 53 ms \\\hline
RSA 4096 bit & 10x unblinding & 93 ms \\\hline
\hline
CS & 10x verifying & 2.610 ms \\\hline
RSA 1024 bit & 10x verifying & 2.303 ms \\\hline
RSA 2048 bit & 10x verifying & 4.386 ms \\\hline
RSA 3072 bit & 10x verifying & 7 ms \\\hline
RSA 4096 bit & 10x verifying & 11 ms \\\hline
\end{tabular}
\caption{Comparison on AMD Ryzen Embedded R1606G}
\label{tab:comp-sign-amd-embedded}
\end{table}
\section{risc64}
Detailed comparison of each operation can be found in table \ref{tab:comp-sign-risc64}.
\begin{bfhBox}[BFH-MediumBlue]{Setup}
CPU: 4-core risc64 processor\\
OS: Linux risc-v-unleashed-000 5.11.0-1022-generic \#23~20.04.1-Ubuntu SMP Thu Oct 21 10:16:27 UTC 2021 riscv64 riscv64 riscv64 GNU/Linux\\
libsodium:riscv64 version: 1.8.7-5ubuntu2 \\
libgcrypt:riscv64 version: 1.0.18-1build1
\end{bfhBox}
\begin{table}[ht]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{llr}
\rowcolor{BFH-tablehead}
\textbf{Signature Scheme} & \textbf{Operation} & \textbf{Speed} \\\hline
CS & 10x key generation & 4.144 ms \\\hline
RSA 1024 bit & 10x key generation & 2923 ms \\\hline
RSA 2048 bit & 10x key generation & 28 000 ms \\\hline
RSA 3072 bit & 10x key generation & 174 000 ms \\\hline
RSA 4096 bit & 10x key generation & 600 000 ms \\\hline
\hline
CS & 10x r0, r1 derive and R1,R2 calculation & 10 ms \\\hline
CS & 10x derivation of blinding secrets & 2.514 ms \\\hline
CS & 10x blinding & 72 ms \\\hline
RSA 1024 bit & 10x blinding & 37 ms \\\hline
RSA 2048 bit & 10x blinding & 93 ms \\\hline
RSA 3072 bit & 10x blinding & 170 ms \\\hline
RSA 4096 bit & 10x blinding & 277 ms \\\hline
\hline
CS & 10x signing & 1.697 ms \\\hline
RSA 1024 bit & 10x signing & 215 ms \\\hline
RSA 2048 bit & 10x signing & 1040 ms \\\hline
RSA 3072 bit & 10x signing & 2883 ms \\\hline
RSA 4096 bit & 10x signing & 5000 ms \\\hline
\hline
CS & 10x unblinding & 0.022 ms \\\hline
RSA 1024 bit & 10x unblinding & 62 ms \\\hline
RSA 2048 bit & 10x unblinding & 150 ms \\\hline
RSA 3072 bit & 10x unblinding & 275 ms \\\hline
RSA 4096 bit & 10x unblinding & 431 ms \\\hline
\hline
CS & 10x verifying & 29 ms \\\hline
RSA 1024 bit & 10x verifying & 22 ms \\\hline
RSA 2048 bit & 10x verifying & 54 ms \\\hline
RSA 3072 bit & 10x verifying & 99 ms \\\hline
RSA 4096 bit & 10x verifying & 166 ms \\\hline
\end{tabular}
\caption{Comparison on risc64}
\label{tab:comp-sign-risc64}
\end{table}
\section{POWER9}
Detailed comparison of each operation can be found in table \ref{tab:comp-sign-POWER9}.
\begin{bfhBox}[BFH-MediumBlue]{Setup}
CPU: 176-core power9\\
architecture: pp64le \\
OS: Linux power9 5.11.0-34-generic \#36-Ubuntu SMP Thu Aug 26 19:19:54 UTC 2021 ppc64le ppc64le ppc64le GNU/Linux \\
libsodium:a::ppc64el version: 1.8.7-2ubuntu2.1 \\
libgcrypt::ppc64el version: 1.0.18-1
\end{bfhBox}
\begin{table}[ht]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{llr}
\rowcolor{BFH-tablehead}
\textbf{Signature Scheme} & \textbf{Operation} & \textbf{Speed} \\\hline
CS & 10x key generation & 0.275 ms \\\hline
RSA 1024 bit & 10x key generation & 290 ms \\\hline
RSA 2048 bit & 10x key generation & 3743 ms \\\hline
RSA 3072 bit & 10x key generation & 15 000 ms \\\hline
RSA 4096 bit & 10x key generation & 45 000 ms \\\hline
\hline
CS & 10x r0, r1 derive and R1,R2 calculation & 0.749 ms \\\hline
CS & 10x derivation of blinding secrets & 0.267 ms \\\hline
CS & 10x blinding & 4.996 ms \\\hline
RSA 1024 bit & 10x blinding & 3.952 ms \\\hline
RSA 2048 bit & 10x blinding & 10 ms \\\hline
RSA 3072 bit & 10x blinding & 17 ms \\\hline
RSA 4096 bit & 10x blinding & 27 ms \\\hline
\hline
CS & 10x signing & 0.221 ms \\\hline
RSA 1024 bit & 10x signing & 25 ms \\\hline
RSA 2048 bit & 10x signing & 135 ms \\\hline
RSA 3072 bit & 10x signing & 381 ms \\\hline
RSA 4096 bit & 10x signing & 762 ms \\\hline
\hline
CS & 10x unblinding & 0.002 ms \\\hline
RSA 1024 bit & 10x unblinding & 9 ms \\\hline
RSA 2048 bit & 10x unblinding & 34 ms \\\hline
RSA 3072 bit & 10x unblinding & 80 ms \\\hline
RSA 4096 bit & 10x unblinding & 141 ms \\\hline
\hline
CS & 10x verifying & 2.458 ms \\\hline
RSA 1024 bit & 10x verifying & 2.365 ms \\\hline
RSA 2048 bit & 10x verifying & 6 ms \\\hline
RSA 3072 bit & 10x verifying & 10 ms \\\hline
RSA 4096 bit & 10x verifying & 16 ms \\\hline
\end{tabular}
\caption{Comparison on POWER9}
\label{tab:comp-sign-POWER9}
\end{table}
\section{ARMv7 Processor}
Detailed comparison of each operation can be found in table \ref{tab:comp-sign-armv7}.
\begin{bfhBox}[BFH-MediumBlue]{Setup}
CPU: 8-core ARMv7 Processor rev 3 (v7l)
Architecture: armv7 \\
OS: Linux odroidxu4 4.14.150-odroidxu4 \#2 SMP PREEMPT Mon Oct 28 08:07:45 CET 2019 armv7l GNU/Linux\\
libsodium:armhf version: 1.9.4-5 \\
libgcrypt:armhf version: 1.0.18-1
\end{bfhBox}
\begin{table}[ht]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{llr}
\rowcolor{BFH-tablehead}
\textbf{Signature Scheme} & \textbf{Operation} & \textbf{Speed} \\\hline
CS & 10x key generation & 1.719 ms \\\hline
RSA 1024 bit & 10x key generation & 1050 ms \\\hline
RSA 2048 bit & 10x key generation & 8000 ms \\\hline
RSA 3072 bit & 10x key generation & 53 000 ms \\\hline
RSA 4096 bit & 10x key generation & 159 000 ms \\\hline
\hline
CS & 10x r0, r1 derive and R1,R2 calculation & 3.621 ms \\\hline
CS & 10x derivation of blinding secrets & 0.514 ms \\\hline
CS & 10x blinding & 24 ms \\\hline
RSA 1024 bit & 10x blinding & 10 ms \\\hline
RSA 2048 bit & 10x blinding & 26 ms \\\hline
RSA 3072 bit & 10x blinding & 45 ms \\\hline
RSA 4096 bit & 10x blinding & 78 ms \\\hline
\hline
CS & 10x signing & 0.481 ms \\\hline
RSA 1024 bit & 10x signing & 87 ms \\\hline
RSA 2048 bit & 10x signing & 385 ms \\\hline
RSA 3072 bit & 10x signing & 1038 ms \\\hline
RSA 4096 bit & 10x signing & 2073 ms \\\hline
\hline
CS & 10x unblinding & 0.008 ms \\\hline
RSA 1024 bit & 10x unblinding & 26 ms \\\hline
RSA 2048 bit & 10x unblinding & 90 ms \\\hline
RSA 3072 bit & 10x unblinding & 195 ms \\\hline
RSA 4096 bit & 10x unblinding & 344 ms \\\hline
\hline
CS & 10x verifying & 11 ms \\\hline
RSA 1024 bit & 10x verifying & 5 ms \\\hline
RSA 2048 bit & 10x verifying & 15 ms \\\hline
RSA 3072 bit & 10x verifying & 28 ms \\\hline
RSA 4096 bit & 10x verifying & 42 ms \\\hline
\end{tabular}
\caption{Comparison on ARMv7}
\label{tab:comp-sign-armv7}
\end{table}
\section{Performance of the Security Module}
These performance measurements are only done on one hardware setup.
The performance tests of the cryptographic routines are more meaningful, the architecture of the Taler exchange could change a lot.
Furthermore, there could be made performance improvements at costs of security by doing the operations requiring the private keys directly in the httpd process.
Because of security reasons, the current design with the security module makes a lot of sense.
It has to be kept in mind that the following performance benchmarks are interesting to see, but could vary a lot with changes inside the codebase.
The performance of the signatures with the security module can be found in table \ref{tab:comp-sign-full}
\begin{bfhBox}[BFH-MediumBlue]{Setup}
CPU: 8-core AMD Ryzen 7 PRO 5850U \\
OS: Ubuntu 21.10 Linux 5.13.0-25-generic \#26-Ubuntu SMP Fri Jan 7 15:48:31 UTC 2022 x86\_64 x86\_64 x86\_64 GNU/Linux \\
libsodium version: 1.0.18-1build1 \\
libgcrypt version: 1.8.7-5ubuntu2
\end{bfhBox}
\begin{table}[ht]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{lll}
\rowcolor{BFH-tablehead}
\textbf{Signature Scheme} & \textbf{Test} & \textbf{Speed} \\\hline
CS & 100 sequential signature operations & 2.591 ms \\\hline
RSA 1024 bit & 100 sequential signature operations & 79 ms \\\hline
RSA 2048 bit & 100 sequential signature operations & 350 ms \\\hline
RSA 3072 bit & 100 sequential signature operations & 893 ms \\\hline
RSA 4092 & 100 sequential signature operations & 1811 ms \\\hline
\hline
CS & 100 parallel signature operations & 14 ms \\\hline
RSA 1024 bit & 100 parallel signature operations & 125 ms \\\hline
RSA 2048 bit & 100 parallel signature operations & 573ms \\\hline
RSA 3072 bit & 100 parallel signature operations & 1420 ms \\\hline
RSA 4092 & 100 parallel signature operations & 3279 ms \\\hline
\hline
CS & 800 parallel signature operations & 19 ms \\\hline
RSA 1024 bit & 800 parallel signature operations & 137 ms \\\hline
RSA 2048 bit & 800 parallel signature operations & 653 ms \\\hline
RSA 3072 bit & 800 parallel signature operations & 1451 ms \\\hline
RSA 4092 & 800 parallel signature operations & 3388 ms \\\hline
\end{tabular}
\caption{Performance comparison of the security module}
\label{tab:comp-sign-full}
\end{table}
\input{content/appendix/rsa-redesign.tex}

279
doc/cs/content/appendix/crypto_implementation.tex Normal file
View File

@ -0,0 +1,279 @@
\begin{lstlisting}[style=bfh-c,language=C,, caption={Crypto Implementation API}, label={lst:cryptoapi}]
#include <sodium.h>
/**
* IMPLEMENTATION NOTICE:
*
* This is an implementation of the Schnorr, Blind Schnorr and
* Clause Blind Schnorr Signature Scheme using Curve25519.
* We use libsodium wherever possible.
*
* Blind Schnorr: The Blind Schnorr Signature Scheme is BROKEN!
* Use the Clause Blind Schnorr Signature Scheme instead.
*
* Clause Blind Schnorr Signature Scheme:
* This is a variation of the Blind Schnorr Signature Scheme where all operations
* before the signature creation are performed twice.
* The signer randomly chooses one of the two sessions and only creates the signature for this session.
* Note that the Clause part needs to be implemented by whoever uses this API.
* Further details about the Clause Blind Schnorr Signature Scheme can be found here:
* https://eprint.iacr.org/2019/877.pdf
*/
/**
* Curve25519 Scalar
*/
struct GNUNET_CRYPTO_Cs25519Scalar
{
/**
* 32 byte scalar
*/
unsigned char d[crypto_core_ed25519_SCALARBYTES];
};
/**
* Curve25519 point
*/
struct GNUNET_CRYPTO_Cs25519Point
{
/**
* This is a point on the Curve25519.
* The x coordinate can be restored using the y coordinate
*/
unsigned char y[crypto_core_ed25519_BYTES];
};
/**
* The private information of an Schnorr key pair.
*/
struct GNUNET_CRYPTO_CsPrivateKey
{
struct GNUNET_CRYPTO_Cs25519Scalar scalar;
};
/**
* The public information of an Schnorr key pair.
*/
struct GNUNET_CRYPTO_CsPublicKey
{
struct GNUNET_CRYPTO_Cs25519Point point;
};
/**
* Secret used for blinding (alpha and beta).
*/
struct GNUNET_CRYPTO_CsBlindingSecret
{
struct GNUNET_CRYPTO_Cs25519Scalar alpha;
struct GNUNET_CRYPTO_Cs25519Scalar beta;
};
/**
* the private r used in the signature
*/
struct GNUNET_CRYPTO_CsRSecret
{
struct GNUNET_CRYPTO_Cs25519Scalar scalar;
};
/**
* the public R (derived from r) used in c
*/
struct GNUNET_CRYPTO_CsRPublic
{
struct GNUNET_CRYPTO_Cs25519Point point;
};
/**
* Schnorr c to be signed
*/
struct GNUNET_CRYPTO_CsC
{
struct GNUNET_CRYPTO_Cs25519Scalar scalar;
};
/**
* s in the signature
*/
struct GNUNET_CRYPTO_CsS
{
struct GNUNET_CRYPTO_Cs25519Scalar scalar;
};
/**
* blinded s in the signature
*/
struct GNUNET_CRYPTO_CsBlindS
{
struct GNUNET_CRYPTO_Cs25519Scalar scalar;
};
/**
* CS Signtature containing scalar s and point R
*/
struct GNUNET_CRYPTO_CsSignature
{
/**
* Schnorr signatures are composed of a scalar s and a curve point
*/
struct GNUNET_CRYPTO_CsS s_scalar;
struct GNUNET_CRYPTO_Cs25519Point r_point;
};
/**
* Nonce
*/
struct GNUNET_CRYPTO_CsNonce
{
/*a nonce*/
unsigned char nonce[256 / 8];
};
/**
* Create a new random private key.
*
* @param[out] priv where to write the fresh private key
*/
void
GNUNET_CRYPTO_cs_private_key_generate (struct GNUNET_CRYPTO_CsPrivateKey *priv);
/**
* Extract the public key of the given private key.
*
* @param priv the private key
* @param[out] pub where to write the public key
*/
void
GNUNET_CRYPTO_cs_private_key_get_public (const struct GNUNET_CRYPTO_CsPrivateKey *priv,
struct GNUNET_CRYPTO_CsPublicKey *pub);
/**
* Derive a new secret r pair r0 and r1.
* In original papers r is generated randomly
* To provide abort-idempotency, r needs to be derived but still needs to be UNPREDICTABLE
* To ensure unpredictability a new nonce should be used when a new r needs to be derived.
* Uses HKDF internally.
* Comment: Can be done in one HKDF shot and split output.
*
* @param nonce is a random nonce
* @param lts is a long-term-secret in form of a private key
* @param[out] r array containing derived secrets r0 and r1
*/
void
GNUNET_CRYPTO_cs_r_derive (const struct GNUNET_CRYPTO_CsNonce *nonce,
const struct GNUNET_CRYPTO_CsPrivateKey *lts,
struct GNUNET_CRYPTO_CsRSecret r[2]);
/**
* Extract the public R of the given secret r.
*
* @param r_priv the private key
* @param[out] r_pub where to write the public key
*/
void
GNUNET_CRYPTO_cs_r_get_public (const struct GNUNET_CRYPTO_CsRSecret *r_priv,
struct GNUNET_CRYPTO_CsRPublic *r_pub);
/**
* Derives new random blinding factors.
* In original papers blinding factors are generated randomly
* To provide abort-idempotency, blinding factors need to be derived but still need to be UNPREDICTABLE
* To ensure unpredictability a new nonce has to be used.
* Uses HKDF internally
*
* @param secret is secret to derive blinding factors
* @param secret_len secret length
* @param[out] bs array containing the two derivedGNUNET_CRYPTO_CsBlindingSecret
*/
void
GNUNET_CRYPTO_cs_blinding_secrets_derive (const struct GNUNET_CRYPTO_CsNonce *blind_seed,
struct GNUNET_CRYPTO_CsBlindingSecret bs[2]);
/**
* Calculate two blinded c's
* Comment: One would be insecure due to Wagner's algorithm solving ROS
*
* @param bs array of the two blinding factor structs each containing alpha and beta
* @param r_pub array of the two signer's nonce R
* @param pub the public key of the signer
* @param msg the message to blind in preparation for signing
* @param msg_len length of message msg
* @param[out] blinded_c array of the two blinded c's
*/
void
GNUNET_CRYPTO_cs_calc_blinded_c (const struct GNUNET_CRYPTO_CsBlindingSecret bs[2],
const struct GNUNET_CRYPTO_CsRPublic r_pub[2],
const struct GNUNET_CRYPTO_CsPublicKey *pub,
const void *msg,
size_t msg_len,
struct GNUNET_CRYPTO_CsC blinded_c[2]);
/**
* Sign a blinded c
* This function derives b from a nonce and a longterm secret
* In original papers b is generated randomly
* To provide abort-idempotency, b needs to be derived but still need to be UNPREDICTABLE.
* To ensure unpredictability a new nonce has to be used for every signature
* HKDF is used internally for derivation
* r0 and r1 can be derived prior by using GNUNET_CRYPTO_cs_r_derive
*
* @param priv private key to use for the signing and as LTS in HKDF
* @param r array of the two secret nonce from the signer
* @param c array of the two blinded c to sign c_b
* @param nonce is a random nonce
* @param[out] blinded_signature_scalar where to write the signature
* @return 0 or 1 for b (see Clause Blind Signature Scheme)
*/
int
GNUNET_CRYPTO_cs_sign_derive(const struct GNUNET_CRYPTO_CsPrivateKey *priv,
const struct GNUNET_CRYPTO_CsRSecret r[2],
const struct GNUNET_CRYPTO_CsC c[2],
const struct GNUNET_CRYPTO_CsNonce *nonce,
struct GNUNET_CRYPTO_CsBlindS *blinded_signature_scalar
);
/**
* Unblind a blind-signed signature using a c that was blinded
*
* @param blinded_signature_scalar the signature made on the blinded c
* @param bs the blinding factors used in the blinding
* @param[out] signature_scalar where to write the unblinded signature
*/
void
GNUNET_CRYPTO_cs_unblind (const struct GNUNET_CRYPTO_CsBlindS *blinded_signature_scalar,
const struct GNUNET_CRYPTO_CsBlindingSecret *bs,
struct GNUNET_CRYPTO_CsS *signature_scalar);
/**
* Verify whether the given message corresponds to the given signature and the
* signature is valid with respect to the given public key.
*
* @param sig signature that is being validated
* @param pub public key of the signer
* @param msg is the message that should be signed by @a sig (message is used to calculate c)
* @param msg_len is the message length
* @returns #GNUNET_YES on success, #GNUNET_SYSERR if key parameter(s) invalid #GNUNET_NO if signature invalid
*/
enum GNUNET_GenericReturnValue
GNUNET_CRYPTO_cs_verify (const struct GNUNET_CRYPTO_CsSignature *sig,
const struct GNUNET_CRYPTO_CsPublicKey *pub,
const void *msg,
size_t msg_len);
\end{lstlisting}

209
doc/cs/content/appendix/rsa-redesign.tex Normal file
View File

@ -0,0 +1,209 @@
\chapter{Redesigned RSA Protocols}
In order to bring the RSA and \gls{CSBS} protocols closer, this chapter describes a variant of the RSA protocols with the same changes as in the \gls{CSBS} versions (where they can be applied).
\section{Withdraw Protocol}
\begin{figure}[htp]
\begin{equation*}
\resizebox{1.0\textwidth}{!}{$\displaystyle
\begin{array}{ l c l }
\text{Customer} & & \text{Exchange}
\\ \text{knows:} & & \text{knows:}
\\ \text{reserve keys } w_s, W_p & & \text{reserve public key } W_p
\\ \text{denomination public key } D_p = e, N & & \text{denomination keys } d_s, D_p
\\ & &
\\\text{generate withdraw secret:}
\\ \omega := randombytes(32)
\\ \text{persist } \langle \omega, D_p \rangle
\\\text{derive coin key pair:} & &
\\ c_s := \text{HKDF}(256, \omega, \text{"cs"})
\\ C_p := \text{Ed25519.GetPub}(c_s)
\\ \text{blind:} & &
\\ b_s := \text{HKDF}(256, \omega, \text{"b-seed"})
\\ r := \text{FDH}(b_s)
\\ m' := \text{FDH}(N, C_p)*r^{e} \mod N & &
\\ \text{sign with reserve private key:} & &
\\ \rho_W := \langle D_p, m' \rangle & &
\\ \sigma_W := \text{Ed25519.Sign}(w_s, \rho_W) & &
\\ & \xrightarrow[\rule{2.5cm}{0pt}]{\rho = W_p, \sigma_W, \rho_W} &
\\ & & \langle D_p, m' \rangle := \rho_W
\\ & & \text{verify if } D_p \text{ is valid}
\\ & & \text{check } \text{Ed25519.Verify}(W_p, \rho_W, \sigma_W)
\\ & & \sigma'_c = (m')^{d_s} \mod N
\\ & & \text{decrease balance if sufficient and}
\\ & & \text{persist } \langle D_p, s \rangle
\\ & \xleftarrow[\rule{2.5cm}{0pt}]{\sigma'_c} &
\\ \text{unblind:}& &
\\ \sigma_c = \sigma'_c*r^{-1} & &
\\ \text{verify signature:}& &
\\ \textbf{check if } \sigma_c^{e} = \text{FDH}(N, C_p) & &
\\ & &
\\ \text{resulting coin: } c_s, C_p, \sigma_c, D_p & &
\\ & &
\\ \text{implementation note: minimum of}
\\ \text{persisted values is } \langle \omega, \sigma_c \rangle
\end{array}$
}
\end{equation*}
\caption{Redesigned RSA withdrawal process}
\label{fig:withdrawal-process-rsa-redesign}
\end{figure}
The changes to the RSA witdhdraw protocol (see \autoref{fig:withdrawal-process-rsa-redesign}) are limited to the derivation of the coin and blinding factor.
\section{Refresh Protocol}
The changes to the refresh protocol are related to the derivation of transfer secrets and subsequent operations, see \autoref{fig:refresh-derive-rsa-redesign}, \autoref{fig:refresh-part1-rsa-redesign} and \autoref{fig:refresh-part2-rsa-redesign}.
\begin{figure}[htp]
\centering
\fbox{%
\procedure[codesize=\small]{$\text{RefreshDerive}(t, \langle e, N \rangle, C_p)$}{%
T := \text{Curve25519.GetPub}(t) \\
x := \textrm{ECDH-EC}(t, C_p) \\
b_s := \text{HKDF}(256, x, \text{"b-seed"}) \\
r := \text{FDH}(b_s) \\
c'_s := \text{HKDF}(256,x,"c") \\
C'_p := \text{Ed25519.GetPub}(c'_s) \\
\overline{m} := r^e * C'_p \mod N \\
\pcreturn \langle T, c_s', C_p', \overline{m} \rangle
}
}
\caption{Redesigned RSA RefreshDerive algorithm}
\label{fig:refresh-derive-rsa-redesign}
\end{figure}
\begin{figure}[htp]
\begin{equation*}
\resizebox{1.0\textwidth}{!}{$\displaystyle
\begin{array}{ l c l }
% preliminaries
\text{Customer} & & \text{Exchange}
\\ \text{knows:} & & \text{knows:}
\\ \text{denomination public key } D_{p(i)} & & \text{denomination keys } d_{s(i)}, D_{p(i)}
\\ \text{coin}_0 = \langle D_{p(0)}, c_s^{(0)}, C_p^{(0)}, \sigma_c^{(0)} \rangle & &
% refresh request
\\ \text{Select} \langle N_t, e_t\rangle := D_{p(t)} \in D_{p(i)}
\\ \omega := randombytes(32)
\\ \text{persist } \langle \omega, D_{p(t)} \rangle
\\ \textbf{for } i = 1, \dots, \kappa: % generate k derives
\\ t_i := \text{HKDF}(256, \omega,\text{"t} i \text{"} ) % seed generation
\\ X_i := \text{RefreshDerive}(t_i, D_{p(t)}, C_p^{(0)})
\\ (T_i, c_s^{(i)}, C_p^{(i)}, \overline{m}_i) := X_i
\\ \textbf{endfor}
\\ h_T := H(T_1, \dots, T_k)
\\ h_{\overline{m}} := H(\overline{m}_1, \dots, \overline{m}_k)
\\ h_C := H(h_t, h_{\overline{m}})
\\ \rho_{RC} := \langle h_C, D_{p(t)}, D_{p(0)}, C_p^{(0)}, \sigma_C^{(0)} \rangle
\\ \sigma_{RC} := \text{Ed25519.Sign}(c_s^{(0)}, \rho_{RC})
\\ \text{Persist refresh-request} \langle \omega, \rho_{RC}, \sigma_{RC} \rangle
\\ & \xrightarrow[\rule{2.5cm}{0pt}]{\rho_{RC}, \sigma_{RC}} &
% Exchange checks refresh request
\\ & & (h_C, D_{p(t)}, D_{p(0)}, C_p^{(0)}, \sigma_C^{(0)} = \rho_{RC})
\\ & & \textbf{check} \text{Ed25519.Verify}(C_p^{(0)}, \sigma_{RC}, \rho_{RC})
\\ & & x \rightarrow \text{GetOldRefresh}(\rho_{RC})
\\ & & \textbf{Comment: }\text{GetOldRefresh} (\rho_{RC} \mapsto \{\bot,\gamma\})
\\ & & \pcif x = \bot
\\ & & v := \text{Denomination}(D_{p(t)})
\\ & & \langle e_0, N_0 \rangle := D_{p(0)}
\\ & & \textbf{check } \text{IsOverspending}(C_p^{(0)}, D_ {p(0)}, v)
\\ & & \textbf{check } D_{p(t)} \in \{D_{p(i)}\}
\\ & & \textbf{check } \text{FDH}(N_0, C_p^{(0)}) \equiv_{N_0} (\sigma_0^{(0)})^{e_0}
\\ & & \text{MarkFractionalSpend}(C_p^{(0)}, v)
\\ & & \gamma \leftarrow \{1, \dots, \kappa\}
\\ & & \text{Persist refresh-record } \langle \rho_{RC},\gamma \rangle
\\ & & \pcelse
\\ & & \gamma := x
\\ & & \textbf{endif}
\\ & \xleftarrow[\rule{2.5cm}{0pt}]{\gamma} &
\\
\\
\\ & \textit{Continued in figure \ref{fig:refresh-part2}} &
%\\ \pcintertext[dotted]{(Continued in Figure)}
\end{array}$
}
\end{equation*}
\caption{Redesigned RSA refresh protocol (commit phase)}
\label{fig:refresh-part1-rsa-redesign}
\end{figure}
\begin{figure}[htp]
\begin{equation*}
\resizebox{1.0\textwidth}{!}{$\displaystyle
\begin{array}{ l c l }
% preliminaries
\text{Customer} & & \text{Exchange}
\\ & \textit{Continuation of figure \ref{fig:refresh-part1}} &
\\
\\
% Check challenge and send challenge response (reveal not selected msgs)
\\ & \xleftarrow[\rule{2.5cm}{0pt}]{\gamma} &
\\ \textbf{check } \text{IsConsistentChallenge}(\rho_{RC}, \gamma)
\\ \textbf{Comment: } \text{IsConsistentChallenge}\\(\rho_{RC}, \gamma) \mapsto \{ \bot,\top \}
\\
\\ \text{Persist refresh-challenge} \langle \rho_{RC}, \gamma \rangle
\\ S := \langle t_1, \dots, t_{\gamma-1}, t_{\gamma+1}, \dots, t_\kappa \rangle % all seeds without the gamma seed
\\ \rho_L = \langle C_p^{(0)}, D_{p(t)}, T_{\gamma},\overline{m}_\gamma \rangle
\\ \rho_{RR} = \langle T_\gamma, \overline{m}_\gamma, S \rangle
\\ \sigma_{L} = \text{Ed25519.Sign}(c_s^{(0)}, \rho_{L})
\\ & \xrightarrow[\rule{2.5cm}{0pt}]{\rho_{RR},\rho_L, \sigma_{L}} &
% check revealed msgs and sign coin
\\ & & \langle T'_\gamma, \overline{m}'_\gamma, S \rangle := \rho_{RR}
\\ & & \langle t_1, \dots, t_{\gamma-1}, t_{\gamma+1}, \dots, t_\kappa \rangle ) := S
\\ & & \textbf{check } \text{Ed25519.Verify}(C_p^{(0)}, \sigma_L, \rho_L)
\\ & & \textbf{for} i = 1,\dots, \gamma-1, \gamma+1,\dots, \kappa
\\ & & X_i := \text{RefreshDerive}(t_i, D_{p(t)}, C_p^{(0)})
\\ & & \langle T_i, c_s^{(i)}, C_p^{(i)}, \overline{m}_i \rangle := X_i
\\ & & \textbf{endfor}
\\ & & h_T' = H(T_1,\dots,T_{\gamma-1},T'_{\gamma},T_{\gamma+1},\dots,T_\kappa)
\\ & & h_{\overline{m}}' = H(\overline{m}_1,\dots,\overline{m}_{\gamma-1},\overline{m}'_{\gamma},\overline{m}_{\gamma+1},\dots,\overline{m}_\kappa)
\\ & & h_C' = H(h_T', h_{\overline{m}}')
\\ & & \textbf{check } h_C = h_C'
\\ & & \overline{\sigma}_C^{(\gamma)} := \overline{m}^{d_{s(t)}}
\\ & & \text{persist } \langle \rho_L, \sigma_L \rangle
\\ & \xleftarrow[\rule{2.5cm}{0pt}]{\overline{\sigma}_C^{(\gamma)}} &
% Check coin signature and persist coin
\\ \sigma_C^{(\gamma)} := r^{-1}\overline{\sigma}_C^{(\gamma)}
\\ \textbf{check if } (\sigma_C^{(\gamma)})^{e_t} \equiv_{N_t} C_p^{(\gamma)}
\\ \text{Persist coin} \langle D_{p(t)}, c_s^{(\gamma)}, C_p^{(\gamma)}, \sigma_C^{(\gamma)} \rangle
\end{array}$
}
\end{equation*}
\caption{Redesigned RSA refresh protocol (reveal phase)}
\label{fig:refresh-part2-rsa-redesign}
\end{figure}
\section{Linking Protocol}
The changes are described in \autoref{fig:refresh-link-rsa-redesign}.
\begin{figure}[htp]
\begin{equation*}
\resizebox{1.0\textwidth}{!}{$\displaystyle
\begin{array}{ l c l }
% preliminaries
\text{Customer} & & \text{Exchange}
\\ \text{knows:} & & \text{knows:}
\\ \text{coin}_0 = \langle D_{p(0)}, c_s^{(0)}, C_p^{(0)}, \sigma_{C}^{(0)} \rangle
\\ & \xrightarrow[\rule{2.5cm}{0pt}]{C_{p(0)}} &
\\ & & L := \text{LookupLink}(C_{p(0)})
\\ & & \textbf{Comment: } \text{LookupLink}(C_p) \mapsto \{\langle \rho_L^{(i)},
\\ & & \sigma_L^{(i)}, \overline{\sigma}_C^{(i)} \rangle\}
\\ & \xleftarrow[\rule{2.5cm}{0pt}]{L} &
\\ \pcfor \langle \rho_{L}^{(i)}, \overline{\sigma}_L^{(i)}, \sigma_C^{(i)} \rangle \in L
\\ \langle \hat{C}_p^{(i)}, D_{p(t)}^{(i)}, T_\gamma^{(i)}, \overline{m}_\gamma^{(i)} \rangle := \rho_L^{(i)}
\\ \langle e_t^{(i)}, N_t^{(i)} \rangle := D_{p(t)}^{(i)}
\\ \textbf{check } \hat{C}_p^{(i)} \equiv C_p^{(0)}
\\ \textbf{check } \text{Ed25519.Verify}(C_p^{(0)}, \rho_{L}^{(i)}, \sigma_L^{(i)})
\\ x_i := \text{ECDH}(c_s^{(0)}, T_{\gamma}^{(i)})
\\ c_s^{(i)} := \text{HKDF}(256,x_i,"c")
\\ C_p^{(i)} := \text{Ed25519.GetPub}(c_s^{(i)})
\\ b_s^{(i)} := \text{HKDF}(256, x_i, \text{"b-seed"})
\\ r_i := \text{FDH}(b_s^{(i)})
\\ \sigma_C^{(i)} := (r_i)^{-1} \cdot \overline{m}_\gamma^{(i)}
\\ \textbf{check } (\sigma_C^{(i)})^{e_t^{(i)}} \equiv_{N_t^{(i)}} C_p^{(i)}
\\ \text{(Re-)obtain coin} \langle D_{p(t)}^{(i)},c_s^{(i)}, C_p^{(i)}, \sigma_C^{(i)} \rangle
\end{array}$
}
\end{equation*}
\caption{Redesigned RSA linking protocol}
\label{fig:refresh-link-rsa-redesign}
\end{figure}

35
doc/cs/content/chapter_01.tex Normal file
View File

@ -0,0 +1,35 @@
%!TEX root = ../dokumentation.tex
\chapter{Das erste Kapitel}
\section{Hello}
Erste Erwähnung eines Akronyms wird als Fußnote angezeigt. Jede weitere wird
nur verlinkt: \ac{AGPL}. Zweite Erwähnung \ac{AGPL}
Verweise auf das Glossar: \gls{Glossareintrag}, \glspl{Glossareintrag}
Nur erwähnte Literaturverweise werden auch im Literaturverzeichnis gedruckt:
\cite{baumgartner:2002}, \cite{dreyfus:1980}
\Gls{Glossareintrag}
Meine erste Fußnote\footnote{Ich bin eine Fußnote}
\begin{wrapfigure}{r}{.4\textwidth}
\includegraphics[height=.4\textwidth]{taler.png}
\vspace{-15pt}
\caption{Das Logo der Musterfirma\footnotemark}
\end{wrapfigure}
%Quelle muss in Fußnote stehen (da sonst aufgrund eines Fehlers nicht kompiliert
% wird)
\footnotetext{aus \cite{mustermann:2012}}
Ein ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der das Bild
umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der
das Bild umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer
Text, der das Bild umfließt. Ein ganz langer Text, der das Bild umfließt. Ein
ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der das Bild
umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der
das Bild umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der das Bild
umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der
das Bild umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer
Text, der das Bild umfließt. Ein ganz langer Text, der das Bild umfließt. Ein
ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der das Bild
umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der
das Bild umfließt.

160
doc/cs/content/withdraw_loophole_remediation.tex Normal file
View File

@ -0,0 +1,160 @@
\section{Remediation of the Withdraw Loophole}
The withdraw loophole allows untaxed and untraceable payments by "misusing" the withdraw protocol.
It allows withdraw operations where owner of the resulting coins isn't the owner of the reserve that the coins where withdrawn from.
It is used for tipping and can therefore be seen as a feature.
Using the withdraw loophole for payments is illustrated in figure \ref{fig:withdraw-loophole-exploit}.
Note that we omitted the parts leading up to the coin creation (contract, agreement of price, number of coins and their denominations).
This is how it works on a high level:
\begin{enumerate}
\item The malicous merchant generates and blinds coins, which are then transmitted to the customer
\item The customer authorizes the withdraw from his reserve by signing the blinded coins with the private key of his reserve, thus generating withdraw confirmations.
\item The withdraw confirmations are transmitted to the exchange, which generates the signatures and returns them to the malicous merchant.
\item The malicous merchant unblinds the signatures.
He is now in possession of the coin, thus the payment is completed.
\end{enumerate}
\begin{figure}[h]
\begin{equation*}
\begin{array}{ l c l}
% preliminaries
\text{Customer} & & \text{malicous Merchant}
\\ \text{knows:} & & \text{knows:}
\\ \text{reserve keys } w_s, W_p
\\ \text{denomination public key } D_p = \langle e, N \rangle & & \text{denomination public key } D_p = \langle e, N \rangle
\\
% generate coin
\\ & & \text{generate coin key pair:}
\\ & & c_s, C_p \leftarrow \text{Ed25519.KeyGen}()
% blind
\\ & & \text{blind:}
\\ & & r \leftarrow random \in \mathbb{Z}_N^*
\\ & & m' := \text{FDH}(N, C_p)*r^{e} \mod N
% sing with reserve sk
\\ & \xleftarrow[\rule{2cm}{0pt}]{m'}
\\ \text{sign with reserve private key:}
\\ \rho_W := \langle D_p, m' \rangle
\\ \sigma_W := \text{Ed25519.Sign}(w_s, \rho_W)
\\ & \xrightarrow[\rule{2cm}{0pt}]{ \langle W_p, \sigma_W, \rho_W \rangle }
\\
% TODO add some kind of separator
\hline
\\
\text{malicous Merchant} & & \text{Exchange}
\\\text{knows:} & & \text{knows:}
\\& & \text{reserve public key } W_p
\\ \text{denomination public key } D_p = \langle e, N \rangle & & \text{denomination keys } d_s, D_p
\\
\\ & \xrightarrow[\rule{2cm}{0pt}]{ \langle W_p, \sigma_W, \rho_W \rangle }
\\ & & \langle D_p, m' \rangle := \rho_W
\\ & & \text{verify if } D_p \text{ is valid}
\\ & & \textbf{check } \text{Ed25519.Verify}(W_p, \rho_W, \sigma_W)
\\ & & \text{decrease balance if sufficient}
\\ & & \text{sign:}
\\ & & \sigma'_c := (m')^{d_s} \mod N
\\ & \xleftarrow[\rule{2cm}{0pt}]{\sigma'_c}
\\ \text{unblind:}
\\ \sigma_c := \sigma'_c*r^{-1}
\\ \text{verify signature:}
\\ \textbf{check if } \sigma_c = \text{FDH}(N, C_p)
\\
\\ \text{resulting coin: } \langle c_s, C_p, \sigma_c, D_p \rangle
\end{array}
\end{equation*}
\caption{untaxed payment using withdraw loophole}
\label{fig:withdraw-loophole-exploit}
\end{figure}
\subsection{Requirements For A Possible Solution}
A viable solution has to fix the withdraw loophole, while still providing a solution for tipping. In addition, Taler's security properties must not be weakened.
The underlying problem that has to be solved is to check that the person withdrawing a coin is also the owner of the reserve used in the withdraw.
This has to be solved in a way that prevents the customer and malicious merchant to work together.
% Requirements For A Perfect Solution}
% minimal adjustments to Taler
% Commitment to sk of Reserve -> constructed by customer (key owner)
% commitment to sk of coin
% how do we ensure that the customer is key owner? -> combine with reserve sk
% how do we verify? problems with blinding
% how do we ensure that the coin in the commitment is the coin that is signed?
% exchange must not learn anything about coin to prevent linking of withdraw and transaction
\subsection{Discussed Solution}
For our proposed solution, a few adjustments to Taler have to be made:
\begin{itemize}
\item The withdraw confirmation must include a commitment to the public key.
This commitment must be constructed in a way that requires the customer to know the public key.
The exception to this are special tipping reserves (to preserve the tipping feature).
\item Cut-and-choose is added to the withdraw protocol.
This means that the customer has to generate the coin and withdraw confirmation $ k $ times.
The exchange will then choose one of the $ k $ sessions.
The customer has to reveal the coin public key, blinding secret and commitment for all sessions except the chosen one.
If the customer isn't able to deliver, the reserve is locked for future withdraws until the other sessions are delivered.
Cut-and-choose is introduced to verify whether the customer honestly created the commitment and used the same coin public key for the signature creation and the commitment.
If the reserve is a special tip reserve (which has to be registered), this check is omitted.
\item An additional protocol is created that transfers the remaining value of a coin back to the reserve if anyone is able to reveal the commitment from the withdrawal.
The adjustments described up to this point lead to the customer knowing all the necessary values for using this protocol.
Besides the customer, no one must be able to reproduce the commitment, except in case of a reserve key compromise.
\item Reserves are limited (usually only one, unless justified) and bound to a customer (KYC).
% this goes further than fixing the loophole. It prevents people from creating new reserves that are then to be transfered
% TODO check if there are disadvantages to this, especially regarding privacy
\item For a coin to be refreshable, it must have been seen by the exchange before, meaning that it had to be used for a payment.
The purpose of this is to prevent a malicious merchant to simply refresh a coin after withdraw to prevent the customer from reverting the withdraw.
\item For any coin used in a payment, the subtracted value must be higher that a certain threshold (set globally or per denomination).
For example, if the threshold is $ 10\% $, at least CHF 10 of a 100 CHF coin must be used for a payment.
The goal of this change is to prevent a malicious merchant from buying a very cheap article to be able to refresh the coin.
\end{itemize}
The commitment has to fulfill the following properties:
\begin{enumerate}
\item It has to be constructed using the reserve private key and must be verifiable using the corresponding public key.
\item It has to include the coin public key.
\item It has to be constructed in a way that ensures that the customer has knowledge of the coin public key.
\item Everyone with knowledge of the two keys must be able to recreate it.
\end{enumerate}
A possible commitment that partially satisfies the properties can be constructed by hashing a signature of the coin's public key:
\begin{equation*}
H( \text{Ed25519.Sign} (w_w, C_p) )
\end{equation*}
Note that the PureEdDSA variant of Ed25519 has to be used for this.
This variant doesn't hash the message before signing (see \cite{rfc8032} for further details).\\
It is still possible for a customer and a malicious merchant to construct the commitment without the customer gaining knowledge of the coin public key.
However, the customer has to share one half of the hash of the reserve private key (which is practically one half of the private key, refer to section \ref{sec:eddsa-signature-creation} for details about EdDSA signature creation).
% was passiert wenn im Verhör und gezwungen wird, Keys herauszurücken?
There is one drawback to this solution:
In case of a reserve key compromise, coins generated by withdraw operation (not refreshed ones) can be linked to withdraw operations, thus revealing relationships between reserves and payments.
This is because an adversary (exchange or auditor) in possession of a reserve private key and coin public keys can calculate $ \text{H(Ed25519.Sign}(w_s, C_p)) $ and check in the database if there is a corresponding withdraw operation, thus linking reserve and coin.
\subsubsection{Discussion}
This is not perfect solution.
It is designed to make untaxed payments using the withdraw loophole less attractive to use for merchants.
If accepted, it should only be used in deployments where the withdraw loophole has to be prohibited.\\
The proposed modifications achieve that a malicious merchant, who wants to perform payments using the withdraw loophole, has to accept one of these drawbacks:
\begin{itemize}
\item He has to accept that the customer is able to revert the payment.
\item He has to spend the coins fully.\\
If he is registered as a merchant at an exchange, he can perform payments to himself to launder the money.
Here, Talers \ac{AML} capabilities come into play.\\
The other possibility is to buy goods at other merchants.
These goods then have to be liquidated, which requires effort.
This wouldn't be a problem (for the malicous merchant) if cryptocurrency can be bought using Taler.
\item He has to spend the coins partially to be able to refresh them (thus preventing payment reversion by the customer).
The goods that were bought using the coin fraction then would have to be liquidated (see previous point).
\item He has to add the threshold value that is lost in order to refresh the coin into the price for payments.
\end{itemize}
The commitment added to the withdrawal weakens the privacy of coins.
Blinding guarantees everlasting privacy, which would be neutralized by the commitment.
The added cut-and-choose makes withdrawing more intensive, which leads to increased infrastructure requirements (and therefore costs).
The added threshold makes coin spending less flexible.
Wallets either have to contain more coins to guarantee that there is always a coin (or multiple) available to guarantee a payment without violating the threshold limitations.
The other variant is that wallets refrain from withdrawing coins with big(ger) denominations, which leads to bigger sums of coins used per payment.
This discussed solution is submitted to the Taler team as a part of the thesis documentation, upon which they can review the protocol changes and decide whether to pursue further.
Therefore, the solution will not be implemented during this thesis.

373
doc/cs/content/x_taler.tex Normal file
View File

@ -0,0 +1,373 @@
\chapter{Taler}
\section{Taler Architecture}
\subsection{Auditor}
The following text is cited from section 4.4 in \cite{dold:the-gnu-taler-system}
\begin{center}
\textit{
"The auditor consists of two processes that are regularly run and generate auditing reports.
Both processes access the exchange’s database, either directly (for exchange-internal auditing as part if its operational security) or over a replica (in the case of external auditors).
The taler-wire-auditor process checks that the incoming and outgoing transfers recorded in the exchange’s database match wire transfers of the underlying bank account.
To access the transaction history (typically recorded by the bank), the wire auditor uses a wire plugin, with the same interface and implementation as the exchange’s wire plugins.
The taler-auditor process generates a report with the following information:
}
\end{center}
\begin{itemize}
\item \textit{Do the operations stored in a reserve’s history match the reserve’s balance?}
\item \textit{Did the exchange record outgoing transactions to the right merchant for deposits after the deadline for the payment was reached?}
\item \textit{Do operations recorded on coins (deposit, refresh, refund) match the remaining value on the coin?}
\item \textit{Do operations respect the expiration of denominations?}
\item \textit{For a denomination, is the number of pairwise different coin public keys recorded in deposit/refresh operations smaller or equal to the number of blind signatures recorded in withdraw/refresh operations? If this invariant is violated, the corresponding denomination must be revoked.}
\item \textit{What is the income if the exchange from different fees?}
\end{itemize}
\begin{center}
\textit{
\dots
The auditor exposes a web server with the taler-auditor-httpd process.
Currently, it only shows a website that allows the customer to add the auditor to the list of trusted auditors in their wallet.
In future versions, the auditor will also have HTTP endpoints that allow merchants to submit samples of deposit confirmations, which will be checked against the deposit permissions in the exchange’s database to detect compromised signing keys or missing writes.
Furthermore, in deployments that require the merchant to register with the exchange beforehand, the auditor also offers a list of exchanges it audits, so that the merchant backend can automatically register with all exchanges it transitively trusts."
}
\end{center}
Some details were left out (see at the dots) and can be read in section 4.4 in \cite{dold:the-gnu-taler-system}
\subsubsection{Technical Details}
Documentation: \cite{taler-documentation:auditor-operator-manual} \\
Git Repositories:
\begin{itemize}
\item Main repository: \cite{taler-git:exchange} (Part of exchange repository, inside ./src/auditor and ./src/auditordb)
\item Auditor's public website: \cite{taler-git:auditor}
\end{itemize}
Language: C \\
Dependencies:
\begin{itemize}
\item GNUnet >= 0.14.0
\item GNU libmicrohttpd >= 0.9.71
\item Postgres >= 9.6, including libpq
\item libjansson >= 2.7
\item libargon2 >= 20171227
\item libsodium >= 1.0
\item libgcrypt >= 1.6
\item libqrencode >= 4.0.0
\item libcurl >= 7.26 (or libgnurl >= 7.26)
\item GNU libunistring >= 0.9.3
\item libsqlite3 >= 3.16.2
\end{itemize}
The auditor API is implemented as REST API and uses \ac{JSON} as message format.
The auditor does not implement HTTPS (TLS), instead it recommends using a HTTP reverse Proxy that offers TLS termination.
By delegating the responsibility for TLS termination, the auditor implementation becomes lighter.
There are a lot more technical details written in the documentation linked above and in the README files.
Since Taler is actively developed and technical details could change, we refer to this documentation.
\subsection{Exchange}
The following text is cited from section 4.3 in \cite{dold:the-gnu-taler-system}
\begin{center}
\textit{
"The exchange consists of three independent processes:
}
\end{center}
\begin{itemize}
\item \textit{The taler-exchange-httpd process handles HTTP requests from clients, mainly merchants and wallets.}
\item \textit{The taler-exchange-wirewatch process watches for wire transfers to the exchange’s bank account and updates reserves based on that.}
\item \textit{The taler-exchange-aggregator process aggregates outgoing transactions to merchants.}
\end{itemize}
\begin{center}
\textit{
All three processes exchange data via the same database.
Only taler-exchange-httpd needs access to the exchanges online signing keys and denomination keys.
The database is accessed via a Taler-specific database abstraction layer.
Different databases can be supported via plugins; at the time of writing this, only a PostgreSQL plugin has been implemented.
Wire plugins are used as an abstraction to access the account layer that Taler runs on.
Specifically, the wirewatch process uses the plugin to monitor incoming transfers, and the aggregator process uses the wire plugin to make wire transfers to merchants.
The following APIs are offered by the exchange:
}
\textbf{\textit{Announcing keys, bank accounts and other public information}}\\
\textit{
The exchange offers the list of denomination keys, signing keys, auditors, supported bank accounts, revoked keys and other general information needed to use the exchange’s services via the /keys and /wire APIs.
}
\textbf{\textit{Reserve status and withdrawal}}\\
\textit{
After having wired money to the exchange, the status of the reserve can be checked via the /reserve/status API. Since the wire transfer usually takes some time to arrive at the exchange, wallets should periodically poll this API, and initiate a withdrawal with /reserve/withdraw once the exchange received the funds.
}
\textbf{\textit{Deposits and tracking}}\\
\textit{
Merchants transmit deposit permissions they have received from customers to the exchange via the/deposit API. Since multiple deposits are aggregated into one wire transfer, the merchant additionally can use the exchange’s /track/transfer API that returns the list of deposits for an identifier included in the wire transfer to the merchant, as well as the /track/transaction API to look up which wire transfer included the payment for a given deposit.
}
\textbf{\textit{Refunds}}\\
\textit{
The refund API (/refund) can “undo” a deposit if the merchant gave their signature, and the aggregation deadline for the payment has not occurred yet.
}
\textbf{\textit{Emergency payback}}\\
\textit{
The emergency payback API (/payback) allows customers to be compensated for coins whose denomination key has been revoked.
Customers must send either a full withdrawal transcript that includes their private blinding factor, or a refresh transcript (of a refresh that had the revoked denominations as one of the targets) that includes blinding factors.
In the former case, the reserve is credited, in the latter case, the source coin of the refresh is refunded and can be refreshed again."
}
\end{center}
Additional information for how the exchange generates new denomination and signing keys can be found in the end of section 4.3 of \cite{dold:the-gnu-taler-system}.
\begin{figure}[h!]
\centering
\includegraphics[height=0.5\textwidth]{taler-exchange.png}
\caption{Architecture of the Taler Exchange reference implementation. Source: \cite{dold:the-gnu-taler-system}}
\label{fig:taler-arch-exchange}
\end{figure}
\subsubsection{Technical Details}
Documentation: \cite{taler-documentation:exchange-operator-manual} \\
Git Repository: Main repository: \cite{taler-git:exchange} \\
Language: C \\
Dependencies:
\begin{itemize}
\item GNUnet >= 0.14.0
\item GNU libmicrohttpd >= 0.9.71
\item Postgres >= 9.6, including libpq
\item libjansson >= 2.7
\item libargon2 >= 20171227
\item libsodium >= 1.0
\item libgcrypt >= 1.6
\item libqrencode >= 4.0.0
\item libcurl >= 7.26 (or libgnurl >= 7.26)
\item GNU libunistring >= 0.9.3
\item libsqlite3 >= 3.16.2
\end{itemize}
The exchange’s API is implemented as REST API and uses \ac{JSON} as message format.
There are a lot more technical details written in the documentation linked above and in the README files.
Since Taler is actively developed and technical details could change, we refer to this documentation.
\subsection{Merchant}
The following text is cited from section 4.5 in \cite{dold:the-gnu-taler-system}
\begin{center}
\textit{
"The Taler merchant backend is a component that abstracts away the details of processing Taler payments and provides a simple HTTP API.
The merchant backend handles cryptographic operations (signature verification, signing), secret management and communication with the exchange.
The backend API (see \url{https://docs.taler.net/api/}) is divided into two types of HTTP endpoints:
}
\end{center}
\begin{enumerate}
\item \textit{Functionality that is accessed internally by the merchant.
These API stypically require authentication and/or are only accessible from within the private network of the merchant.}
\item \textit{Functionality that is exposed publicly on the Internet and accessed by the customer’s wallet and browser.}
\end{enumerate}
\begin{center}
\textit{
A typical merchant has a storefront component that customers visit with their browser, as well as a back office component that allows the merchant to view information about payments that customers made and that integrates with other components such as order processing and shipping."
}
\end{center}
\subsubsection{Processing Payments}
\begin{center}
\textit{
"To process a payment, the storefront first instructs the backend to create an order.
The order contains information relevant to the purchase, and is in fact a subset of the information contained in the contract terms.
The backend automatically adds missing information to the order details provided by the storefront.
The full contract terms can only be signed once the customer provides the claim public key for the contract.\\
Each order is uniquely identified by an order ID, which can be chosen by the storefront or automatically generated by the backend.
The order ID can be used to query the status of the payment.
If the customer did not pay for an order ID yet, the response from the backend includes a payment redirect URL.
The storefront can redirect the customer to this payment redirect URL; visiting the URL will trigger the customer’s browser/wallet to prompt for a payment.\\
To simplify the implementation of the storefront, the merchant backend can serve a page to the customer’s browser that triggers the payment via the HTTP402 status code and the corresponding headers, and provides a fallback (in the form of a taler:pay link) for loosely integrated browsers.
When checking the status of a payment that is not settled yet, the response from the merchant backend will contains a payment redirect URL.
The storefront redirects the browser to this URL, which is served by the merchant backend and triggers the payment.
\dots "
}
\end{center}
\subsubsection{Back Office APIs}
\begin{center}
\textit{
"The back office API allows the merchant to query information about the history and status of payments, as well as correlate wire transfers to the merchant’s bank account with the respective GNU Taler payment.
This API is necessary to allow integration with other parts of the merchant’s e-commerce infrastructure."
}
\end{center}
% Nachfolgende Section nicht notwendig.
% \subsubsection{Example Merchant Frontends}
% This section is included to provide an overview of the reference implementation for the merchant.
% This helps to get a better understanding of how a merchant could potentially look like.
% Note that the actual code could differ from the cited part.
% The actual code can be found in \url{git.taler.net}
% \begin{center}
% \textit{
% We implemented the following applications using the merchant backend API.
% }
% \textit{\textbf{Blog Merchant}}\\
% \textit{
% The blog merchant’s landing page has a list of article titles with a teaser.
% When following the link to the article, the customer is asked to pay to view the article.
% }
% \textit{\textbf{Donations}}\\
% \textit{
% The donations frontend allows the customer to select a project to donate to.
% The fulfillment page shows a donation receipt.
% }
% \textit{\textbf{Codeless Payments}}\\
% \textit{
% The codeless payment frontend is a prototype for a user interface that allows merchants to sell products on their website without having to write code to integrate with the merchant backend.
% Instead, the merchant uses a web interface to manage products and their available stock.
% The codeless payment frontend then creates an HTML snippet with a payment button that the merchant can copy-and-paste integrate into their storefront.
% }
% \textit{\textbf{Survey}}\\
% \textit{
% The survey frontend showcases the tipping functionality of GNU Taler.
% The user fills out a survey and receives a tip for completing it.
% }
% \textit{\textbf{Back Office}}\\
% \textit{
% The example back-office application shows the history and status of payments processed by the merchant.
% }
% \end{center}
\begin{figure}[h!]
\centering
\includegraphics[height=0.5\textwidth]{taler-merchant.png}
\caption{Architecture Taler Merchant reference implementation. Source: \cite{dold:the-gnu-taler-system}}
\label{fig:taler-arch-merchant}
\end{figure}
\subsubsection{Technical Details}
Documentation: \cite{taler-documentation:merchant-backend-operator-manual} \\
API Documentation: \cite{taler-documentation:merchant-api} \\
Back-office Documentation: \cite{taler-documentation:back-office} \\
Point-of-Sales Documentation: \cite{taler-documentation:pos-manual} \\
Git Repositories:
\begin{itemize}
\item Backend: \cite{taler-git:merchant}
\item Backoffice: \cite{taler-git:backoffice}
\item Point-of-Sales App: \cite{taler-git:android} (part of android repo)
\end{itemize}
Language: C (Backend), Kotlin (\ac{PoS}), [Python, Javascript] (Backoffice)\\
Dependencies:
\begin{itemize}
\item GNUnet >= 0.14.0
\item GNU libmicrohttpd >= 0.9.71
\item Postgres >= 9.6, including libpq
\item libjansson >= 2.7
\item libargon2 >= 20171227
\item libsodium >= 1.0
\item libgcrypt >= 1.6
\item libqrencode >= 4.0.0
\item libcurl >= 7.26 (or libgnurl >= 7.26)
\item GNU libunistring >= 0.9.3
\item libsqlite3 >= 3.16.2
\item Flask (Backoffice)
\end{itemize}
Frontend Repositories:
\begin{itemize}
\item Payments with Django: \cite{taler-git:django-payments}
\item Wordpress woocommerce plugin: \cite{taler-git:woocommerce}
\item Saleor Frontend: \cite{taler-git:saleor}
\item Demo Frontends: \cite{taler-git:merchant-demos}
\end{itemize}
The merchant’s API is implemented as REST API and uses \ac{JSON} as message format.
The \ac{PoS} app is for the merchant to process customer's orders by adding or removing products, calculating the amount owed by the customer or letting the customer make a Taler payment via QR code or NFC.
The back office Web service allows a merchant to check status of their Taler transactions.
There are already a lot of demo pages and integrations for different e-commerce solutions.
There are a lot more technical details written in the documentation linked above and in the README files.
Since Taler is actively developed and technical details could change, we refer to this documentation.
\subsection{Wallet}
The following text is cited from section 4.6 in \cite{dold:the-gnu-taler-system}
\begin{center}
\textit{
"The wallet manages the customer’s reserves and coins, lets the customer view and pay for contracts from merchants. \dots
The reference implementation of the GNU Taler wallet is written in the Type-Script language against the WebExtension API, a cross-browser mechanism for browser extensions.
The reference wallet is a “tightly integrated” wallet, as it directly hooks into the browser to process responses with the HTTP status code“402 Payment Required”.\\
Many cryptographic operations needed to implement the wallet are not commonly available in a browser environment.
We cross-compile the GNU Taler utility library written in C as well as its dependencies (such as libgcrypt) to asm.js (and WebAssembly on supported platforms) using the LLVM-based emscripten toolchain.
Cryptographic operations run in an isolated process implemented as a WebWorker.
This design allows the relatively slow cryptographic operations to run concurrently in the background in multiple threads.
Since the crypto WebWorkers are started on-demand, the wallet only uses minimal resources when not actively used."
}
\end{center}
\subsubsection{Optimizations}
\begin{center}
\textit{
"To improve the perceived performance of cryptographic operations, the wallet optimistically creates signatures in the background while the user is looking at the “confirm payment” dialog.
If the user does not accept the contract, these signatures are thrown away instead of being sent to the merchant.
This effectively hides the latency of the most expensive cryptographic operations, as they are done while the user consciously needs to make a decision on whether to proceed with a payment."
}
\end{center}
\subsubsection{Wallet Detection}
\begin{center}
\textit{
" \dots
Browser fingerprinting is a concern with any additional APIs made available to websites, either by the browser itself or by browser extensions.
Since a website can simply try to trigger a payment to determine whether a tightly integrated Taler wallet is installed, one bit of additional fingerprinting information is already available through the usage of Taler.
The dynamic detection methods do not, however, expose any information that is not already available to websites by signaling the wallet through HTTP headers."
}
\end{center}
\subsubsection{Further Wallet Features}
More information about other Wallet Features like coin selection, wallet liquidation and wallet signaling can be found in sections 4.6.2, 4.6.5 and 4.6.6 of \cite{dold:the-gnu-taler-system}.
\begin{figure}[h!]
\centering
\includegraphics[height=0.5\textwidth]{taler-wallet.png}
\caption{Architecture of the Taler Wallet reference implementation. Source: \cite{dold:the-gnu-taler-system}}
\label{fig:taler-wallet-reference-impl}
\end{figure}
\subsubsection{Technical Details}
Documentation: \cite{taler-documentation:wallet-developer-manual} \\
Wallet-CLI documentation: \cite{taler-documentation:wallet-cli-manual} \\
Git Repository:
\begin{itemize}
\item Main repository: \cite{taler-git:wallet-core} \\
This Repository includes the wallet-core and the implementations for the web extension and CLI.
\item Android app: \cite{taler-git:android}
\item iOS app: \cite{taler-git:ios}
\end{itemize}
Language: Typescript, Javascript (wallet-core, web extension), Kotlin (Android app), Swift (iOS app)\\
Dependencies:
\begin{itemize}
\item prettier
\item rimraf
\item rollup
\item typescript
\item ava
\item esbuild
\item axios
\item tslib
\item cancellationtoken
\item minimatch
\item source-map-support
\item big-integer
\item fflate
\item esm
\item jed
\item nyc
\item po2json
\item typedoc
\item api-extractor
\end{itemize}
There are a lot more technical details written in the documentation linked above and in the README files.
Since Taler is actively developed and technical details could change, we refer to this documentation.

BIN
doc/cs/images/bfh_logo.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 5.4 KiB

BIN
doc/cs/images/diagram-simple.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 92 KiB

BIN
doc/cs/images/logo-2021.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 30 KiB

BIN
doc/cs/images/projectplan.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 323 KiB

BIN
doc/cs/images/taler-exchange.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 55 KiB

BIN
doc/cs/images/taler-merchant.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 40 KiB

BIN
doc/cs/images/taler-pki.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 78 KiB

BIN
doc/cs/images/taler-wallet.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 50 KiB

BIN
doc/cs/images/taler_bigger.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 253 KiB

BIN
doc/cs/images/taler_cut_and_choose.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 51 KiB

BIN
doc/cs/images/taler_refresh_link_threat.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 55 KiB

BIN
doc/cs/images/taler_refresh_transfer_key.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 27 KiB

93
doc/cs/thesis.tex Normal file
View File

@ -0,0 +1,93 @@
%============================ MAIN DOCUMENT ================================
% define document class
\documentclass[
a4paper % paper format
% ,10.5pt % fontsize
% ,BCOR=18mm % Binding correction
% ,twoside
% ,headings=openright
,bibliography=totoc % If enabled add bibliography to TOC
,class=scrreprt % If removed, makes book format (1 side left, 1 right)
,listof=totoc % If enabled add lists to TOC
% ,bilingual
,monolingual
% ,invert-title % Invert the BFH colors
]{bfhthesis} % KOMA-script report
\input{ads/header.tex}
\begin{document}
\frontmatter
\input{variable.sty}
%---------------- BFH tile page -----------------------------------------
\maketitle
% Abstract
\input{ads/abstract}
%------------ TABLEOFCONTENTS ----------------
\tableofcontents
%------------ START MAIN PART ----------------
\mainmatter
%------------ Introduction
\input{content/1_introduction.tex}
%------------ Project management
% \input{content/2_project_management.tex}
%------------ Preliminaries
\input{content/3_preliminaries.tex}
%------------ Execution
\input{content/4_execution.tex}
%------------ Discussion
\input{content/5_discussion.tex}
%------------ Conclusion
\input{content/6_conclusion.tex}
%------------ Eidesstattliche Erklärung
\includepdf[pages=1]{ads/Erklaerung}
%------------ History
% \input{ads/history}
%------------ Abbildungsverzeichnis
%\cleardoublepage
\listoffigures
%------------ Tabellenverzeichnis
%\cleardoublepage
\listoftables
% TODO
%------------ Quellcodeverzeichnis
% \cleardoublepage
\phantomsection \label{listoflist}
\addcontentsline{toc}{chapter}{List of listings}
\lstlistoflistings
%------------ Literaturverzeichnis
%\cleardoublepage
\printbibliography
%------------ Abkürzungsverzeichnis
%\cleardoublepage
\phantomsection \label{listofacs}
\addcontentsline{toc}{chapter}{Abbreviations}
\input{ads/abbreviation}
%------------ Glossar
\printglossary[style=altlist,title=Glossary]
%------------ Anhang
\input{content/appendix.tex}
\end{document}

15
doc/cs/variable.sty Normal file
View File

@ -0,0 +1,15 @@
\title{Adding Schnorr's Blind Signature in Taler}
\subtitle{An improved Taler Blind Signature System}
\author{{Gian Demarmels}, {Lucien Heuzeveldt}}
\institution{Bern University of Applied Science}
\department{Engineering and Computer Sciences}
\institute{Institute for Cybersecurity and Engineering ICE}
\version{1.0}
\titlegraphic{\includegraphics[width=\width]{logo-2021.png}}
\advisor{Prof. Dr. Emmanuel Benoist}
\expert{Elektronikingenieur HTL Daniel Voisard}
\degreeprogram{Bachelor of Science in Computer Science}
\setupSignature{
G. Demarmels={\includegraphics[width=\linewidth]{logo-2021.png}},
L. Heuzeveldt={\includegraphics[width=\linewidth]{bfh_logo.png}\vskip-\baselineskip}
}

32
src/auditor/generate-auditor-basedb.conf
View File

@ -106,6 +106,7 @@ fee_withdraw = TESTKUDOS:0.01
fee_deposit = TESTKUDOS:0.01
fee_refresh = TESTKUDOS:0.01
fee_refund = TESTKUDOS:0.01
CIPHER = RSA
rsa_keysize = 1024
[coin_kudos_ct_10]
@ -117,6 +118,7 @@ fee_withdraw = TESTKUDOS:0.01
fee_deposit = TESTKUDOS:0.01
fee_refresh = TESTKUDOS:0.03
fee_refund = TESTKUDOS:0.01
CIPHER = RSA
rsa_keysize = 1024
[coin_kudos_1]
@ -128,6 +130,7 @@ fee_withdraw = TESTKUDOS:0.02
fee_deposit = TESTKUDOS:0.02
fee_refresh = TESTKUDOS:0.03
fee_refund = TESTKUDOS:0.01
CIPHER = RSA
rsa_keysize = 1024
[coin_kudos_2]
@ -139,6 +142,7 @@ fee_withdraw = TESTKUDOS:0.03
fee_deposit = TESTKUDOS:0.03
fee_refresh = TESTKUDOS:0.04
fee_refund = TESTKUDOS:0.02
CIPHER = RSA
rsa_keysize = 1024
[coin_kudos_4]
@ -150,6 +154,7 @@ fee_withdraw = TESTKUDOS:0.03
fee_deposit = TESTKUDOS:0.03
fee_refresh = TESTKUDOS:0.04
fee_refund = TESTKUDOS:0.02
CIPHER = RSA
rsa_keysize = 1024
[coin_kudos_5]
@ -161,6 +166,7 @@ fee_withdraw = TESTKUDOS:0.01
fee_deposit = TESTKUDOS:0.01
fee_refresh = TESTKUDOS:0.03
fee_refund = TESTKUDOS:0.01
CIPHER = RSA
rsa_keysize = 1024
[coin_kudos_8]
@ -172,6 +178,7 @@ fee_withdraw = TESTKUDOS:0.05
fee_deposit = TESTKUDOS:0.02
fee_refresh = TESTKUDOS:0.03
fee_refund = TESTKUDOS:0.04
CIPHER = RSA
rsa_keysize = 1024
[coin_kudos_10]
@ -183,6 +190,31 @@ fee_withdraw = TESTKUDOS:0.01
fee_deposit = TESTKUDOS:0.01
fee_refresh = TESTKUDOS:0.03
fee_refund = TESTKUDOS:0.01
CIPHER = RSA
rsa_keysize = 1024
[coin_kudos_ct_1]
value = TESTKUDOS:0.01
duration_withdraw = 7 days
duration_spend = 2 years
duration_legal = 3 years
fee_withdraw = TESTKUDOS:0.01
fee_deposit = TESTKUDOS:0.01
fee_refresh = TESTKUDOS:0.01
fee_refund = TESTKUDOS:0.01
CIPHER = RSA
rsa_keysize = 1024
[coin_kudos_ct_10]
value = TESTKUDOS:0.10
duration_withdraw = 7 days
duration_spend = 2 years
duration_legal = 3 years
fee_withdraw = TESTKUDOS:0.01
fee_deposit = TESTKUDOS:0.01
fee_refresh = TESTKUDOS:0.03
fee_refund = TESTKUDOS:0.01
CIPHER = RSA
rsa_keysize = 1024
[benchmark]

98
src/auditor/report-lib.c
View File

@ -89,13 +89,6 @@ static struct GNUNET_SIGNAL_Context *sig_int;
static struct GNUNET_SIGNAL_Context *sig_term;
/**
* Test if the audit should be aborted because the user
* pressed CTRL-C.
*
* @return false to continue the audit, true to terminate
* cleanly as soon as possible
*/
bool
TALER_ARL_do_abort (void)
{
@ -103,12 +96,6 @@ TALER_ARL_do_abort (void)
}
/**
* Add @a object to the report @a array. Fail hard if this fails.
*
* @param array report array to append @a object to
* @param object object to append, should be check that it is not NULL
*/
void
TALER_ARL_report (json_t *array,
json_t *object)
@ -183,14 +170,6 @@ add_denomination (
}
/**
* Obtain information about a @a denom_pub.
*
* @param dh hash of the denomination public key to look up
* @param[out] issue set to detailed information about @a denom_pub, NULL if not found, must
* NOT be freed by caller
* @return transaction status code
*/
enum GNUNET_DB_QueryStatus
TALER_ARL_get_denomination_info_by_hash (
const struct TALER_DenominationHash *dh,
@ -262,15 +241,6 @@ TALER_ARL_get_denomination_info_by_hash (
}
/**
* Obtain information about a @a denom_pub.
*
* @param denom_pub key to look up
* @param[out] issue set to detailed information about @a denom_pub, NULL if not found, must
* NOT be freed by caller
* @param[out] dh set to the hash of @a denom_pub, may be NULL
* @return transaction status code
*/
enum GNUNET_DB_QueryStatus
TALER_ARL_get_denomination_info (
const struct TALER_DenominationPublicKey *denom_pub,
@ -298,7 +268,7 @@ TALER_ARL_get_denomination_info (
* #GNUNET_NO if we had an error on commit (retry may help)
* #GNUNET_SYSERR on hard errors
*/
static int
static enum GNUNET_GenericReturnValue
transact (TALER_ARL_Analysis analysis,
void *analysis_cls)
{
@ -369,14 +339,7 @@ transact (TALER_ARL_Analysis analysis,
}
/**
* Initialize DB sessions and run the analysis.
*
* @param ana analysis to run
* @param ana_cls closure for @a ana
* @return #GNUNET_OK on success
*/
int
enum GNUNET_GenericReturnValue
TALER_ARL_setup_sessions_and_run (TALER_ARL_Analysis ana,
void *ana_cls)
{
@ -424,19 +387,6 @@ test_master_present (void *cls,
}
/**
* Perform addition of amounts. If the addition fails, logs
* a detailed error and calls exit() to terminate the process (!).
*
* Do not call this function directly, use #TALER_ARL_amount_add().
*
* @param[out] sum where to store @a a1 + @a a2, set to "invalid" on overflow
* @param a1 first amount to add
* @param a2 second amount to add
* @param filename where is the addition called
* @param functionname name of the function where the addition is called
* @param line line number of the addition
*/
void
TALER_ARL_amount_add_ (struct TALER_Amount *sum,
const struct TALER_Amount *a1,
@ -485,19 +435,6 @@ TALER_ARL_amount_add_ (struct TALER_Amount *sum,
}
/**
* Perform subtraction of amounts. If the subtraction fails, logs
* a detailed error and calls exit() to terminate the process (!).
*
* Do not call this function directly, use #TALER_ARL_amount_subtract().
*
* @param[out] diff where to store (@a a1 - @a a2)
* @param a1 amount to subtract from
* @param a2 amount to subtract
* @param filename where is the addition called
* @param functionname name of the function where the addition is called
* @param line line number of the addition
*/
void
TALER_ARL_amount_subtract_ (struct TALER_Amount *diff,
const struct TALER_Amount *a1,
@ -546,24 +483,6 @@ TALER_ARL_amount_subtract_ (struct TALER_Amount *diff,
}
/**
* Perform subtraction of amounts. Negative results should be signalled by the
* return value (leaving @a diff set to 'invalid'). If the subtraction fails
* for other reasons (currency mismatch, normalization failure), logs a
* detailed error and calls exit() to terminate the process (!).
*
* Do not call this function directly, use #TALER_ARL_amount_subtract_neg().
*
* @param[out] diff where to store (@a a1 - @a a2)
* @param a1 amount to subtract from
* @param a2 amount to subtract
* @param filename where is the addition called
* @param functionname name of the function where the addition is called
* @param line line number of the addition
* @return #TALER_ARL_SR_INVALID_NEGATIVE if the result was negative (and @a diff is now invalid),
* #TALER_ARL_SR_ZERO if the result was zero,
* #TALER_ARL_SR_POSITIVE if the result is positive
*/
enum TALER_ARL_SubtractionResult
TALER_ARL_amount_subtract_neg_ (struct TALER_Amount *diff,
const struct TALER_Amount *a1,
@ -622,13 +541,7 @@ handle_sigint (void)
}
/**
* Setup global variables based on configuration.
*
* @param c configuration to use
* @return #GNUNET_OK on success
*/
int
enum GNUNET_GenericReturnValue
TALER_ARL_init (const struct GNUNET_CONFIGURATION_Handle *c)
{
TALER_ARL_cfg = c;
@ -822,11 +735,6 @@ TALER_ARL_init (const struct GNUNET_CONFIGURATION_Handle *c)
}
/**
* Generate the report and close connectios to the database.
*
* @param report the report to output, may be NULL for no report
*/
void
TALER_ARL_done (json_t *report)
{

4
src/auditor/report-lib.h
View File

@ -276,7 +276,7 @@ TALER_ARL_amount_subtract_neg_ (struct TALER_Amount *diff,
* @param ana_cls closure for @a ana
* @return #GNUNET_OK on success
*/
int
enum GNUNET_GenericReturnValue
TALER_ARL_setup_sessions_and_run (TALER_ARL_Analysis ana,
void *ana_cls);
@ -298,7 +298,7 @@ TALER_ARL_do_abort (void);
* @param c configuration to use
* @return #GNUNET_OK on success
*/
int
enum GNUNET_GenericReturnValue
TALER_ARL_init (const struct GNUNET_CONFIGURATION_Handle *c);

20
src/auditor/taler-auditor-httpd_deposit-confirmation.c
View File

@ -221,20 +221,6 @@ verify_and_execute_deposit_confirmation (
}
/**
* Handle a "/deposit-confirmation" request. Parses the JSON, and, if
* successful, passes the JSON data to #verify_and_execute_deposit_confirmation()
* to further check the details of the operation specified. If
* everything checks out, this will ultimately lead to the "/deposit-confirmation"
* being stored in the database.
*
* @param rh context of the handler
* @param connection the MHD connection to handle
* @param[in,out] connection_cls the connection's closure (can be updated)
* @param upload_data upload data
* @param[in,out] upload_data_size number of bytes (left) in @a upload_data
* @return MHD result code
*/
MHD_RESULT
TAH_DEPOSIT_CONFIRMATION_handler (struct TAH_RequestHandler *rh,
struct MHD_Connection *connection,
@ -323,9 +309,6 @@ TAH_DEPOSIT_CONFIRMATION_handler (struct TAH_RequestHandler *rh,
}
/**
* Initialize subsystem.
*/
void
TEAH_DEPOSIT_CONFIRMATION_init (void)
{
@ -335,9 +318,6 @@ TEAH_DEPOSIT_CONFIRMATION_init (void)
}
/**
* Shut down subsystem.
*/
void
TEAH_DEPOSIT_CONFIRMATION_done (void)
{

3
src/auditor/taler-helper-auditor-coins.c
View File

@ -1086,9 +1086,6 @@ struct RevealContext
* @param cls closure with a `struct RevealContext *` in it
* @param num_freshcoins size of the @a rrcs array
* @param rrcs array of @a num_freshcoins information about coins to be created
* @param num_tprivs number of entries in @a tprivs, should be #TALER_CNC_KAPPA - 1
* @param tprivs array of @e num_tprivs transfer private keys
* @param tp transfer public key information
*/
static void
reveal_data_cb (void *cls,

22
src/auditor/taler-helper-auditor-reserves.c
View File

@ -508,12 +508,7 @@ handle_reserve_out (void *cls,
struct GNUNET_TIME_Timestamp valid_start;
struct GNUNET_TIME_Timestamp expire_withdraw;
enum GNUNET_DB_QueryStatus qs;
struct TALER_WithdrawRequestPS wsrd = {
.purpose.purpose = htonl (TALER_SIGNATURE_WALLET_RESERVE_WITHDRAW),
.purpose.size = htonl (sizeof (wsrd)),
.reserve_pub = *reserve_pub,
.h_coin_envelope = *h_blind_ev
};
struct TALER_DenominationHash h_denom_pub;
/* should be monotonically increasing */
GNUNET_assert (rowid >= ppr.last_reserve_out_serial_id);
@ -523,7 +518,7 @@ handle_reserve_out (void *cls,
initializes wsrd.h_denomination_pub! */
qs = TALER_ARL_get_denomination_info (denom_pub,
&issue,
&wsrd.h_denomination_pub);
&h_denom_pub);
if (0 > qs)
{
GNUNET_break (GNUNET_DB_STATUS_SOFT_ERROR == qs);
@ -569,17 +564,16 @@ handle_reserve_out (void *cls,
GNUNET_JSON_pack_data_auto ("reserve_pub",
reserve_pub),
GNUNET_JSON_pack_data_auto ("denompub_h",
&wsrd.h_denomination_pub)));
&h_denom_pub)));
}
/* check reserve_sig (first: setup remaining members of wsrd) */
TALER_amount_hton (&wsrd.amount_with_fee,
amount_with_fee);
if (GNUNET_OK !=
GNUNET_CRYPTO_eddsa_verify (TALER_SIGNATURE_WALLET_RESERVE_WITHDRAW,
&wsrd,
&reserve_sig->eddsa_signature,
&reserve_pub->eddsa_pub))
TALER_wallet_withdraw_verify (&h_denom_pub,
amount_with_fee,
h_blind_ev,
reserve_pub,
reserve_sig))
{
TALER_ARL_report (report_bad_sig_losses,
GNUNET_JSON_PACK (

11
src/auditordb/auditordb_plugin.c
View File

@ -24,12 +24,6 @@
#include <ltdl.h>
/**
* Initialize the plugin.
*
* @param cfg configuration to use
* @return #GNUNET_OK on success
*/
struct TALER_AUDITORDB_Plugin *
TALER_AUDITORDB_plugin_load (const struct GNUNET_CONFIGURATION_Handle *cfg)
{
@ -62,11 +56,6 @@ TALER_AUDITORDB_plugin_load (const struct GNUNET_CONFIGURATION_Handle *cfg)
}
/**
* Shutdown the plugin.
*
* @param plugin the plugin to unload
*/
void
TALER_AUDITORDB_plugin_unload (struct TALER_AUDITORDB_Plugin *plugin)
{

2
src/auditordb/plugin_auditordb_postgres.c
View File

@ -144,7 +144,7 @@ postgres_create_tables (void *cls)
* @param[in,out] pg the plugin-specific state
* @return #GNUNET_OK on success
*/
static int
static enum GNUNET_GenericReturnValue
setup_connection (struct PostgresClosure *pg)
{
struct GNUNET_PQ_PreparedStatement ps[] = {

39
src/bank-lib/bank_api_transfer.c
View File

@ -65,18 +65,7 @@ struct WirePackP
GNUNET_NETWORK_STRUCT_END
/**
* Prepare for execution of a wire transfer from the exchange to some
* merchant.
*
* @param destination_account_payto_uri payto:// URL identifying where to send the money
* @param amount amount to transfer, already rounded
* @param exchange_base_url base URL of this exchange (included in subject
* to facilitate use of tracking API by merchant backend)
* @param wtid wire transfer identifier to use
* @param[out] buf set to transfer data to persist, NULL on error
* @param[out] buf_size set to number of bytes in @a buf, 0 on error
*/
void
TALER_BANK_prepare_transfer (
const char *destination_account_payto_uri,
@ -247,17 +236,6 @@ handle_transfer_finished (void *cls,
}
/**
* Execute a wire transfer.
*
* @param ctx curl context for our event loop
* @param auth authentication data to authenticate with the bank
* @param buf buffer with the prepared execution details
* @param buf_size number of bytes in @a buf
* @param cc function to call upon success
* @param cc_cls closure for @a cc
* @return NULL on error
*/
struct TALER_BANK_TransferHandle *
TALER_BANK_transfer (
struct GNUNET_CURL_Context *ctx,
@ -366,21 +344,6 @@ TALER_BANK_transfer (
}
/**
* Abort execution of a wire transfer. For example, because we are shutting
* down. Note that if an execution is aborted, it may or may not still
* succeed.
*
* The caller MUST run #TALER_BANK_transfer() again for the same request as
* soon as possible, to ensure that the request either ultimately succeeds or
* ultimately fails. Until this has been done, the transaction is in limbo
* (i.e. may or may not have been committed).
*
* This function cannot be used on a request handle if a response is already
* served for it.
*
* @param th the wire transfer request handle
*/
void
TALER_BANK_transfer_cancel (struct TALER_BANK_TransferHandle *th)
{

128
src/benchmark/bank-benchmark-cs.conf Normal file
View File

@ -0,0 +1,128 @@
# This file is in the public domain.
#
[paths]
# Persistent data storage for the testcase
# This value is a default for `taler_config_home'
taler_test_home = exchange_benchmark_home/
[taler]
# Currency supported by the exchange (can only be one)
currency = EUR
CURRENCY_ROUND_UNIT = EUR:0.01
[exchange]
# how long is one signkey valid?
signkey_duration = 4 weeks
signkey_legal_duration = 2 years
# how long do we provide to clients denomination and signing keys
# ahead of time?
# Keep it short so the test runs fast.
lookahead_sign = 12h
# HTTP port the exchange listens to
port = 8081
# Master public key used to sign the exchange's various keys
master_public_key = 98NJW3CQHZQGQXTY3K85K531XKPAPAVV4Q5V8PYYRR00NJGZWNVG
# How to access our database
DB = postgres
# Base URL of the exchange. Must be set to a URL where the
# exchange (or the twister) is actually listening.
base_url = "http://localhost:8081/"
WIREWATCH_IDLE_SLEEP_INTERVAL = 1500 ms
[exchange-offline]
MASTER_PRIV_FILE = ${TALER_DATA_HOME}/exchange/offline-keys/master.priv
[auditor]
BASE_URL = "http://localhost:8083/"
[exchangedb-postgres]
config = "postgres:///talercheck"
[benchmark-remote-exchange]
host = localhost
# Adjust $HOME to match remote target!
dir = $HOME/repos/taler/exchange/src/benchmark
[bank]
HTTP_PORT = 8082
SERVE = http
MAX_DEBT = EUR:100000000000.0
MAX_DEBT_BANK = EUR:1000000000000000.0
[benchmark]
USER_PAYTO_URI = payto://x-taler-bank/localhost:8082/42
[exchange-account-2]
# What is the payto://-URL of the exchange (to generate wire response)
PAYTO_URI = "payto://x-taler-bank/localhost:8082/Exchange"
enable_debit = YES
enable_credit = YES
[exchange-accountcredentials-2]
# What is the bank account (with the "Taler Bank" demo system)? Must end with "/".
WIRE_GATEWAY_URL = http://localhost:8082/Exchange/
# Authentication information for basic authentication
WIRE_GATEWAY_AUTH_METHOD = "basic"
username = Exchange
password = x
# Sections starting with "coin_" specify which denominations
# the exchange should support (and their respective fee structure)
[coin_eur_ct_1]
value = EUR:0.01
duration_withdraw = 7 days
duration_spend = 2 years
duration_legal = 3 years
fee_withdraw = EUR:0.00
fee_deposit = EUR:0.00
fee_refresh = EUR:0.01
fee_refund = EUR:0.01
CIPHER = CS
[coin_eur_ct_10]
value = EUR:0.10
duration_withdraw = 7 days
duration_spend = 2 years
duration_legal = 3 years
fee_withdraw = EUR:0.01
fee_deposit = EUR:0.01
fee_refresh = EUR:0.03
fee_refund = EUR:0.01
CIPHER = CS
[coin_eur_1]
value = EUR:1
duration_withdraw = 7 days
duration_spend = 2 years
duration_legal = 3 years
fee_withdraw = EUR:0.01
fee_deposit = EUR:0.01
fee_refresh = EUR:0.03
fee_refund = EUR:0.01
CIPHER = CS
[coin_eur_5]
value = EUR:5
duration_withdraw = 7 days
duration_spend = 2 years
duration_legal = 3 years
fee_withdraw = EUR:0.01
fee_deposit = EUR:0.01
fee_refresh = EUR:0.03
fee_refund = EUR:0.01
CIPHER = CS
[coin_eur_10]
value = EUR:10
duration_withdraw = 7 days
duration_spend = 2 years
duration_legal = 3 years
fee_withdraw = EUR:0.01
fee_deposit = EUR:0.01
fee_refresh = EUR:0.03
fee_refund = EUR:0.01
CIPHER = CS

5
src/benchmark/bank-benchmark.conf → src/benchmark/bank-benchmark-rsa.conf
View File

@ -81,6 +81,7 @@ fee_withdraw = EUR:0.00
fee_deposit = EUR:0.00
fee_refresh = EUR:0.01
fee_refund = EUR:0.01
CIPHER = RSA
rsa_keysize = 2048
[coin_eur_ct_10]
@ -92,6 +93,7 @@ fee_withdraw = EUR:0.01
fee_deposit = EUR:0.01
fee_refresh = EUR:0.03
fee_refund = EUR:0.01
CIPHER = RSA
rsa_keysize = 2048
[coin_eur_1]
@ -103,6 +105,7 @@ fee_withdraw = EUR:0.01
fee_deposit = EUR:0.01
fee_refresh = EUR:0.03
fee_refund = EUR:0.01
CIPHER = RSA
rsa_keysize = 2048
[coin_eur_5]
@ -114,6 +117,7 @@ fee_withdraw = EUR:0.01
fee_deposit = EUR:0.01
fee_refresh = EUR:0.03
fee_refund = EUR:0.01
CIPHER = RSA
rsa_keysize = 2048
[coin_eur_10]
@ -125,4 +129,5 @@ fee_withdraw = EUR:0.01
fee_deposit = EUR:0.01
fee_refresh = EUR:0.03
fee_refund = EUR:0.01
CIPHER = RSA
rsa_keysize = 2048

126
src/benchmark/benchmark-cs.conf Normal file
View File

@ -0,0 +1,126 @@
# This file is in the public domain.
#
[paths]
# Persistent data storage for the testcase
# This value is a default for `taler_config_home'
TALER_TEST_HOME = exchange_benchmark_home/
[taler]
# Currency supported by the exchange (can only be one)
CURRENCY = EUR
CURRENCY_ROUND_UNIT = EUR:0.01
[exchange]
SIGNKEY_LEGAL_DURATION = 2 years
# HTTP port the exchange listens to
PORT = 8081
# Master public key used to sign the exchange's various keys
MASTER_PUBLIC_KEY = 98NJW3CQHZQGQXTY3K85K531XKPAPAVV4Q5V8PYYRR00NJGZWNVG
# How to access our database
DB = postgres
# Base URL of the exchange. Must be set to a URL where the
# exchange (or the twister) is actually listening.
BASE_URL = "http://localhost:8081/"
AGGREGATOR_SHARD_SIZE = 67108864
#AGGREGATOR_SHARD_SIZE = 2147483648
WIREWATCH_IDLE_SLEEP_INTERVAL = 5 ms
[exchange-offline]
MASTER_PRIV_FILE = ${TALER_DATA_HOME}/exchange/offline-keys/master.priv
[auditor]
BASE_URL = "http://localhost:8083/"
[exchangedb-postgres]
CONFIG = "postgres:///talercheck"
[benchmark-remote-exchange]
HOST = localhost
# Adjust $HOME to match remote target!
DIR = $HOME/repos/taler/exchange/src/benchmark
[bank]
HTTP_PORT = 8082
SERVE = http
MAX_DEBT = EUR:100000000000.0
MAX_DEBT_BANK = EUR:1000000000000000.0
[benchmark]
USER_PAYTO_URI = payto://x-taler-bank/localhost:8082/42
[exchange-account-test]
# What is the bank account (with the "Taler Bank" demo system)? Must end with "/".
PAYTO_URI = "payto://x-taler-bank/localhost/Exchange"
# Authentication information for basic authentication
ENABLE_DEBIT = YES
ENABLE_CREDIT = YES
[exchange-accountcredentials-test]
WIRE_GATEWAY_URL = http://localhost:8082/Exchange/
WIRE_GATEWAY_AUTH_METHOD = "basic"
USERNAME = Exchange
PASSWORD = x
# Sections starting with "coin_" specify which denominations
# the exchange should support (and their respective fee structure)
[coin_eur_ct_1]
value = EUR:0.01
duration_withdraw = 7 days
duration_spend = 2 years
duration_legal = 3 years
fee_withdraw = EUR:0.00
fee_deposit = EUR:0.00
fee_refresh = EUR:0.01
fee_refund = EUR:0.01
CIPHER = CS
[coin_eur_ct_10]
value = EUR:0.10
duration_withdraw = 7 days
duration_spend = 2 years
duration_legal = 3 years
fee_withdraw = EUR:0.01
fee_deposit = EUR:0.01
fee_refresh = EUR:0.03
fee_refund = EUR:0.01
CIPHER = CS
[coin_eur_1]
value = EUR:1
duration_withdraw = 7 days
duration_spend = 2 years
duration_legal = 3 years
fee_withdraw = EUR:0.01
fee_deposit = EUR:0.01
fee_refresh = EUR:0.03
fee_refund = EUR:0.01
CIPHER = CS
[coin_eur_5]
value = EUR:5
duration_withdraw = 7 days
duration_spend = 2 years
duration_legal = 3 years
fee_withdraw = EUR:0.01
fee_deposit = EUR:0.01
fee_refresh = EUR:0.03
fee_refund = EUR:0.01
CIPHER = CS
[coin_eur_10]
value = EUR:10
duration_withdraw = 7 days
duration_spend = 2 years
duration_legal = 3 years
fee_withdraw = EUR:0.01
fee_deposit = EUR:0.01
fee_refresh = EUR:0.03
fee_refund = EUR:0.01
CIPHER = CS

5
src/benchmark/benchmark.conf → src/benchmark/benchmark-rsa.conf
View File

@ -79,6 +79,7 @@ fee_withdraw = EUR:0.00
fee_deposit = EUR:0.00
fee_refresh = EUR:0.01
fee_refund = EUR:0.01
CIPHER = RSA
rsa_keysize = 2048
[coin_eur_ct_10]
@ -90,6 +91,7 @@ fee_withdraw = EUR:0.01
fee_deposit = EUR:0.01
fee_refresh = EUR:0.03
fee_refund = EUR:0.01
CIPHER = RSA
rsa_keysize = 2048
[coin_eur_1]
@ -101,6 +103,7 @@ fee_withdraw = EUR:0.01
fee_deposit = EUR:0.01
fee_refresh = EUR:0.03
fee_refund = EUR:0.01
CIPHER = RSA
rsa_keysize = 2048
[coin_eur_5]
@ -112,6 +115,7 @@ fee_withdraw = EUR:0.01
fee_deposit = EUR:0.01
fee_refresh = EUR:0.03
fee_refund = EUR:0.01
CIPHER = RSA
rsa_keysize = 2048
[coin_eur_10]
@ -123,4 +127,5 @@ fee_withdraw = EUR:0.01
fee_deposit = EUR:0.01
fee_refresh = EUR:0.03
fee_refund = EUR:0.01
CIPHER = RSA
rsa_keysize = 2048

23
src/benchmark/taler-aggregator-benchmark.c
View File

@ -228,7 +228,7 @@ struct Merchant
/**
* Salt used when computing @e h_wire.
*/
struct TALER_WireSalt wire_salt;
struct TALER_WireSaltP wire_salt;
/**
* Account information for the merchant.
@ -490,8 +490,10 @@ run (void *cls,
struct TALER_CoinPubHash c_hash;
struct TALER_PlanchetDetail pd;
struct TALER_BlindedDenominationSignature bds;
union TALER_DenominationBlindingKeyP bks;
struct TALER_PlanchetMasterSecretP ps;
struct TALER_ExchangeWithdrawValues alg_values;
struct TALER_CoinSpendPublicKeyP coin_pub;
union TALER_DenominationBlindingKeyP bks;
RANDOMIZE (&coin_pub);
GNUNET_assert (GNUNET_OK ==
@ -499,6 +501,7 @@ run (void *cls,
&denom_pub,
TALER_DENOMINATION_RSA,
1024));
alg_values.cipher = TALER_DENOMINATION_RSA;
TALER_denom_pub_hash (&denom_pub,
&h_denom_pub);
make_amountN (2, 0, &issue.properties.value);
@ -518,25 +521,29 @@ run (void *cls,
return;
}
TALER_blinding_secret_create (&bks);
TALER_planchet_blinding_secret_create (&ps,
&alg_values,
&bks);
GNUNET_assert (GNUNET_OK ==
TALER_denom_blind (&denom_pub,
&bks,
NULL, /* FIXME-oec */
&coin_pub,
&alg_values,
&c_hash,
&pd.coin_ev,
&pd.coin_ev_size));
&pd.blinded_planchet));
GNUNET_assert (GNUNET_OK ==
TALER_denom_sign_blinded (&bds,
&pk,
pd.coin_ev,
pd.coin_ev_size));
GNUNET_free (pd.coin_ev);
&pd.blinded_planchet));
TALER_blinded_planchet_free (&pd.blinded_planchet);
GNUNET_assert (GNUNET_OK ==
TALER_denom_sig_unblind (&denom_sig,
&bds,
&bks,
&c_hash,
&alg_values,
&denom_pub));
TALER_blinded_denom_sig_free (&bds);
TALER_denom_pub_free (&denom_pub);

6
src/exchange-tools/taler-crypto-worker.c
View File

@ -14,7 +14,7 @@
TALER; see the file COPYING. If not, see <http://www.gnu.org/licenses/>
*/
/**
* @file util/taler-crypto-worker.c
* @file exchange-tools/taler-crypto-worker.c
* @brief Standalone process to perform various cryptographic operations.
* @author Florian Dold
*/
@ -178,6 +178,7 @@ run (void *cls,
"sent response\n");
continue;
}
#if FIXME_FLORIAN
if (0 == strcmp ("setup_refresh_planchet", op))
{
struct TALER_TransferSecretP transfer_secret;
@ -204,7 +205,7 @@ run (void *cls,
global_ret = 1;
return;
}
TALER_planchet_setup_refresh (&transfer_secret,
TALER_transfer_secret_to_planchet_secret (&transfer_secret,
coin_index,
&ps);
GNUNET_CRYPTO_eddsa_key_get_public (&ps.coin_priv.eddsa_priv,
@ -222,6 +223,7 @@ run (void *cls,
"sent response\n");
continue;
}
#endif
GNUNET_log (GNUNET_ERROR_TYPE_ERROR,
"unsupported operation '%s'\n",
op);

154
src/exchange-tools/taler-exchange-offline.c
View File

@ -2530,16 +2530,16 @@ do_download (char *const *args)
* Check that the security module keys are the same as before. If we had no
* keys in store before, remember them (Trust On First Use).
*
* @param secm security module keys, must be an array of length 2
* @param secmset security module keys
* @return #GNUNET_OK if keys match with what we have in store
* #GNUNET_NO if we had nothing in store but now do
* #GNUNET_SYSERR if keys changed from what we remember or other error
*/
static int
tofu_check (const struct TALER_SecurityModulePublicKeyP secm[2])
static enum GNUNET_GenericReturnValue
tofu_check (const struct TALER_SecurityModulePublicKeySetP *secmset)
{
char *fn;
struct TALER_SecurityModulePublicKeyP old[2];
struct TALER_SecurityModulePublicKeySetP oldset;
ssize_t ret;
if (GNUNET_OK !=
@ -2557,11 +2557,11 @@ tofu_check (const struct TALER_SecurityModulePublicKeyP secm[2])
GNUNET_DISK_file_test (fn))
{
ret = GNUNET_DISK_fn_read (fn,
&old,
sizeof (old));
&oldset,
sizeof (oldset));
if (GNUNET_SYSERR != ret)
{
if (ret != sizeof (old))
if (ret != sizeof (oldset))
{
GNUNET_log (GNUNET_ERROR_TYPE_ERROR,
"File `%s' corrupt\n",
@ -2570,9 +2570,9 @@ tofu_check (const struct TALER_SecurityModulePublicKeyP secm[2])
return GNUNET_SYSERR;
}
/* TOFU check */
if (0 != memcmp (old,
secm,
sizeof (old)))
if (0 != memcmp (&oldset,
secmset,
sizeof (*secmset)))
{
GNUNET_log (GNUNET_ERROR_TYPE_ERROR,
"Fatal: security module keys changed (file `%s')!\n",
@ -2608,15 +2608,17 @@ tofu_check (const struct TALER_SecurityModulePublicKeyP secm[2])
"SECM_ESIGN_PUBKEY",
"key malformed");
GNUNET_free (key);
GNUNET_free (fn);
return GNUNET_SYSERR;
}
GNUNET_free (key);
if (0 !=
GNUNET_memcmp (&k,
&secm[1]))
&secmset->eddsa))
{
GNUNET_log (GNUNET_ERROR_TYPE_ERROR,
"ESIGN security module key does not match SECM_ESIGN_PUBKEY in configuration\n");
GNUNET_free (fn);
return GNUNET_SYSERR;
}
}
@ -2639,15 +2641,50 @@ tofu_check (const struct TALER_SecurityModulePublicKeyP secm[2])
"SECM_DENOM_PUBKEY",
"key malformed");
GNUNET_free (key);
GNUNET_free (fn);
return GNUNET_SYSERR;
}
GNUNET_free (key);
if (0 !=
GNUNET_memcmp (&k,
&secm[0]))
&secmset->rsa))
{
GNUNET_log (GNUNET_ERROR_TYPE_ERROR,
"DENOM security module key does not match SECM_DENOM_PUBKEY in configuration\n");
GNUNET_free (fn);
return GNUNET_SYSERR;
}
}
if (GNUNET_OK ==
GNUNET_CONFIGURATION_get_value_string (kcfg,
"exchange-offline",
"SECM_DENOM_CS_PUBKEY",
&key))
{
struct TALER_SecurityModulePublicKeyP k;
if (GNUNET_OK !=
GNUNET_STRINGS_string_to_data (key,
strlen (key),
&k,
sizeof (k)))
{
GNUNET_log_config_invalid (GNUNET_ERROR_TYPE_ERROR,
"exchange-offline",
"SECM_DENOM_CS_PUBKEY",
"key malformed");
GNUNET_free (key);
GNUNET_free (fn);
return GNUNET_SYSERR;
}
GNUNET_free (key);
if (0 !=
GNUNET_memcmp (&k,
&secmset->cs))
{
GNUNET_log (GNUNET_ERROR_TYPE_ERROR,
"DENOM security module key does not match SECM_DENOM_CS_PUBKEY in configuration\n");
GNUNET_free (fn);
return GNUNET_SYSERR;
}
}
@ -2664,8 +2701,8 @@ tofu_check (const struct TALER_SecurityModulePublicKeyP secm[2])
/* persist keys for future runs */
if (GNUNET_OK !=
GNUNET_DISK_fn_write (fn,
secm,
sizeof (old),
secmset,
sizeof (oldset),
GNUNET_DISK_PERM_USER_READ))
{
GNUNET_log (GNUNET_ERROR_TYPE_ERROR,
@ -2674,6 +2711,7 @@ tofu_check (const struct TALER_SecurityModulePublicKeyP secm[2])
GNUNET_free (fn);
return GNUNET_SYSERR;
}
GNUNET_free (fn);
return GNUNET_NO;
}
@ -2770,12 +2808,14 @@ show_signkeys (const struct TALER_SecurityModulePublicKeyP *secm_pub,
/**
* Output @a denomkeys for human consumption.
*
* @param secm_pub security module public key used to sign the denominations
* @param secm_pub_rsa security module public key used to sign the RSA denominations
* @param secm_pub_cs security module public key used to sign the CS denominations
* @param denomkeys keys to output
* @return #GNUNET_OK on success
*/
static int
show_denomkeys (const struct TALER_SecurityModulePublicKeyP *secm_pub,
static enum GNUNET_GenericReturnValue
show_denomkeys (const struct TALER_SecurityModulePublicKeyP *secm_pub_rsa,
const struct TALER_SecurityModulePublicKeyP *secm_pub_cs,
const json_t *denomkeys)
{
size_t index;
@ -2868,7 +2908,21 @@ show_denomkeys (const struct TALER_SecurityModulePublicKeyP *secm_pub,
section_name,
stamp_start,
duration,
secm_pub,
secm_pub_rsa,
&secm_sig);
}
break;
case TALER_DENOMINATION_CS:
{
struct TALER_CsPubHashP h_cs;
TALER_cs_pub_hash (&denom_pub.details.cs_public_key,
&h_cs);
ok = TALER_exchange_secmod_cs_verify (&h_cs,
section_name,
stamp_start,
duration,
secm_pub_cs,
&secm_sig);
}
break;
@ -3023,7 +3077,7 @@ do_show (char *const *args)
json_t *denomkeys;
json_t *signkeys;
struct TALER_MasterPublicKeyP mpub;
struct TALER_SecurityModulePublicKeyP secm[2];
struct TALER_SecurityModulePublicKeySetP secmset;
struct GNUNET_JSON_Specification spec[] = {
GNUNET_JSON_spec_json ("future_denoms",
&denomkeys),
@ -3032,9 +3086,11 @@ do_show (char *const *args)
GNUNET_JSON_spec_fixed_auto ("master_pub",
&mpub),
GNUNET_JSON_spec_fixed_auto ("denom_secmod_public_key",
&secm[0]),
&secmset.rsa),
GNUNET_JSON_spec_fixed_auto ("denom_secmod_cs_public_key",
&secmset.cs),
GNUNET_JSON_spec_fixed_auto ("signkey_secmod_public_key",
&secm[1]),
&secmset.eddsa),
GNUNET_JSON_spec_end ()
};
@ -3076,7 +3132,7 @@ do_show (char *const *args)
return;
}
if (GNUNET_SYSERR ==
tofu_check (secm))
tofu_check (&secmset))
{
global_ret = EXIT_FAILURE;
test_shutdown ();
@ -3085,10 +3141,11 @@ do_show (char *const *args)
return;
}
if ( (GNUNET_OK !=
show_signkeys (&secm[1],
show_signkeys (&secmset.eddsa,
signkeys)) ||
(GNUNET_OK !=
show_denomkeys (&secm[0],
show_denomkeys (&secmset.rsa,
&secmset.cs,
denomkeys)) )
{
global_ret = EXIT_FAILURE;
@ -3111,7 +3168,7 @@ do_show (char *const *args)
* @param[in,out] result array where to output the signatures
* @return #GNUNET_OK on success
*/
static int
static enum GNUNET_GenericReturnValue
sign_signkeys (const struct TALER_SecurityModulePublicKeyP *secm_pub,
const json_t *signkeys,
json_t *result)
@ -3242,13 +3299,15 @@ load_age_mask (const char*section_name)
/**
* Sign @a denomkeys with offline key.
*
* @param secm_pub security module public key used to sign the denominations
* @param secm_pub_rsa security module public key used to sign the RSA denominations
* @param secm_pub_cs security module public key used to sign the CS denominations
* @param denomkeys keys to output
* @param[in,out] result array where to output the signatures
* @return #GNUNET_OK on success
*/
static enum GNUNET_GenericReturnValue
sign_denomkeys (const struct TALER_SecurityModulePublicKeyP *secm_pub,
sign_denomkeys (const struct TALER_SecurityModulePublicKeyP *secm_pub_rsa,
const struct TALER_SecurityModulePublicKeyP *secm_pub_cs,
const json_t *denomkeys,
json_t *result)
{
@ -3346,7 +3405,31 @@ sign_denomkeys (const struct TALER_SecurityModulePublicKeyP *secm_pub,
section_name,
stamp_start,
duration,
secm_pub,
secm_pub_rsa,
&secm_sig))
{
GNUNET_log (GNUNET_ERROR_TYPE_ERROR,
"Invalid security module signature for denomination key %s (aborting)\n",
GNUNET_h2s (&h_denom_pub.hash));
global_ret = EXIT_FAILURE;
test_shutdown ();
GNUNET_JSON_parse_free (spec);
return GNUNET_SYSERR;
}
}
break;
case TALER_DENOMINATION_CS:
{
struct TALER_CsPubHashP h_cs;
TALER_cs_pub_hash (&denom_pub.details.cs_public_key,
&h_cs);
if (GNUNET_OK !=
TALER_exchange_secmod_cs_verify (&h_cs,
section_name,
stamp_start,
duration,
secm_pub_cs,
&secm_sig))
{
GNUNET_log (GNUNET_ERROR_TYPE_ERROR,
@ -3410,7 +3493,7 @@ do_sign (char *const *args)
json_t *denomkeys;
json_t *signkeys;
struct TALER_MasterPublicKeyP mpub;
struct TALER_SecurityModulePublicKeyP secm[2];
struct TALER_SecurityModulePublicKeySetP secmset;
struct GNUNET_JSON_Specification spec[] = {
GNUNET_JSON_spec_json ("future_denoms",
&denomkeys),
@ -3419,9 +3502,11 @@ do_sign (char *const *args)
GNUNET_JSON_spec_fixed_auto ("master_pub",
&mpub),
GNUNET_JSON_spec_fixed_auto ("denom_secmod_public_key",
&secm[0]),
&secmset.rsa),
GNUNET_JSON_spec_fixed_auto ("denom_secmod_cs_public_key",
&secmset.cs),
GNUNET_JSON_spec_fixed_auto ("signkey_secmod_public_key",
&secm[1]),
&secmset.eddsa),
GNUNET_JSON_spec_end ()
};
@ -3465,7 +3550,7 @@ do_sign (char *const *args)
return;
}
if (GNUNET_SYSERR ==
tofu_check (secm))
tofu_check (&secmset))
{
GNUNET_log (GNUNET_ERROR_TYPE_ERROR,
"Fatal: security module keys changed!\n");
@ -3482,11 +3567,12 @@ do_sign (char *const *args)
GNUNET_assert (NULL != signkey_sig_array);
GNUNET_assert (NULL != denomkey_sig_array);
if ( (GNUNET_OK !=
sign_signkeys (&secm[1],
sign_signkeys (&secmset.eddsa,
signkeys,
signkey_sig_array)) ||
(GNUNET_OK !=
sign_denomkeys (&secm[0],
sign_denomkeys (&secmset.rsa,
&secmset.cs,
denomkeys,
denomkey_sig_array)) )
{

1
src/exchange/Makefile.am
View File

@ -79,6 +79,7 @@ taler_exchange_transfer_LDADD = \
taler_exchange_httpd_SOURCES = \
taler-exchange-httpd.c taler-exchange-httpd.h \
taler-exchange-httpd_auditors.c taler-exchange-httpd_auditors.h \
taler-exchange-httpd_csr.c taler-exchange-httpd_csr \
taler-exchange-httpd_db.c taler-exchange-httpd_db.h \
taler-exchange-httpd_deposit.c taler-exchange-httpd_deposit.h \
taler-exchange-httpd_deposits_get.c taler-exchange-httpd_deposits_get.h \

8
src/exchange/taler-exchange-aggregator.c
View File

@ -199,7 +199,7 @@ static int test_mode;
* Main work function that queries the DB and aggregates transactions
* into larger wire transfers.
*
* @param cls NULL
* @param cls a `struct Shard *`
*/
static void
run_aggregation (void *cls);
@ -679,12 +679,6 @@ release_shard (struct Shard *s)
}
/**
* Main work function that queries the DB and aggregates transactions
* into larger wire transfers.
*
* @param cls a `struct Shard *`
*/
static void
run_aggregation (void *cls)
{

10
src/exchange/taler-exchange-httpd.c
View File

@ -30,6 +30,7 @@
#include <limits.h>
#include "taler_mhd_lib.h"
#include "taler-exchange-httpd_auditors.h"
#include "taler-exchange-httpd_csr.h"
#include "taler-exchange-httpd_deposit.h"
#include "taler-exchange-httpd_deposits_get.h"
#include "taler-exchange-httpd_extensions.h"
@ -193,7 +194,7 @@ static unsigned long long req_max;
struct GNUNET_CURL_Context *TEH_curl_ctx;
/**
* Context for integrating #exchange_curl_ctx with the
* Context for integrating #TEH_curl_ctx with the
* GNUnet event loop.
*/
static struct GNUNET_CURL_RescheduleContext *exchange_curl_rc;
@ -922,6 +923,13 @@ handle_mhd_request (void *cls,
.method = MHD_HTTP_METHOD_GET,
.handler.get = &TEH_handler_wire
},
/* request R, used in clause schnorr withdraw and refresh */
{
.url = "csr",
.method = MHD_HTTP_METHOD_POST,
.handler.post = &TEH_handler_csr,
.nargs = 0
},
/* Withdrawing coins / interaction with reserves */
{
.url = "reserves",

210
src/exchange/taler-exchange-httpd_csr.c Normal file
View File

@ -0,0 +1,210 @@
/*
This file is part of TALER
Copyright (C) 2014-2021 Taler Systems SA
TALER is free software; you can redistribute it and/or modify
it under the terms of the GNU Affero General Public License as
published by the Free Software Foundation; either version 3,
or (at your option) any later version.
TALER is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty
of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU Affero General Public License for more details.
You should have received a copy of the GNU Affero General
Public License along with TALER; see the file COPYING. If not,
see <http://www.gnu.org/licenses/>
*/
/**
* @file taler-exchange-httpd_csr.c
* @brief Handle /csr requests
* @author Lucien Heuzeveldt
* @author Gian Demarmles
*/
#include "platform.h"
#include <gnunet/gnunet_util_lib.h>
#include <jansson.h>
#include "taler_json_lib.h"
#include "taler_mhd_lib.h"
#include "taler-exchange-httpd_csr.h"
#include "taler-exchange-httpd_responses.h"
#include "taler-exchange-httpd_keys.h"
MHD_RESULT
TEH_handler_csr (struct TEH_RequestContext *rc,
const json_t *root,
const char *const args[])
{
unsigned int csr_requests_num;
json_t *csr_requests;
json_t *csr_response_ewvs;
json_t *csr_response;
struct GNUNET_JSON_Specification spec[] = {
GNUNET_JSON_spec_json ("nks",
&csr_requests),
GNUNET_JSON_spec_end ()
};
enum TALER_ErrorCode ec;
struct TEH_DenominationKey *dk;
(void) args;
// parse input
{
enum GNUNET_GenericReturnValue res;
res = TALER_MHD_parse_json_data (rc->connection,
root,
spec);
if (GNUNET_OK != res)
return (GNUNET_SYSERR == res) ? MHD_NO : MHD_YES;
}
csr_requests_num = json_array_size (csr_requests);
if (TALER_MAX_FRESH_COINS <= csr_requests_num)
{
GNUNET_JSON_parse_free (spec);
return TALER_MHD_reply_with_error (
rc->connection,
MHD_HTTP_BAD_REQUEST,
TALER_EC_EXCHANGE_GENERIC_NEW_DENOMS_ARRAY_SIZE_EXCESSIVE,
NULL);
}
struct TALER_CsNonce nonces[GNUNET_NZL (csr_requests_num)];
struct TALER_DenominationHash denom_pub_hashes[GNUNET_NZL (csr_requests_num)];
for (unsigned int i = 0; i < csr_requests_num; i++)
{
struct TALER_CsNonce *nonce = &nonces[i];
struct TALER_DenominationHash *denom_pub_hash = &denom_pub_hashes[i];
struct GNUNET_JSON_Specification csr_spec[] = {
GNUNET_JSON_spec_fixed ("nonce",
nonce,
sizeof (struct TALER_CsNonce)),
GNUNET_JSON_spec_fixed ("denom_pub_hash",
denom_pub_hash,
sizeof (struct TALER_DenominationHash)),
GNUNET_JSON_spec_end ()
};
enum GNUNET_GenericReturnValue res;
res = TALER_MHD_parse_json_array (rc->connection,
csr_requests,
csr_spec,
i,
-1);
if (GNUNET_OK != res)
{
GNUNET_JSON_parse_free (spec);
return (GNUNET_NO == res) ? MHD_YES : MHD_NO;
}
}
GNUNET_JSON_parse_free (spec);
struct TALER_ExchangeWithdrawValues ewvs[GNUNET_NZL (csr_requests_num)];
for (unsigned int i = 0; i < csr_requests_num; i++)
{
const struct TALER_CsNonce *nonce = &nonces[i];
const struct TALER_DenominationHash *denom_pub_hash = &denom_pub_hashes[i];
struct TALER_DenominationCSPublicRPairP *r_pub
= &ewvs[i].details.cs_values;
ewvs[i].cipher = TALER_DENOMINATION_CS;
// check denomination referenced by denom_pub_hash
{
struct TEH_KeyStateHandle *ksh;
ksh = TEH_keys_get_state ();
if (NULL == ksh)
{
return TALER_MHD_reply_with_error (rc->connection,
MHD_HTTP_INTERNAL_SERVER_ERROR,
TALER_EC_EXCHANGE_GENERIC_KEYS_MISSING,
NULL);
}
dk = TEH_keys_denomination_by_hash2 (ksh,
denom_pub_hash,
NULL,
NULL);
if (NULL == dk)
{
return TEH_RESPONSE_reply_unknown_denom_pub_hash (
rc->connection,
&denom_pub_hash[i]);
}
if (GNUNET_TIME_absolute_is_past (dk->meta.expire_withdraw.abs_time))
{
/* This denomination is past the expiration time for withdraws/refreshes*/
return TEH_RESPONSE_reply_expired_denom_pub_hash (
rc->connection,
denom_pub_hash,
TALER_EC_EXCHANGE_GENERIC_DENOMINATION_EXPIRED,
"CSR");
}
if (GNUNET_TIME_absolute_is_future (dk->meta.start.abs_time))
{
/* This denomination is not yet valid, no need to check
for idempotency! */
return TEH_RESPONSE_reply_expired_denom_pub_hash (
rc->connection,
denom_pub_hash,
TALER_EC_EXCHANGE_GENERIC_DENOMINATION_VALIDITY_IN_FUTURE,
"CSR");
}
if (dk->recoup_possible)
{
/* This denomination has been revoked */
return TEH_RESPONSE_reply_expired_denom_pub_hash (
rc->connection,
denom_pub_hash,
TALER_EC_EXCHANGE_GENERIC_DENOMINATION_REVOKED,
"CSR");
}
if (TALER_DENOMINATION_CS != dk->denom_pub.cipher)
{
// denomination is valid but not CS
return TEH_RESPONSE_reply_invalid_denom_cipher_for_operation (
rc->connection,
denom_pub_hash);
}
}
// derive r_pub
// FIXME: bundle all requests into one derivation request (TEH_keys_..., crypto helper, security module)
ec = TEH_keys_denomination_cs_r_pub (denom_pub_hash,
nonce,
r_pub);
if (TALER_EC_NONE != ec)
{
GNUNET_break (0);
return TALER_MHD_reply_with_ec (rc->connection,
ec,
NULL);
}
}
// send response
csr_response_ewvs = json_array ();
for (unsigned int i = 0; i < csr_requests_num; i++)
{
json_t *csr_obj;
csr_obj = GNUNET_JSON_PACK (
TALER_JSON_pack_exchange_withdraw_values ("ewv",
&ewvs[i]));
GNUNET_assert (NULL != csr_obj);
GNUNET_assert (0 ==
json_array_append_new (csr_response_ewvs,
csr_obj));
}
csr_response = GNUNET_JSON_PACK (
GNUNET_JSON_pack_array_steal ("ewvs",
csr_response_ewvs));
GNUNET_assert (NULL != csr_response);
return TALER_MHD_reply_json_steal (rc->connection,
csr_response,
MHD_HTTP_OK);
}
/* end of taler-exchange-httpd_csr.c */

43
src/exchange/taler-exchange-httpd_csr.h Normal file
View File

@ -0,0 +1,43 @@
/*
This file is part of TALER
Copyright (C) 2014-2021 Taler Systems SA
TALER is free software; you can redistribute it and/or modify it under the
terms of the GNU Affero General Public License as published by the Free Software
Foundation; either version 3, or (at your option) any later version.
TALER is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.
You should have received a copy of the GNU Affero General Public License along with
TALER; see the file COPYING. If not, see <http://www.gnu.org/licenses/>
*/
/**
* @file taler-exchange-httpd_csr.h
* @brief Handle /csr requests
* @author Lucien Heuzeveldt
* @author Gian Demarmles
*/
#ifndef TALER_EXCHANGE_HTTPD_CSR_H
#define TALER_EXCHANGE_HTTPD_CSR_H
#include <microhttpd.h>
#include "taler-exchange-httpd.h"
/**
* Handle a "/csr" request. Parses the "nonce" and
* the "denom_pub_hash" (identifying a denomination) used to derive the r_pub.
*
* @param rc request context
* @param root uploaded JSON data
* @param args empty array
* @return MHD result code
*/
MHD_RESULT
TEH_handler_csr (struct TEH_RequestContext *rc,
const json_t *root,
const char *const args[]);
#endif

10
src/exchange/taler-exchange-httpd_deposit.c
View File

@ -51,6 +51,7 @@
* @param h_contract_terms hash of contract details
* @param exchange_timestamp exchange's timestamp
* @param refund_deadline until when this deposit be refunded
* @param wire_deadline until when will the exchange wire the funds
* @param merchant merchant public key
* @param amount_without_fee fraction of coin value to deposit, without the fee
* @return MHD result code
@ -359,6 +360,15 @@ TEH_handler_deposit (struct MHD_Connection *connection,
TALER_EC_EXCHANGE_GENERIC_DENOMINATION_REVOKED,
"DEPOSIT");
}
if (dk->denom_pub.cipher != deposit.coin.denom_sig.cipher)
{
/* denomination cipher and denomination signature cipher not the same */
GNUNET_JSON_parse_free (spec);
return TALER_MHD_reply_with_error (connection,
MHD_HTTP_BAD_REQUEST,
TALER_EC_EXCHANGE_GENERIC_CIPHER_MISMATCH,
NULL);
}
deposit.deposit_fee = dk->meta.fee_deposit;
/* check coin signature */

294
src/exchange/taler-exchange-httpd_keys.c
View File

@ -1,6 +1,6 @@
/*
This file is part of TALER
Copyright (C) 2020, 2021 Taler Systems SA
Copyright (C) 2020-2022 Taler Systems SA
TALER is free software; you can redistribute it and/or modify it under the
terms of the GNU Affero General Public License as published by the Free Software
@ -103,6 +103,11 @@ struct HelperDenomination
*/
struct TALER_RsaPubHashP h_rsa;
/**
* Hash of the CS key.
*/
struct TALER_CsPubHashP h_cs;
} h_details;
/**
@ -188,7 +193,12 @@ struct HelperState
/**
* Handle for the denom/RSA helper.
*/
struct TALER_CRYPTO_RsaDenominationHelper *dh;
struct TALER_CRYPTO_RsaDenominationHelper *rsadh;
/**
* Handle for the denom/CS helper.
*/
struct TALER_CRYPTO_CsDenominationHelper *csdh;
/**
* Map from H(denom_pub) to `struct HelperDenomination` entries.
@ -200,6 +210,11 @@ struct HelperState
*/
struct GNUNET_CONTAINER_MultiHashMap *rsa_keys;
/**
* Map from H(cs_pub) to `struct HelperDenomination` entries.
*/
struct GNUNET_CONTAINER_MultiHashMap *cs_keys;
/**
* Map from `struct TALER_ExchangePublicKey` to `struct HelperSignkey`
* entries. Based on the fact that a `struct GNUNET_PeerIdentity` is also
@ -424,7 +439,12 @@ static struct GNUNET_TIME_Relative signkey_legal_duration;
/**
* RSA security module public key, all zero if not known.
*/
static struct TALER_SecurityModulePublicKeyP denom_sm_pub;
static struct TALER_SecurityModulePublicKeyP denom_rsa_sm_pub;
/**
* CS security module public key, all zero if not known.
*/
static struct TALER_SecurityModulePublicKeyP denom_cs_sm_pub;
/**
* EdDSA security module public key, all zero if not known.
@ -541,6 +561,7 @@ check_dk (void *cls,
if (TALER_DENOMINATION_RSA == dk->denom_pub.cipher)
GNUNET_assert (GNUNET_CRYPTO_rsa_public_key_check (
dk->denom_pub.details.rsa_public_key));
// nothing to do for TALER_DENOMINATION_CS
return GNUNET_OK;
}
@ -609,19 +630,43 @@ clear_response_cache (struct TEH_KeyStateHandle *ksh)
* @param sm_pub RSA security module public key to check
*/
static void
check_denom_sm_pub (const struct TALER_SecurityModulePublicKeyP *sm_pub)
check_denom_rsa_sm_pub (const struct TALER_SecurityModulePublicKeyP *sm_pub)
{
if (0 !=
GNUNET_memcmp (sm_pub,
&denom_sm_pub))
&denom_rsa_sm_pub))
{
if (! GNUNET_is_zero (&denom_sm_pub))
if (! GNUNET_is_zero (&denom_rsa_sm_pub))
{
GNUNET_log (GNUNET_ERROR_TYPE_ERROR,
"Our RSA security module changed its key. This must not happen.\n");
GNUNET_assert (0);
}
denom_sm_pub = *sm_pub; /* TOFU ;-) */
denom_rsa_sm_pub = *sm_pub; /* TOFU ;-) */
}
}
/**
* Check that the given CS security module's public key is the one
* we have pinned. If it does not match, we die hard.
*
* @param sm_pub RSA security module public key to check
*/
static void
check_denom_cs_sm_pub (const struct TALER_SecurityModulePublicKeyP *sm_pub)
{
if (0 !=
GNUNET_memcmp (sm_pub,
&denom_cs_sm_pub))
{
if (! GNUNET_is_zero (&denom_cs_sm_pub))
{
GNUNET_log (GNUNET_ERROR_TYPE_ERROR,
"Our CS security module changed its key. This must not happen.\n");
GNUNET_assert (0);
}
denom_cs_sm_pub = *sm_pub; /* TOFU ;-) */
}
}
@ -659,7 +704,7 @@ check_esign_sm_pub (const struct TALER_SecurityModulePublicKeyP *sm_pub)
* @param value the `struct HelperDenomination` to release
* @return #GNUNET_OK (continue to iterate)
*/
static int
static enum GNUNET_GenericReturnValue
free_denom_cb (void *cls,
const struct GNUNET_HashCode *h_denom_pub,
void *value)
@ -712,6 +757,8 @@ destroy_key_helpers (struct HelperState *hs)
hs);
GNUNET_CONTAINER_multihashmap_destroy (hs->rsa_keys);
hs->rsa_keys = NULL;
GNUNET_CONTAINER_multihashmap_destroy (hs->cs_keys);
hs->cs_keys = NULL;
GNUNET_CONTAINER_multihashmap_destroy (hs->denom_keys);
hs->denom_keys = NULL;
GNUNET_CONTAINER_multipeermap_iterate (hs->esign_keys,
@ -719,10 +766,15 @@ destroy_key_helpers (struct HelperState *hs)
hs);
GNUNET_CONTAINER_multipeermap_destroy (hs->esign_keys);
hs->esign_keys = NULL;
if (NULL != hs->dh)
if (NULL != hs->rsadh)
{
TALER_CRYPTO_helper_rsa_disconnect (hs->dh);
hs->dh = NULL;
TALER_CRYPTO_helper_rsa_disconnect (hs->rsadh);
hs->rsadh = NULL;
}
if (NULL != hs->csdh)
{
TALER_CRYPTO_helper_cs_disconnect (hs->csdh);
hs->csdh = NULL;
}
if (NULL != hs->esh)
{
@ -743,7 +795,6 @@ static struct TALER_AgeMask
load_age_mask (const char*section_name)
{
static const struct TALER_AgeMask null_mask = {0};
enum GNUNET_GenericReturnValue ret;
struct TALER_AgeMask age_mask = TALER_extensions_age_restriction_ageMask ();
if (age_mask.mask == 0)
@ -753,21 +804,23 @@ load_age_mask (const char*section_name)
TEH_cfg,
section_name,
"AGE_RESTRICTED")))
return null_mask;
{
enum GNUNET_GenericReturnValue ret;
ret = GNUNET_CONFIGURATION_get_value_yesno (TEH_cfg,
if (GNUNET_SYSERR ==
(ret = GNUNET_CONFIGURATION_get_value_yesno (TEH_cfg,
section_name,
"AGE_RESTRICTED");
if (GNUNET_YES == ret)
return age_mask;
if (GNUNET_SYSERR == ret)
"AGE_RESTRICTED")))
{
GNUNET_log_config_invalid (GNUNET_ERROR_TYPE_ERROR,
section_name,
"AGE_RESTRICTED",
"Value must be YES or NO\n");
return null_mask;
}
}
return age_mask;
}
/**
@ -782,7 +835,7 @@ load_age_mask (const char*section_name)
* zero if the key has been revoked or purged
* @param validity_duration how long does the key remain available for signing;
* zero if the key has been revoked or purged
* @param h_denom_pub hash of the @a denom_pub that is available (or was purged)
* @param h_rsa hash of the @a denom_pub that is available (or was purged)
* @param denom_pub the public key itself, NULL if the key was revoked or purged
* @param sm_pub public key of the security module, NULL if the key was revoked or purged
* @param sm_sig signature from the security module, NULL if the key was revoked or purged
@ -819,7 +872,7 @@ helper_rsa_cb (
return;
}
GNUNET_assert (NULL != sm_pub);
check_denom_sm_pub (sm_pub);
check_denom_rsa_sm_pub (sm_pub);
hd = GNUNET_new (struct HelperDenomination);
hd->start_time = start_time;
hd->validity_duration = validity_duration;
@ -851,6 +904,86 @@ helper_rsa_cb (
}
/**
* Function called with information about available CS keys for signing. Usually
* only called once per key upon connect. Also called again in case a key is
* being revoked, in that case with an @a end_time of zero.
*
* @param cls closure with the `struct HelperState *`
* @param section_name name of the denomination type in the configuration;
* NULL if the key has been revoked or purged
* @param start_time when does the key become available for signing;
* zero if the key has been revoked or purged
* @param validity_duration how long does the key remain available for signing;
* zero if the key has been revoked or purged
* @param h_cs hash of the @a denom_pub that is available (or was purged)
* @param denom_pub the public key itself, NULL if the key was revoked or purged
* @param sm_pub public key of the security module, NULL if the key was revoked or purged
* @param sm_sig signature from the security module, NULL if the key was revoked or purged
* The signature was already verified against @a sm_pub.
*/
static void
helper_cs_cb (
void *cls,
const char *section_name,
struct GNUNET_TIME_Timestamp start_time,
struct GNUNET_TIME_Relative validity_duration,
const struct TALER_CsPubHashP *h_cs,
const struct TALER_DenominationPublicKey *denom_pub,
const struct TALER_SecurityModulePublicKeyP *sm_pub,
const struct TALER_SecurityModuleSignatureP *sm_sig)
{
struct HelperState *hs = cls;
struct HelperDenomination *hd;
GNUNET_log (GNUNET_ERROR_TYPE_INFO,
"CS helper announces key %s for denomination type %s with validity %s\n",
GNUNET_h2s (&h_cs->hash),
section_name,
GNUNET_STRINGS_relative_time_to_string (validity_duration,
GNUNET_NO));
key_generation++;
TEH_resume_keys_requests (false);
hd = GNUNET_CONTAINER_multihashmap_get (hs->cs_keys,
&h_cs->hash);
if (NULL != hd)
{
/* should be just an update (revocation!), so update existing entry */
hd->validity_duration = validity_duration;
return;
}
GNUNET_assert (NULL != sm_pub);
check_denom_cs_sm_pub (sm_pub);
hd = GNUNET_new (struct HelperDenomination);
hd->start_time = start_time;
hd->validity_duration = validity_duration;
hd->h_details.h_cs = *h_cs;
hd->sm_sig = *sm_sig;
GNUNET_assert (TALER_DENOMINATION_CS == denom_pub->cipher);
TALER_denom_pub_deep_copy (&hd->denom_pub,
denom_pub);
/* load the age mask for the denomination, if applicable */
hd->denom_pub.age_mask = load_age_mask (section_name);
TALER_denom_pub_hash (&hd->denom_pub,
&hd->h_denom_pub);
hd->section_name = GNUNET_strdup (section_name);
GNUNET_assert (
GNUNET_OK ==
GNUNET_CONTAINER_multihashmap_put (
hs->denom_keys,
&hd->h_denom_pub.hash,
hd,
GNUNET_CONTAINER_MULTIHASHMAPOPTION_UNIQUE_ONLY));
GNUNET_assert (
GNUNET_OK ==
GNUNET_CONTAINER_multihashmap_put (
hs->cs_keys,
&hd->h_details.h_cs.hash,
hd,
GNUNET_CONTAINER_MULTIHASHMAPOPTION_UNIQUE_ONLY));
}
/**
* Function called with information about available keys for signing. Usually
* only called once per key upon connect. Also called again in case a key is
@ -927,13 +1060,24 @@ setup_key_helpers (struct HelperState *hs)
hs->rsa_keys
= GNUNET_CONTAINER_multihashmap_create (1024,
GNUNET_YES);
hs->cs_keys
= GNUNET_CONTAINER_multihashmap_create (1024,
GNUNET_YES);
hs->esign_keys
= GNUNET_CONTAINER_multipeermap_create (32,
GNUNET_NO /* MUST BE NO! */);
hs->dh = TALER_CRYPTO_helper_rsa_connect (TEH_cfg,
hs->rsadh = TALER_CRYPTO_helper_rsa_connect (TEH_cfg,
&helper_rsa_cb,
hs);
if (NULL == hs->dh)
if (NULL == hs->rsadh)
{
destroy_key_helpers (hs);
return GNUNET_SYSERR;
}
hs->csdh = TALER_CRYPTO_helper_cs_connect (TEH_cfg,
&helper_cs_cb,
hs);
if (NULL == hs->csdh)
{
destroy_key_helpers (hs);
return GNUNET_SYSERR;
@ -958,7 +1102,8 @@ setup_key_helpers (struct HelperState *hs)
static void
sync_key_helpers (struct HelperState *hs)
{
TALER_CRYPTO_helper_rsa_poll (hs->dh);
TALER_CRYPTO_helper_rsa_poll (hs->rsadh);
TALER_CRYPTO_helper_cs_poll (hs->csdh);
TALER_CRYPTO_helper_esign_poll (hs->esh);
}
@ -971,7 +1116,7 @@ sync_key_helpers (struct HelperState *hs)
* @param value a `struct TEH_DenominationKey` to free
* @return #GNUNET_OK (continue to iterate)
*/
static int
static enum GNUNET_GenericReturnValue
clear_denomination_cb (void *cls,
const struct GNUNET_HashCode *h_denom_pub,
void *value)
@ -1002,7 +1147,7 @@ clear_denomination_cb (void *cls,
* @param value a `struct SigningKey` to free
* @return #GNUNET_OK (continue to iterate)
*/
static int
static enum GNUNET_GenericReturnValue
clear_signkey_cb (void *cls,
const struct GNUNET_PeerIdentity *pid,
void *value)
@ -1244,7 +1389,7 @@ struct GetAuditorSigsContext
* @param value a `struct TEH_DenominationKey`
* @return #GNUNET_OK (continue to iterate)
*/
static int
static enum GNUNET_GenericReturnValue
get_auditor_sigs (void *cls,
const struct GNUNET_HashCode *h_denom_pub,
void *value)
@ -1377,7 +1522,7 @@ struct SignKeyCtx
* @param value a `struct SigningKey`
* @return #GNUNET_OK (continue to iterate)
*/
static int
static enum GNUNET_GenericReturnValue
add_sign_key_cb (void *cls,
const struct GNUNET_PeerIdentity *pid,
void *value)
@ -1446,7 +1591,7 @@ struct DenomKeyCtx
* @param value a `struct TEH_DenominationKey`
* @return #GNUNET_OK (continue to iterate)
*/
static int
static enum GNUNET_GenericReturnValue
add_denom_key_cb (void *cls,
const struct GNUNET_HashCode *h_denom_pub,
void *value)
@ -1760,6 +1905,10 @@ create_krd (struct TEH_KeyStateHandle *ksh,
r = json_object_update (keys, sig);
GNUNET_assert (0 == r);
}
else
{
json_decref (extensions);
}
// Special case for age restrictions: if enabled, provide the list of
// age-restricted denominations.
@ -2286,44 +2435,73 @@ TEH_keys_denomination_by_hash2 (
}
struct TALER_BlindedDenominationSignature
enum TALER_ErrorCode
TEH_keys_denomination_sign (const struct TALER_DenominationHash *h_denom_pub,
const void *msg,
size_t msg_size,
enum TALER_ErrorCode *ec)
const struct TALER_BlindedPlanchet *bp,
struct TALER_BlindedDenominationSignature *bs)
{
struct TEH_KeyStateHandle *ksh;
struct HelperDenomination *hd;
ksh = TEH_keys_get_state ();
if (NULL == ksh)
return TALER_EC_EXCHANGE_GENERIC_KEYS_MISSING;
hd = GNUNET_CONTAINER_multihashmap_get (ksh->helpers->denom_keys,
&h_denom_pub->hash);
if (NULL == hd)
return TALER_EC_EXCHANGE_GENERIC_DENOMINATION_KEY_UNKNOWN;
if (bp->cipher != hd->denom_pub.cipher)
return TALER_EC_GENERIC_INTERNAL_INVARIANT_FAILURE;
switch (hd->denom_pub.cipher)
{
case TALER_DENOMINATION_RSA:
return TALER_CRYPTO_helper_rsa_sign (
ksh->helpers->rsadh,
&hd->h_details.h_rsa,
bp->details.rsa_blinded_planchet.blinded_msg,
bp->details.rsa_blinded_planchet.blinded_msg_size,
bs);
case TALER_DENOMINATION_CS:
return TALER_CRYPTO_helper_cs_sign (
ksh->helpers->csdh,
&hd->h_details.h_cs,
&bp->details.cs_blinded_planchet,
bs);
default:
return TALER_EC_GENERIC_INTERNAL_INVARIANT_FAILURE;
}
}
enum TALER_ErrorCode
TEH_keys_denomination_cs_r_pub (const struct
TALER_DenominationHash *h_denom_pub,
const struct TALER_CsNonce *nonce,
struct TALER_DenominationCSPublicRPairP *r_pub)
{
struct TEH_KeyStateHandle *ksh;
struct TALER_BlindedDenominationSignature none;
struct HelperDenomination *hd;
memset (&none,
0,
sizeof (none));
ksh = TEH_keys_get_state ();
if (NULL == ksh)
{
*ec = TALER_EC_EXCHANGE_GENERIC_KEYS_MISSING;
return none;
return TALER_EC_EXCHANGE_GENERIC_KEYS_MISSING;
}
hd = GNUNET_CONTAINER_multihashmap_get (ksh->helpers->denom_keys,
&h_denom_pub->hash);
if (NULL == hd)
{
*ec = TALER_EC_EXCHANGE_GENERIC_DENOMINATION_KEY_UNKNOWN;
return none;
return TALER_EC_EXCHANGE_GENERIC_DENOMINATION_KEY_UNKNOWN;
}
switch (hd->denom_pub.cipher)
if (TALER_DENOMINATION_CS != hd->denom_pub.cipher)
{
case TALER_DENOMINATION_RSA:
return TALER_CRYPTO_helper_rsa_sign (ksh->helpers->dh,
&hd->h_details.h_rsa,
msg,
msg_size,
ec);
default:
*ec = TALER_EC_GENERIC_INTERNAL_INVARIANT_FAILURE;
return none;
return TALER_EC_GENERIC_INTERNAL_INVARIANT_FAILURE;
}
return TALER_CRYPTO_helper_cs_r_derive (ksh->helpers->csdh,
&hd->h_details.h_cs,
nonce,
r_pub);
}
@ -2349,10 +2527,15 @@ TEH_keys_denomination_revoke (const struct TALER_DenominationHash *h_denom_pub)
switch (hd->denom_pub.cipher)
{
case TALER_DENOMINATION_RSA:
TALER_CRYPTO_helper_rsa_revoke (ksh->helpers->dh,
TALER_CRYPTO_helper_rsa_revoke (ksh->helpers->rsadh,
&hd->h_details.h_rsa);
TEH_keys_update_states ();
return;
case TALER_DENOMINATION_CS:
TALER_CRYPTO_helper_cs_revoke (ksh->helpers->csdh,
&hd->h_details.h_cs);
TEH_keys_update_states ();
return;
default:
GNUNET_break (0);
return;
@ -2948,7 +3131,8 @@ TEH_keys_management_get_keys_handler (const struct TEH_RequestHandler *rh,
.signkeys = json_array ()
};
if (GNUNET_is_zero (&denom_sm_pub))
if ( (GNUNET_is_zero (&denom_rsa_sm_pub)) &&
(GNUNET_is_zero (&denom_cs_sm_pub)) )
{
return TALER_MHD_reply_with_error (connection,
MHD_HTTP_BAD_GATEWAY,
@ -2979,7 +3163,9 @@ TEH_keys_management_get_keys_handler (const struct TEH_RequestHandler *rh,
GNUNET_JSON_pack_data_auto ("master_pub",
&TEH_master_public_key),
GNUNET_JSON_pack_data_auto ("denom_secmod_public_key",
&denom_sm_pub),
&denom_rsa_sm_pub),
GNUNET_JSON_pack_data_auto ("denom_secmod_cs_public_key",
&denom_cs_sm_pub),
GNUNET_JSON_pack_data_auto ("signkey_secmod_public_key",
&esign_sm_pub));
GNUNET_log (GNUNET_ERROR_TYPE_INFO,

42
src/exchange/taler-exchange-httpd_keys.h
View File

@ -1,6 +1,6 @@
/*
This file is part of TALER
Copyright (C) 2020 Taler Systems SA
Copyright (C) 2020-2022 Taler Systems SA
TALER is free software; you can redistribute it and/or modify it under the
terms of the GNU Affero General Public License as published by the Free Software
@ -160,32 +160,46 @@ TEH_keys_denomination_by_hash (const struct TALER_DenominationHash *h_denom_pub,
* or NULL if @a h_denom_pub could not be found
*/
struct TEH_DenominationKey *
TEH_keys_denomination_by_hash2 (struct TEH_KeyStateHandle *ksh,
const struct
TALER_DenominationHash *h_denom_pub,
TEH_keys_denomination_by_hash2 (
struct TEH_KeyStateHandle *ksh,
const struct TALER_DenominationHash *h_denom_pub,
struct MHD_Connection *conn,
MHD_RESULT *mret);
/**
* Request to sign @a msg using the public key corresponding to
* @a h_denom_pub.
*
* @param h_denom_pub hash of the public key to use to sign
* @param msg message to sign
* @param msg_size number of bytes in @a msg
* @param[out] ec set to the error code (or #TALER_EC_NONE on success)
* @return signature, the value inside the structure will be NULL on failure,
* see @a ec for details about the failure
* @param bp blinded planchet to sign
* @param[out] bs set to the blind signature on success
* @return #TALER_EC_NONE on success
*/
struct TALER_BlindedDenominationSignature
enum TALER_ErrorCode
TEH_keys_denomination_sign (const struct TALER_DenominationHash *h_denom_pub,
const void *msg,
size_t msg_size,
enum TALER_ErrorCode *ec);
const struct TALER_BlindedPlanchet *bp,
struct TALER_BlindedDenominationSignature *bs);
/**
* Revoke the public key associated with @param h_denom_pub .
* Request to derive CS @a r_pub using the denomination corresponding to @a h_denom_pub
* and @a nonce.
*
* @param h_denom_pub hash of the public key to use to derive r_pub
* @param nonce withdraw/refresh nonce
* @param[out] r_pub where to write the result
* @return #TALER_EC_NONE on success
*/
enum TALER_ErrorCode
TEH_keys_denomination_cs_r_pub (
const struct TALER_DenominationHash *h_denom_pub,
const struct TALER_CsNonce *nonce,
struct TALER_DenominationCSPublicRPairP *r_pub);
/**
* Revoke the public key associated with @a h_denom_pub.
* This function should be called AFTER the database was
* updated, as it also triggers #TEH_keys_update_states().
*

2
src/exchange/taler-exchange-httpd_kyc-check.h
View File

@ -29,7 +29,7 @@
* Handle a "/kyc-check" request. Checks the KYC
* status of the given account and returns it.
*
* @param connection request to handle
* @param rc details about the request to handle
* @param args one argument with the payment_target_uuid
* @return MHD result code
*/

14
src/exchange/taler-exchange-httpd_link.c
View File

@ -1,6 +1,6 @@
/*
This file is part of TALER
Copyright (C) 2014-2019 Taler Systems SA
Copyright (C) 2014-2019, 2022 Taler Systems SA
TALER is free software; you can redistribute it and/or modify it under the
terms of the GNU Affero General Public License as published by the Free Software
@ -86,8 +86,18 @@ handle_link_data (void *cls,
&pos->denom_pub),
TALER_JSON_pack_blinded_denom_sig ("ev_sig",
&pos->ev_sig),
GNUNET_JSON_pack_uint64 ("coin_idx",
pos->coin_refresh_offset),
TALER_JSON_pack_exchange_withdraw_values ("ewv",
&pos->alg_values),
GNUNET_JSON_pack_data_auto ("link_sig",
&pos->orig_coin_link_sig));
&pos->orig_coin_link_sig),
GNUNET_JSON_pack_allow_null (
pos->have_nonce
? GNUNET_JSON_pack_data_auto ("cs_nonce",
&pos->nonce)
: GNUNET_JSON_pack_string ("cs_nonce",
NULL)));
if ( (NULL == obj) ||
(0 !=
json_array_append_new (list,

7
src/exchange/taler-exchange-httpd_melt.c
View File

@ -1,6 +1,6 @@
/*
This file is part of TALER
Copyright (C) 2014-2021 Taler Systems SA
Copyright (C) 2014-2022 Taler Systems SA
TALER is free software; you can redistribute it and/or modify it under the
terms of the GNU Affero General Public License as published by the Free Software
@ -183,6 +183,7 @@ melt_transaction (void *cls,
}
if (! balance_ok)
{
GNUNET_break_op (0);
TEH_plugin->rollback (TEH_plugin->cls);
*mhd_ret
= TEH_RESPONSE_reply_coin_insufficient_funds (
@ -302,6 +303,10 @@ check_melt_valid (struct MHD_Connection *connection,
rmc->coin_refresh_fee = dk->meta.fee_refresh;
rmc->coin_value = dk->meta.value;
GNUNET_log (GNUNET_ERROR_TYPE_INFO,
"Melted coin's denomination is worth %s\n",
TALER_amount2s (&dk->meta.value));
/* sanity-check that "total melt amount > melt fee" */
if (0 <
TALER_amount_cmp (&rmc->coin_refresh_fee,

6
src/exchange/taler-exchange-httpd_melt.h
View File

@ -30,10 +30,10 @@
/**
* Handle a "/coins/$COIN_PUB/melt" request. Parses the request into the JSON
* components and then hands things of to #check_for_denomination_key() to
* components and then hands things of to #check_melt_valid() to
* validate the melted coins, the signature and execute the melt using
* handle_melt().
* melt_transaction().
*
* @param connection the MHD connection to handle
* @param coin_pub public key of the coin
* @param root uploaded JSON data

32
src/exchange/taler-exchange-httpd_recoup-refresh.c
View File

@ -162,6 +162,8 @@ recoup_refresh_transaction (void *cls,
*
* @param connection the MHD connection to handle
* @param coin information about the coin
* @param exchange_vals values contributed by the exchange
* during refresh
* @param coin_bks blinding data of the coin (to be checked)
* @param coin_sig signature of the coin
* @return MHD result code
@ -170,7 +172,9 @@ static MHD_RESULT
verify_and_execute_recoup_refresh (
struct MHD_Connection *connection,
const struct TALER_CoinPublicInfo *coin,
const struct TALER_ExchangeWithdrawValues *exchange_vals,
const union TALER_DenominationBlindingKeyP *coin_bks,
const struct TALER_CsNonce *nonce,
const struct TALER_CoinSpendSignatureP *coin_sig)
{
struct RecoupContext pc;
@ -241,18 +245,17 @@ verify_and_execute_recoup_refresh (
}
{
void *coin_ev;
size_t coin_ev_size;
struct TALER_CoinPubHash c_hash;
struct TALER_BlindedPlanchet blinded_planchet;
if (GNUNET_OK !=
TALER_denom_blind (&dk->denom_pub,
coin_bks,
NULL, /* FIXME-Oec: TALER_AgeCommitmentHash * */
&coin->coin_pub,
exchange_vals,
&c_hash,
&coin_ev,
&coin_ev_size))
&blinded_planchet))
{
GNUNET_break (0);
return TALER_MHD_reply_with_error (
@ -261,10 +264,13 @@ verify_and_execute_recoup_refresh (
TALER_EC_EXCHANGE_RECOUP_REFRESH_BLINDING_FAILED,
NULL);
}
TALER_coin_ev_hash (coin_ev,
coin_ev_size,
if (TALER_DENOMINATION_CS == blinded_planchet.cipher)
blinded_planchet.details.cs_blinded_planchet.nonce
= *nonce;
TALER_coin_ev_hash (&blinded_planchet,
&coin->denom_pub_hash,
&h_blind);
GNUNET_free (coin_ev);
TALER_blinded_planchet_free (&blinded_planchet);
}
pc.coin_sig = coin_sig;
@ -357,21 +363,31 @@ TEH_handler_recoup_refresh (struct MHD_Connection *connection,
struct TALER_CoinPublicInfo coin;
union TALER_DenominationBlindingKeyP coin_bks;
struct TALER_CoinSpendSignatureP coin_sig;
struct TALER_ExchangeWithdrawValues exchange_vals;
struct TALER_CsNonce nonce;
struct GNUNET_JSON_Specification spec[] = {
GNUNET_JSON_spec_fixed_auto ("denom_pub_hash",
&coin.denom_pub_hash),
TALER_JSON_spec_denom_sig ("denom_sig",
&coin.denom_sig),
TALER_JSON_spec_exchange_withdraw_values ("ewv",
&exchange_vals),
GNUNET_JSON_spec_fixed_auto ("coin_blind_key_secret",
&coin_bks),
GNUNET_JSON_spec_fixed_auto ("coin_sig",
&coin_sig),
GNUNET_JSON_spec_mark_optional (
GNUNET_JSON_spec_fixed_auto ("cs_nonce",
&nonce)),
GNUNET_JSON_spec_end ()
};
memset (&coin,
0,
sizeof (coin));
memset (&nonce,
0,
sizeof (nonce));
coin.coin_pub = *coin_pub;
ret = TALER_MHD_parse_json_data (connection,
root,
@ -385,7 +401,9 @@ TEH_handler_recoup_refresh (struct MHD_Connection *connection,
res = verify_and_execute_recoup_refresh (connection,
&coin,
&exchange_vals,
&coin_bks,
&nonce,
&coin_sig);
GNUNET_JSON_parse_free (spec);
return res;

2
src/exchange/taler-exchange-httpd_recoup-refresh.h
View File

@ -14,7 +14,7 @@
TALER; see the file COPYING. If not, see <http://www.gnu.org/licenses/>
*/
/**
* @file taler-exchange-httpd_recoup_refresh.h
* @file taler-exchange-httpd_recoup-refresh.h
* @brief Handle /recoup-refresh requests
* @author Christian Grothoff
*/

62
src/exchange/taler-exchange-httpd_recoup.c
View File

@ -1,6 +1,6 @@
/*
This file is part of TALER
Copyright (C) 2017-2021 Taler Systems SA
Copyright (C) 2017-2022 Taler Systems SA
TALER is free software; you can redistribute it and/or modify it under the
terms of the GNU Affero General Public License as published by the Free Software
@ -40,9 +40,9 @@
struct RecoupContext
{
/**
* Hash of the blinded coin.
* Hash identifying the withdraw request.
*/
struct TALER_BlindedCoinHash h_blind;
struct TALER_WithdrawIdentificationHash wih;
/**
* Set by #recoup_transaction() to the reserve that will
@ -165,6 +165,8 @@ recoup_transaction (void *cls,
*
* @param connection the MHD connection to handle
* @param coin information about the coin
* @param exchange_vals values contributed by the exchange
* during withdrawal
* @param coin_bks blinding data of the coin (to be checked)
* @param coin_sig signature of the coin
* @return MHD result code
@ -173,7 +175,9 @@ static MHD_RESULT
verify_and_execute_recoup (
struct MHD_Connection *connection,
const struct TALER_CoinPublicInfo *coin,
const struct TALER_ExchangeWithdrawValues *exchange_vals,
const union TALER_DenominationBlindingKeyP *coin_bks,
const struct TALER_CsNonce *nonce,
const struct TALER_CoinSpendSignatureP *coin_sig)
{
struct RecoupContext pc;
@ -242,19 +246,21 @@ verify_and_execute_recoup (
NULL);
}
/* re-compute client-side blinding so we can
(a bit later) check that this coin was indeed
signed by us. */
{
void *coin_ev;
size_t coin_ev_size;
struct TALER_CoinPubHash c_hash;
struct TALER_BlindedPlanchet blinded_planchet;
if (GNUNET_OK !=
TALER_denom_blind (&dk->denom_pub,
coin_bks,
NULL, /* FIXME-Oec: TALER_AgeCommitmentHash * */
&coin->coin_pub,
exchange_vals,
&c_hash,
&coin_ev,
&coin_ev_size))
&blinded_planchet))
{
GNUNET_break (0);
return TALER_MHD_reply_with_error (
@ -263,10 +269,21 @@ verify_and_execute_recoup (
TALER_EC_EXCHANGE_RECOUP_BLINDING_FAILED,
NULL);
}
TALER_coin_ev_hash (coin_ev,
coin_ev_size,
&pc.h_blind);
GNUNET_free (coin_ev);
if (TALER_DENOMINATION_CS == blinded_planchet.cipher)
blinded_planchet.details.cs_blinded_planchet.nonce
= *nonce;
if (GNUNET_OK !=
TALER_withdraw_request_hash (&blinded_planchet,
&coin->denom_pub_hash,
&pc.wih))
{
GNUNET_break (0);
return TALER_MHD_reply_with_error (connection,
MHD_HTTP_INTERNAL_SERVER_ERROR,
TALER_EC_GENERIC_INTERNAL_INVARIANT_FAILURE,
NULL);
}
TALER_blinded_planchet_free (&blinded_planchet);
}
pc.coin_sig = coin_sig;
@ -291,8 +308,8 @@ verify_and_execute_recoup (
{
enum GNUNET_DB_QueryStatus qs;
qs = TEH_plugin->get_reserve_by_h_blind (TEH_plugin->cls,
&pc.h_blind,
qs = TEH_plugin->get_reserve_by_wih (TEH_plugin->cls,
&pc.wih,
&pc.reserve_pub,
&pc.reserve_out_serial_id);
if (0 > qs)
@ -302,13 +319,13 @@ verify_and_execute_recoup (
connection,
MHD_HTTP_INTERNAL_SERVER_ERROR,
TALER_EC_GENERIC_DB_FETCH_FAILED,
"get_reserve_by_h_blind");
"get_reserve_by_wih");
}
if (GNUNET_DB_STATUS_SUCCESS_NO_RESULTS == qs)
{
GNUNET_log (GNUNET_ERROR_TYPE_INFO,
"Recoup requested for unknown envelope %s\n",
GNUNET_h2s (&pc.h_blind.hash));
GNUNET_h2s (&pc.wih.hash));
return TALER_MHD_reply_with_error (
connection,
MHD_HTTP_NOT_FOUND,
@ -359,21 +376,31 @@ TEH_handler_recoup (struct MHD_Connection *connection,
struct TALER_CoinPublicInfo coin;
union TALER_DenominationBlindingKeyP coin_bks;
struct TALER_CoinSpendSignatureP coin_sig;
struct TALER_ExchangeWithdrawValues exchange_vals;
struct TALER_CsNonce nonce;
struct GNUNET_JSON_Specification spec[] = {
GNUNET_JSON_spec_fixed_auto ("denom_pub_hash",
&coin.denom_pub_hash),
TALER_JSON_spec_denom_sig ("denom_sig",
&coin.denom_sig),
TALER_JSON_spec_exchange_withdraw_values ("ewv",
&exchange_vals),
GNUNET_JSON_spec_fixed_auto ("coin_blind_key_secret",
&coin_bks),
GNUNET_JSON_spec_fixed_auto ("coin_sig",
&coin_sig),
GNUNET_JSON_spec_mark_optional (
GNUNET_JSON_spec_fixed_auto ("cs_nonce",
&nonce)),
GNUNET_JSON_spec_end ()
};
memset (&coin,
0,
sizeof (coin));
memset (&nonce,
0,
sizeof (nonce));
coin.coin_pub = *coin_pub;
ret = TALER_MHD_parse_json_data (connection,
root,
@ -382,12 +409,17 @@ TEH_handler_recoup (struct MHD_Connection *connection,
return MHD_NO; /* hard failure */
if (GNUNET_NO == ret)
return MHD_YES; /* failure */
GNUNET_log (GNUNET_ERROR_TYPE_ERROR,
"Recoup coin with BKS=%s\n",
TALER_B2S (&coin_bks));
{
MHD_RESULT res;
res = verify_and_execute_recoup (connection,
&coin,
&exchange_vals,
&coin_bks,
&nonce,
&coin_sig);
GNUNET_JSON_parse_free (spec);
return res;

171
src/exchange/taler-exchange-httpd_refreshes_reveal.c
View File

@ -1,6 +1,6 @@
/*
This file is part of TALER
Copyright (C) 2014-2019, 2021 Taler Systems SA
Copyright (C) 2014-2022 Taler Systems SA
TALER is free software; you can redistribute it and/or modify it under the
terms of the GNU Affero General Public License as published by the Free Software
@ -31,18 +31,12 @@
#include "taler-exchange-httpd_keys.h"
/**
* Maximum number of fresh coins we allow per refresh operation.
*/
#define MAX_FRESH_COINS 256
/**
* Send a response for "/refreshes/$RCH/reveal".
*
* @param connection the connection to send the response to
* @param num_freshcoins number of new coins for which we reveal data
* @param sigs array of @a num_freshcoins signatures revealed
* @param rrcs array of @a num_freshcoins signatures revealed
* @return a MHD result code
*/
static MHD_RESULT
@ -108,6 +102,14 @@ struct RevealContext
*/
const struct TEH_DenominationKey **dks;
/**
* Array of information about fresh coins being revealed.
*/
/* FIXME: const would be nicer here, but we initalize
the 'alg_values' in the verification
routine; suboptimal to be fixed... */
struct TALER_EXCHANGEDB_RefreshRevealedCoin *rrcs;
/**
* Envelopes to be signed.
*/
@ -142,6 +144,79 @@ check_commitment (struct RevealContext *rctx,
struct MHD_Connection *connection,
MHD_RESULT *mhd_ret)
{
struct TALER_CsNonce nonces[rctx->num_fresh_coins];
unsigned int aoff = 0;
for (unsigned int j = 0; j<rctx->num_fresh_coins; j++)
{
const struct TALER_DenominationPublicKey *dk = &rctx->dks[j]->denom_pub;
if (dk->cipher != rctx->rcds[j].blinded_planchet.cipher)
{
GNUNET_break (0);
*mhd_ret = TALER_MHD_reply_with_error (
connection,
MHD_HTTP_BAD_REQUEST,
TALER_EC_EXCHANGE_GENERIC_CIPHER_MISMATCH,
NULL);
return GNUNET_SYSERR;
}
switch (dk->cipher)
{
case TALER_DENOMINATION_INVALID:
GNUNET_break (0);
*mhd_ret = TALER_MHD_reply_with_error (
connection,
MHD_HTTP_INTERNAL_SERVER_ERROR,
TALER_EC_GENERIC_INTERNAL_INVARIANT_FAILURE,
NULL);
return GNUNET_SYSERR;
case TALER_DENOMINATION_RSA:
continue;
case TALER_DENOMINATION_CS:
nonces[aoff]
= rctx->rcds[j].blinded_planchet.details.cs_blinded_planchet.nonce;
aoff++;
break;
}
}
// OPTIMIZE: do this in batch later!
aoff = 0;
for (unsigned int j = 0; j<rctx->num_fresh_coins; j++)
{
const struct TALER_DenominationPublicKey *dk = &rctx->dks[j]->denom_pub;
struct TALER_ExchangeWithdrawValues *alg_values
= &rctx->rrcs[j].exchange_vals;
alg_values->cipher = dk->cipher;
switch (dk->cipher)
{
case TALER_DENOMINATION_INVALID:
GNUNET_assert (0);
return GNUNET_SYSERR;
case TALER_DENOMINATION_RSA:
continue;
case TALER_DENOMINATION_CS:
{
enum TALER_ErrorCode ec;
ec = TEH_keys_denomination_cs_r_pub (
&rctx->rrcs[j].h_denom_pub,
&nonces[aoff],
&alg_values->details.cs_values);
if (TALER_EC_NONE != ec)
{
*mhd_ret = TALER_MHD_reply_with_error (connection,
MHD_HTTP_INTERNAL_SERVER_ERROR,
ec,
NULL);
return GNUNET_SYSERR;
}
aoff++;
}
}
}
/* Verify commitment */
{
/* Note that the contents of rcs[melt.session.noreveal_index]
@ -177,25 +252,45 @@ check_commitment (struct RevealContext *rctx,
&ts);
rce->new_coins = GNUNET_new_array (rctx->num_fresh_coins,
struct TALER_RefreshCoinData);
aoff = 0;
for (unsigned int j = 0; j<rctx->num_fresh_coins; j++)
{
const struct TALER_DenominationPublicKey *dk
= &rctx->dks[j]->denom_pub;
struct TALER_RefreshCoinData *rcd = &rce->new_coins[j];
struct TALER_PlanchetSecretsP ps;
struct TALER_CoinSpendPrivateKeyP coin_priv;
union TALER_DenominationBlindingKeyP bks;
const struct TALER_ExchangeWithdrawValues *alg_value
= &rctx->rrcs[j].exchange_vals;
struct TALER_PlanchetDetail pd;
struct TALER_CoinPubHash c_hash;
struct TALER_PlanchetMasterSecretP ps;
rcd->dk = &rctx->dks[j]->denom_pub;
TALER_planchet_setup_refresh (&ts,
TALER_transfer_secret_to_planchet_secret (&ts,
j,
&ps);
TALER_planchet_setup_coin_priv (&ps,
alg_value,
&coin_priv);
TALER_planchet_blinding_secret_create (&ps,
alg_value,
&bks);
GNUNET_assert (GNUNET_OK ==
TALER_planchet_prepare (rcd->dk,
&ps,
alg_value,
&bks,
&coin_priv,
NULL, /* FIXME-Oec, struct TALER_AgeCommitmentHash * */
&c_hash,
&pd));
rcd->coin_ev = pd.coin_ev;
rcd->coin_ev_size = pd.coin_ev_size;
if (TALER_DENOMINATION_CS == dk->cipher)
{
pd.blinded_planchet.details.cs_blinded_planchet.nonce =
nonces[aoff];
aoff++;
}
rcd->blinded_planchet = pd.blinded_planchet;
}
}
}
@ -217,7 +312,7 @@ check_commitment (struct RevealContext *rctx,
{
struct TALER_RefreshCoinData *rcd = &rce->new_coins[j];
GNUNET_free (rcd->coin_ev);
TALER_blinded_planchet_free (&rcd->blinded_planchet);
}
GNUNET_free (rce->new_coins);
}
@ -299,7 +394,7 @@ resolve_refreshes_reveal_denominations (struct MHD_Connection *connection,
const json_t *coin_evs)
{
unsigned int num_fresh_coins = json_array_size (new_denoms_h_json);
/* We know num_fresh_coins is bounded by #MAX_FRESH_COINS, so this is safe */
/* We know num_fresh_coins is bounded by #TALER_MAX_FRESH_COINS, so this is safe */
const struct TEH_DenominationKey *dks[num_fresh_coins];
struct TALER_RefreshCoinData rcds[num_fresh_coins];
struct TALER_EXCHANGEDB_RefreshRevealedCoin rrcs[num_fresh_coins];
@ -379,9 +474,8 @@ resolve_refreshes_reveal_denominations (struct MHD_Connection *connection,
{
struct TALER_EXCHANGEDB_RefreshRevealedCoin *rrc = &rrcs[i];
struct GNUNET_JSON_Specification spec[] = {
GNUNET_JSON_spec_varsize (NULL,
&rrc->coin_ev,
&rrc->coin_ev_size),
TALER_JSON_spec_blinded_planchet (NULL,
&rrc->blinded_planchet),
GNUNET_JSON_spec_end ()
};
enum GNUNET_GenericReturnValue res;
@ -394,12 +488,12 @@ resolve_refreshes_reveal_denominations (struct MHD_Connection *connection,
if (GNUNET_OK != res)
{
for (unsigned int j = 0; j<i; j++)
GNUNET_free (rrcs[j].coin_ev);
TALER_blinded_planchet_free (&rrcs[j].blinded_planchet);
return (GNUNET_NO == res) ? MHD_YES : MHD_NO;
}
GNUNET_CRYPTO_hash (rrc->coin_ev,
rrc->coin_ev_size,
&rrc->coin_envelope_hash.hash);
TALER_coin_ev_hash (&rrc->blinded_planchet,
&rrcs[i].h_denom_pub,
&rrc->coin_envelope_hash);
}
/* lookup old_coin_pub in database */
@ -492,13 +586,23 @@ resolve_refreshes_reveal_denominations (struct MHD_Connection *connection,
const struct TALER_EXCHANGEDB_RefreshRevealedCoin *rrc = &rrcs[i];
struct TALER_RefreshCoinData *rcd = &rcds[i];
rcd->coin_ev = rrc->coin_ev;
rcd->coin_ev_size = rrc->coin_ev_size;
rcd->blinded_planchet = rrc->blinded_planchet;
rcd->dk = &dks[i]->denom_pub;
if (rcd->blinded_planchet.cipher != rcd->dk->cipher)
{
GNUNET_break_op (0);
ret = TALER_MHD_REPLY_JSON_PACK (
connection,
MHD_HTTP_BAD_REQUEST,
TALER_JSON_pack_ec (
TALER_EC_EXCHANGE_GENERIC_CIPHER_MISMATCH));
goto cleanup;
}
}
rctx->dks = dks;
rctx->rcds = rcds;
rctx->rrcs = rrcs;
if (GNUNET_OK !=
check_commitment (rctx,
connection,
@ -512,14 +616,12 @@ resolve_refreshes_reveal_denominations (struct MHD_Connection *connection,
/* create fresh coin signatures */
for (unsigned int i = 0; i<rctx->num_fresh_coins; i++)
{
enum TALER_ErrorCode ec = TALER_EC_NONE;
enum TALER_ErrorCode ec;
rrcs[i].coin_sig
= TEH_keys_denomination_sign (
ec = TEH_keys_denomination_sign (
&rrcs[i].h_denom_pub,
rcds[i].coin_ev,
rcds[i].coin_ev_size,
&ec);
&rcds[i].blinded_planchet,
&rrcs[i].coin_sig);
if (TALER_EC_NONE != ec)
{
GNUNET_break (0);
@ -541,8 +643,7 @@ resolve_refreshes_reveal_denominations (struct MHD_Connection *connection,
{
struct TALER_EXCHANGEDB_RefreshRevealedCoin *rrc = &rrcs[i];
rrc->coin_ev = rcds[i].coin_ev;
rrc->coin_ev_size = rcds[i].coin_ev_size;
rrc->blinded_planchet = rcds[i].blinded_planchet;
}
qs = TEH_plugin->insert_refresh_reveal (TEH_plugin->cls,
melt_serial_id,
@ -575,7 +676,7 @@ cleanup:
struct TALER_EXCHANGEDB_RefreshRevealedCoin *rrc = &rrcs[i];
TALER_blinded_denom_sig_free (&rrc->coin_sig);
GNUNET_free (rrc->coin_ev);
TALER_blinded_planchet_free (&rrc->blinded_planchet);
}
return ret;
}
@ -616,13 +717,13 @@ handle_refreshes_reveal_json (struct MHD_Connection *connection,
unsigned int num_tprivs = json_array_size (tp_json);
GNUNET_assert (num_tprivs == TALER_CNC_KAPPA - 1); /* checked just earlier */
if ( (num_fresh_coins >= MAX_FRESH_COINS) ||
if ( (num_fresh_coins >= TALER_MAX_FRESH_COINS) ||
(0 == num_fresh_coins) )
{
GNUNET_break_op (0);
return TALER_MHD_reply_with_error (connection,
MHD_HTTP_BAD_REQUEST,
TALER_EC_EXCHANGE_REFRESHES_REVEAL_NEW_DENOMS_ARRAY_SIZE_EXCESSIVE,
TALER_EC_EXCHANGE_GENERIC_NEW_DENOMS_ARRAY_SIZE_EXCESSIVE,
NULL);
}

59
src/exchange/taler-exchange-httpd_responses.c
View File

@ -503,18 +503,53 @@ TEH_RESPONSE_reply_expired_denom_pub_hash (
}
/**
* Send proof that a request is invalid to client because of
* insufficient funds. This function will create a message with all
* of the operations affecting the coin that demonstrate that the coin
* has insufficient value.
*
* @param connection connection to the client
* @param ec error code to return
* @param coin_pub public key of the coin
* @param tl transaction list to use to build reply
* @return MHD result code
*/
MHD_RESULT
TEH_RESPONSE_reply_invalid_denom_cipher_for_operation (
struct MHD_Connection *connection,
const struct TALER_DenominationHash *dph)
{
struct TALER_ExchangePublicKeyP epub;
struct TALER_ExchangeSignatureP esig;
struct GNUNET_TIME_Timestamp now;
enum TALER_ErrorCode ec;
now = GNUNET_TIME_timestamp_get ();
{
struct TALER_DenominationUnknownAffirmationPS dua = {
.purpose.size = htonl (sizeof (dua)),
.purpose.purpose = htonl (TALER_SIGNATURE_EXCHANGE_AFFIRM_DENOM_UNKNOWN),
.timestamp = GNUNET_TIME_timestamp_hton (now),
.h_denom_pub = *dph,
};
ec = TEH_keys_exchange_sign (&dua,
&epub,
&esig);
}
if (TALER_EC_NONE != ec)
{
GNUNET_break (0);
return TALER_MHD_reply_with_error (connection,
MHD_HTTP_INTERNAL_SERVER_ERROR,
ec,
NULL);
}
return TALER_MHD_REPLY_JSON_PACK (
connection,
MHD_HTTP_NOT_FOUND,
TALER_JSON_pack_ec (
TALER_EC_EXCHANGE_GENERIC_INVALID_DENOMINATION_CIPHER_FOR_OPERATION),
GNUNET_JSON_pack_timestamp ("timestamp",
now),
GNUNET_JSON_pack_data_auto ("exchange_pub",
&epub),
GNUNET_JSON_pack_data_auto ("exchange_sig",
&esig),
GNUNET_JSON_pack_data_auto ("h_denom_pub",
dph));
}
MHD_RESULT
TEH_RESPONSE_reply_coin_insufficient_funds (
struct MHD_Connection *connection,

13
src/exchange/taler-exchange-httpd_responses.h
View File

@ -79,6 +79,19 @@ TEH_RESPONSE_reply_expired_denom_pub_hash (
const char *oper);
/**
* Send assertion that the given denomination cannot be used for this operation.
*
* @param connection connection to the client
* @param dph denomination public key hash
* @return MHD result code
*/
MHD_RESULT
TEH_RESPONSE_reply_invalid_denom_cipher_for_operation (
struct MHD_Connection *connection,
const struct TALER_DenominationHash *dph);
/**
* Send proof that a request is invalid to client because of
* insufficient funds. This function will create a message with all

5
src/exchange/taler-exchange-httpd_wire.c
View File

@ -107,7 +107,7 @@ wire_update_event_cb (void *cls,
}
int
enum GNUNET_GenericReturnValue
TEH_wire_init ()
{
struct GNUNET_DB_EventHeaderP es = {
@ -147,8 +147,7 @@ TEH_wire_done ()
/**
* Create standard JSON response format using
* @param ec and @a detail
* Create standard JSON response format using @a ec and @a detail.
*
* @param ec error code to return
* @param detail optional detail text to return, can be NULL

122
src/exchange/taler-exchange-httpd_withdraw.c
View File

@ -90,20 +90,31 @@ reply_withdraw_insufficient_funds (
*/
struct WithdrawContext
{
/**
* Details about the withdrawal request.
* Hash that uniquely identifies the withdraw request.
*/
struct TALER_WithdrawRequestPS wsrd;
struct TALER_WithdrawIdentificationHash wih;
/**
* Hash of the (blinded) message to be signed by the Exchange.
*/
struct TALER_BlindedCoinHash h_coin_envelope;
/**
* Value of the coin being exchanged (matching the denomination key)
* plus the transaction fee. We include this in what is being
* signed so that we can verify a reserve's remaining total balance
* without needing to access the respective denomination key
* information each time.
*/
struct TALER_Amount amount_with_fee;
/**
* Blinded planchet.
*/
void *blinded_msg;
/**
* Number of bytes in @e blinded_msg.
*/
size_t blinded_msg_len;
struct TALER_BlindedPlanchet blinded_planchet;
/**
* Set to the resulting signed coin data to be returned to the client.
@ -148,9 +159,8 @@ withdraw_transaction (void *cls,
uint64_t ruuid;
now = GNUNET_TIME_timestamp_get ();
wc->collectable.reserve_pub = wc->wsrd.reserve_pub;
wc->collectable.h_coin_envelope = wc->wsrd.h_coin_envelope;
qs = TEH_plugin->do_withdraw (TEH_plugin->cls,
&wc->wih,
&wc->collectable,
now,
&found,
@ -178,7 +188,6 @@ withdraw_transaction (void *cls,
{
struct TALER_EXCHANGEDB_ReserveHistory *rh;
struct TALER_Amount balance;
struct TALER_Amount requested_amount;
TEH_plugin->rollback (TEH_plugin->cls);
// FIXME: maybe start read-committed here?
@ -197,7 +206,7 @@ withdraw_transaction (void *cls,
/* The reserve does not have the required amount (actual
* amount + withdraw fee) */
qs = TEH_plugin->get_reserve_history (TEH_plugin->cls,
&wc->wsrd.reserve_pub,
&wc->collectable.reserve_pub,
&balance,
&rh);
if (NULL == rh)
@ -209,11 +218,10 @@ withdraw_transaction (void *cls,
"reserve history");
return GNUNET_DB_STATUS_HARD_ERROR;
}
TALER_amount_ntoh (&requested_amount,
&wc->wsrd.amount_with_fee);
*mhd_ret = reply_withdraw_insufficient_funds (connection,
*mhd_ret = reply_withdraw_insufficient_funds (
connection,
&balance,
&requested_amount,
&wc->collectable.amount_with_fee,
rh);
TEH_plugin->free_reserve_history (TEH_plugin->cls,
rh);
@ -292,7 +300,7 @@ check_request_idempotent (struct TEH_RequestContext *rc,
enum GNUNET_DB_QueryStatus qs;
qs = TEH_plugin->get_withdraw_info (TEH_plugin->cls,
&wc->wsrd.h_coin_envelope,
&wc->wih,
&wc->collectable);
if (0 > qs)
{
@ -324,13 +332,12 @@ TEH_handler_withdraw (struct TEH_RequestContext *rc,
{
struct WithdrawContext wc;
struct GNUNET_JSON_Specification spec[] = {
GNUNET_JSON_spec_varsize ("coin_ev",
&wc.blinded_msg,
&wc.blinded_msg_len),
GNUNET_JSON_spec_fixed_auto ("reserve_sig",
&wc.collectable.reserve_sig),
GNUNET_JSON_spec_fixed_auto ("denom_pub_hash",
&wc.collectable.denom_pub_hash),
TALER_JSON_spec_blinded_planchet ("coin_ev",
&wc.blinded_planchet),
GNUNET_JSON_spec_end ()
};
enum TALER_ErrorCode ec;
@ -342,8 +349,8 @@ TEH_handler_withdraw (struct TEH_RequestContext *rc,
if (GNUNET_OK !=
GNUNET_STRINGS_string_to_data (args[0],
strlen (args[0]),
&wc.wsrd.reserve_pub,
sizeof (wc.wsrd.reserve_pub)))
&wc.collectable.reserve_pub,
sizeof (wc.collectable.reserve_pub)))
{
GNUNET_break_op (0);
return TALER_MHD_reply_with_error (rc->connection,
@ -444,6 +451,15 @@ TEH_handler_withdraw (struct TEH_RequestContext *rc,
GNUNET_JSON_parse_free (spec);
return mret;
}
if (dk->denom_pub.cipher != wc.blinded_planchet.cipher)
{
/* denomination cipher and blinded planchet cipher not the same */
GNUNET_JSON_parse_free (spec);
return TALER_MHD_reply_with_error (rc->connection,
MHD_HTTP_BAD_REQUEST,
TALER_EC_EXCHANGE_GENERIC_CIPHER_MISMATCH,
NULL);
}
}
if (0 >
@ -457,29 +473,28 @@ TEH_handler_withdraw (struct TEH_RequestContext *rc,
TALER_EC_EXCHANGE_WITHDRAW_AMOUNT_FEE_OVERFLOW,
NULL);
}
TALER_amount_hton (&wc.wsrd.amount_with_fee,
&wc.collectable.amount_with_fee);
// FIXME: move this logic into libtalerutil!
/* verify signature! */
wc.wsrd.purpose.size
= htonl (sizeof (wc.wsrd));
wc.wsrd.purpose.purpose
= htonl (TALER_SIGNATURE_WALLET_RESERVE_WITHDRAW);
wc.wsrd.h_denomination_pub
= wc.collectable.denom_pub_hash;
TALER_coin_ev_hash (wc.blinded_msg,
wc.blinded_msg_len,
&wc.wsrd.h_coin_envelope);
if (GNUNET_OK !=
GNUNET_CRYPTO_eddsa_verify (
TALER_SIGNATURE_WALLET_RESERVE_WITHDRAW,
&wc.wsrd,
&wc.collectable.reserve_sig.eddsa_signature,
&wc.wsrd.reserve_pub.eddsa_pub))
TALER_coin_ev_hash (&wc.blinded_planchet,
&wc.collectable.denom_pub_hash,
&wc.collectable.h_coin_envelope))
{
TALER_LOG_WARNING (
"Client supplied invalid signature for withdraw request\n");
GNUNET_break (0);
GNUNET_JSON_parse_free (spec);
return TALER_MHD_reply_with_error (rc->connection,
MHD_HTTP_INTERNAL_SERVER_ERROR,
TALER_EC_GENERIC_INTERNAL_INVARIANT_FAILURE,
NULL);
}
if (GNUNET_OK !=
TALER_wallet_withdraw_verify (&wc.collectable.denom_pub_hash,
&wc.collectable.amount_with_fee,
&wc.collectable.h_coin_envelope,
&wc.collectable.reserve_pub,
&wc.collectable.reserve_sig))
{
GNUNET_break_op (0);
GNUNET_JSON_parse_free (spec);
return TALER_MHD_reply_with_error (rc->connection,
MHD_HTTP_FORBIDDEN,
@ -487,13 +502,24 @@ TEH_handler_withdraw (struct TEH_RequestContext *rc,
NULL);
}
if (GNUNET_OK !=
TALER_withdraw_request_hash (&wc.blinded_planchet,
&wc.collectable.denom_pub_hash,
&wc.wih))
{
GNUNET_break (0);
GNUNET_JSON_parse_free (spec);
return TALER_MHD_reply_with_error (rc->connection,
MHD_HTTP_INTERNAL_SERVER_ERROR,
TALER_EC_GENERIC_INTERNAL_INVARIANT_FAILURE,
NULL);
}
/* Sign before transaction! */
ec = TALER_EC_NONE;
wc.collectable.sig
= TEH_keys_denomination_sign (&wc.collectable.denom_pub_hash,
wc.blinded_msg,
wc.blinded_msg_len,
&ec);
ec = TEH_keys_denomination_sign (
&wc.collectable.denom_pub_hash,
&wc.blinded_planchet,
&wc.collectable.sig);
if (TALER_EC_NONE != ec)
{
GNUNET_break (0);

42
src/exchange/test_taler_exchange_httpd.conf
View File

@ -70,7 +70,7 @@ PASSWORD = x
WIRE_GATEWAY_URL = "http://localhost:8082/3/"
# Coins for the tests.
[coin_eur_ct_1]
[coin_eur_ct_1_rsa]
value = EUR:0.01
duration_withdraw = 7 days
duration_spend = 2 years
@ -79,9 +79,21 @@ fee_withdraw = EUR:0.00
fee_deposit = EUR:0.00
fee_refresh = EUR:0.01
fee_refund = EUR:0.01
CIPHER = RSA
rsa_keysize = 1024
[coin_eur_ct_10]
[coin_eur_ct_1_cs]
value = EUR:0.01
duration_withdraw = 7 days
duration_spend = 2 years
duration_legal = 3 years
fee_withdraw = EUR:0.00
fee_deposit = EUR:0.00
fee_refresh = EUR:0.01
fee_refund = EUR:0.01
CIPHER = CS
[coin_eur_ct_10_rsa]
value = EUR:0.10
duration_withdraw = 7 days
duration_spend = 2 years
@ -90,9 +102,21 @@ fee_withdraw = EUR:0.01
fee_deposit = EUR:0.01
fee_refresh = EUR:0.03
fee_refund = EUR:0.01
CIPHER = RSA
rsa_keysize = 1024
[coin_eur_1]
[coin_eur_ct_10_cs]
value = EUR:0.10
duration_withdraw = 7 days
duration_spend = 2 years
duration_legal = 3 years
fee_withdraw = EUR:0.01
fee_deposit = EUR:0.01
fee_refresh = EUR:0.03
fee_refund = EUR:0.01
CIPHER = CS
[coin_eur_1_rsa]
value = EUR:1
duration_withdraw = 7 days
duration_spend = 2 years
@ -101,4 +125,16 @@ fee_withdraw = EUR:0.01
fee_deposit = EUR:0.01
fee_refresh = EUR:0.03
fee_refund = EUR:0.01
CIPHER = RSA
rsa_keysize = 1024
[coin_eur_1_cs]
value = EUR:1
duration_withdraw = 7 days
duration_spend = 2 years
duration_legal = 3 years
fee_withdraw = EUR:0.01
fee_deposit = EUR:0.01
fee_refresh = EUR:0.03
fee_refund = EUR:0.01
CIPHER = CS

42
src/exchange/test_taler_exchange_unix.conf
View File

@ -70,7 +70,7 @@ TALER_BANK_AUTH_METHOD = NONE
# Coins for the tests.
[coin_eur_ct_1]
[coin_eur_ct_1_rsa]
value = EUR:0.01
duration_withdraw = 7 days
duration_spend = 2 years
@ -79,9 +79,21 @@ fee_withdraw = EUR:0.00
fee_deposit = EUR:0.00
fee_refresh = EUR:0.01
fee_refund = EUR:0.01
CIPHER = RSA
rsa_keysize = 1024
[coin_eur_ct_10]
[coin_eur_ct_1_cs]
value = EUR:0.01
duration_withdraw = 7 days
duration_spend = 2 years
duration_legal = 3 years
fee_withdraw = EUR:0.00
fee_deposit = EUR:0.00
fee_refresh = EUR:0.01
fee_refund = EUR:0.01
CIPHER = CS
[coin_eur_ct_10_rsa]
value = EUR:0.10
duration_withdraw = 7 days
duration_spend = 2 years
@ -90,9 +102,21 @@ fee_withdraw = EUR:0.01
fee_deposit = EUR:0.01
fee_refresh = EUR:0.03
fee_refund = EUR:0.01
CIPHER = RSA
rsa_keysize = 1024
[coin_eur_1]
[coin_eur_ct_10_cs]
value = EUR:0.10
duration_withdraw = 7 days
duration_spend = 2 years
duration_legal = 3 years
fee_withdraw = EUR:0.01
fee_deposit = EUR:0.01
fee_refresh = EUR:0.03
fee_refund = EUR:0.01
CIPHER = CS
[coin_eur_1_rsa]
value = EUR:1
duration_withdraw = 7 days
duration_spend = 2 years
@ -101,4 +125,16 @@ fee_withdraw = EUR:0.01
fee_deposit = EUR:0.01
fee_refresh = EUR:0.03
fee_refund = EUR:0.01
CIPHER = RSA
rsa_keysize = 1024
[coin_eur_1_cs]
value = EUR:1
duration_withdraw = 7 days
duration_spend = 2 years
duration_legal = 3 years
fee_withdraw = EUR:0.01
fee_deposit = EUR:0.01
fee_refresh = EUR:0.03
fee_refund = EUR:0.01
CIPHER = CS

45
src/exchangedb/exchange-0001.sql
View File

@ -196,7 +196,8 @@ CREATE INDEX IF NOT EXISTS reserves_close_by_reserve_pub_index
CREATE TABLE IF NOT EXISTS reserves_out
(reserve_out_serial_id BIGSERIAL -- UNIQUE
,h_blind_ev BYTEA PRIMARY KEY CHECK (LENGTH(h_blind_ev)=64)
,wih BYTEA PRIMARY KEY CHECK (LENGTH(wih)=64)
,h_blind_ev BYTEA CHECK (LENGTH(h_blind_ev)=64) -- UNIQUE
,denominations_serial INT8 NOT NULL REFERENCES denominations (denominations_serial)
,denom_sig BYTEA NOT NULL
,reserve_uuid INT8 NOT NULL -- REFERENCES reserves (reserve_uuid) ON DELETE CASCADE
@ -205,9 +206,11 @@ CREATE TABLE IF NOT EXISTS reserves_out
,amount_with_fee_val INT8 NOT NULL
,amount_with_fee_frac INT4 NOT NULL
)
PARTITION BY HASH (h_blind_ev);
PARTITION BY HASH (wih);
COMMENT ON TABLE reserves_out
IS 'Withdraw operations performed on reserves.';
COMMENT ON COLUMN reserves_out.wih
IS 'Hash that uniquely identifies the withdraw request. Used to detect request replays (crucial for CS) and to check the withdraw existed during recoup.';
COMMENT ON COLUMN reserves_out.h_blind_ev
IS 'Hash of the blinded coin, used as primary key here so that broken clients that use a non-random coin or blinding factor fail to withdraw (otherwise they would fail on deposit when the coin is not unique there).';
COMMENT ON COLUMN reserves_out.denominations_serial
@ -380,6 +383,7 @@ CREATE TABLE IF NOT EXISTS refresh_revealed_coins
,coin_ev BYTEA NOT NULL -- UNIQUE
,h_coin_ev BYTEA NOT NULL CHECK(LENGTH(h_coin_ev)=64) -- UNIQUE
,ev_sig BYTEA NOT NULL
,ewv BYTEA NOT NULL
-- ,PRIMARY KEY (melt_serial_id, freshcoin_index) -- done per shard
)
PARTITION BY HASH (melt_serial_id);
@ -393,6 +397,8 @@ COMMENT ON COLUMN refresh_revealed_coins.freshcoin_index
IS 'index of the fresh coin being created (one melt operation may result in multiple fresh coins)';
COMMENT ON COLUMN refresh_revealed_coins.coin_ev
IS 'envelope of the new coin to be signed';
COMMENT ON COLUMN refresh_revealed_coins.ewv
IS 'exchange contributed values in the creation of the fresh coin (see /csr)';
COMMENT ON COLUMN refresh_revealed_coins.h_coin_ev
IS 'hash of the envelope of the new coin to be signed (for lookups)';
COMMENT ON COLUMN refresh_revealed_coins.ev_sig
@ -637,7 +643,7 @@ COMMENT ON TABLE recoup
COMMENT ON COLUMN recoup.known_coin_id
IS 'Coin that is being debited in the recoup. Do not CASCADE ON DROP on the coin_pub, as we may keep the coin alive!';
COMMENT ON COLUMN recoup.reserve_out_serial_id
IS 'Identifies the h_blind_ev of the recouped coin and provides the link to the credited reserve.';
IS 'Identifies the wih of the recouped coin and provides the link to the credited reserve.';
COMMENT ON COLUMN recoup.coin_sig
IS 'Signature by the coin affirming the recoup, of type TALER_SIGNATURE_WALLET_COIN_RECOUP';
COMMENT ON COLUMN recoup.coin_blind
@ -812,6 +818,7 @@ CREATE INDEX IF NOT EXISTS revolving_work_shards_by_job_name_active_last_attempt
CREATE OR REPLACE FUNCTION exchange_do_withdraw(
IN in_wih BYTEA,
IN amount_val INT8,
IN amount_frac INT4,
IN h_denom_pub BYTEA,
@ -825,7 +832,8 @@ CREATE OR REPLACE FUNCTION exchange_do_withdraw(
OUT balance_ok BOOLEAN,
OUT kycok BOOLEAN,
OUT account_uuid INT8,
OUT ruuid INT8)
OUT ruuid INT8,
OUT out_denom_sig BYTEA)
LANGUAGE plpgsql
AS $$
DECLARE
@ -838,7 +846,7 @@ DECLARE
reserve_frac INT4;
BEGIN
-- Shards: reserves by reserve_pub (SELECT)
-- reserves_out (INSERT, with CONFLICT detection) by h_blind_ev
-- reserves_out (INSERT, with CONFLICT detection) by wih
-- reserves by reserve_pub (UPDATE)
-- reserves_in by reserve_pub (SELECT)
-- wire_targets by wire_target_serial_id
@ -887,6 +895,7 @@ END IF;
-- the query successful due to idempotency.
INSERT INTO reserves_out
(h_blind_ev
,wih
,denominations_serial
,denom_sig
,reserve_uuid
@ -896,6 +905,7 @@ INSERT INTO reserves_out
,amount_with_fee_frac)
VALUES
(h_coin_envelope
,in_wih
,denom_serial
,denom_sig
,ruuid
@ -908,6 +918,25 @@ ON CONFLICT DO NOTHING;
IF NOT FOUND
THEN
-- idempotent query, all constraints must be satisfied
SELECT
denom_sig
INTO
out_denom_sig
FROM reserves_in
WHERE wih=in_wih
LIMIT 1; -- limit 1 should not be required (without p2p transfers)
IF NOT FOUND
THEN
reserve_found=FALSE;
balance_ok=FALSE;
kycok=FALSE;
account_uuid=0;
ruuid=0;
ASSERT false, 'internal logic error';
END IF;
reserve_found=TRUE;
balance_ok=TRUE;
kycok=TRUE;
@ -967,9 +996,13 @@ SELECT
WHERE reserve_pub=rpub
LIMIT 1; -- limit 1 should not be required (without p2p transfers)
-- Return denomination signature as result that
-- was given as the argument.
out_denom_sig=denom_sig;
END $$;
COMMENT ON FUNCTION exchange_do_withdraw(INT8, INT4, BYTEA, BYTEA, BYTEA, BYTEA, BYTEA, INT8, INT8)
COMMENT ON FUNCTION exchange_do_withdraw(BYTEA, INT8, INT4, BYTEA, BYTEA, BYTEA, BYTEA, BYTEA, INT8, INT8)
IS 'Checks whether the reserve has sufficient balance for a withdraw operation (or the request is repeated and was previously approved) and if so updates the database with the result';

12
src/exchangedb/exchangedb_transactions.c
View File

@ -22,17 +22,7 @@
#include "taler_exchangedb_lib.h"
/**
* Calculate the total value of all transactions performed.
* Stores @a off plus the cost of all transactions in @a tl
* in @a ret.
*
* @param tl transaction list to process
* @param off offset to use as the starting value
* @param[out] ret where the resulting total is to be stored (may alias @a off)
* @return #GNUNET_OK on success, #GNUNET_SYSERR on errors
*/
int
enum GNUNET_GenericReturnValue
TALER_EXCHANGEDB_calculate_transaction_list_totals (
struct TALER_EXCHANGEDB_TransactionList *tl,
const struct TALER_Amount *off,

2
src/exchangedb/irbt_callbacks.c
View File

@ -440,6 +440,8 @@ irbt_cb_table_refresh_revealed_coins (
GNUNET_PQ_query_param_auto_from_type (&h_coin_ev),
TALER_PQ_query_param_blinded_denom_sig (
&td->details.refresh_revealed_coins.ev_sig),
TALER_PQ_query_param_exchange_withdraw_values (
&td->details.refresh_revealed_coins.ewv),
GNUNET_PQ_query_param_uint64 (
&td->details.refresh_revealed_coins.denominations_serial),
GNUNET_PQ_query_param_uint64 (

3
src/exchangedb/lrbt_callbacks.c
View File

@ -790,6 +790,9 @@ lrbt_cb_table_refresh_revealed_coins (void *cls,
TALER_PQ_result_spec_blinded_denom_sig (
"ev_sig",
&td.details.refresh_revealed_coins.ev_sig),
TALER_PQ_result_spec_exchange_withdraw_values (
"ewv",
&td.details.refresh_revealed_coins.ewv),
GNUNET_PQ_result_spec_uint64 (
"denominations_serial",
&td.details.refresh_revealed_coins.denominations_serial),

153
src/exchangedb/plugin_exchangedb_postgres.c
View File

@ -564,13 +564,6 @@ prepare_statements (struct PostgresClosure *pg)
" ON (wire_source_serial_id = wire_target_serial_id)"
" WHERE reserve_pub=$1;",
1),
/* Lock withdraw table; NOTE: we may want to eventually shard the
deposit table to avoid this lock being the main point of
contention limiting transaction performance. */
GNUNET_PQ_make_prepare (
"lock_withdraw",
"LOCK TABLE reserves_out;",
0),
/* Used in #postgres_do_withdraw() to store
the signature of a blinded coin with the blinded coin's
details before returning it during /reserve/withdraw. We store
@ -586,9 +579,10 @@ prepare_statements (struct PostgresClosure *pg)
",kycok AS kyc_ok"
",account_uuid AS payment_target_uuid"
",ruuid"
",out_denom_sig"
" FROM exchange_do_withdraw"
" ($1,$2,$3,$4,$5,$6,$7,$8,$9);",
9),
" ($1,$2,$3,$4,$5,$6,$7,$8,$9,$10);",
10),
/* Used in #postgres_do_withdraw_limit_check() to check
if the withdrawals remain below the limit under which
KYC is not required. */
@ -663,6 +657,7 @@ prepare_statements (struct PostgresClosure *pg)
",reserve_sig"
",reserves.reserve_pub"
",execution_date"
",h_blind_ev"
",amount_with_fee_val"
",amount_with_fee_frac"
",denom.fee_withdraw_val"
@ -672,7 +667,7 @@ prepare_statements (struct PostgresClosure *pg)
" USING (reserve_uuid)"
" JOIN denominations denom"
" USING (denominations_serial)"
" WHERE h_blind_ev=$1;",
" WHERE wih=$1;",
1),
/* Used during #postgres_get_reserve_history() to
obtain all of the /reserve/withdraw operations that
@ -897,13 +892,14 @@ prepare_statements (struct PostgresClosure *pg)
",link_sig "
",denominations_serial "
",coin_ev"
",ewv"
",h_coin_ev"
",ev_sig"
") SELECT $1, $2, $3, "
" denominations_serial, $5, $6, $7"
" denominations_serial, $5, $6, $7, $8"
" FROM denominations"
" WHERE denom_pub_hash=$4;",
7),
8),
/* Obtain information about the coins created in a refresh
operation, used in #postgres_get_refresh_reveal() */
GNUNET_PQ_make_prepare (
@ -914,6 +910,7 @@ prepare_statements (struct PostgresClosure *pg)
",rrc.h_coin_ev"
",rrc.link_sig"
",rrc.coin_ev"
",rrc.ewv"
",rrc.ev_sig"
" FROM refresh_commitments"
" JOIN refresh_revealed_coins rrc"
@ -1219,7 +1216,10 @@ prepare_statements (struct PostgresClosure *pg)
" tp.transfer_pub"
",denoms.denom_pub"
",rrc.ev_sig"
",rrc.ewv"
",rrc.link_sig"
",rrc.freshcoin_index"
",rrc.coin_ev"
" FROM refresh_commitments"
" JOIN refresh_revealed_coins rrc"
" USING (melt_serial_id)"
@ -1672,16 +1672,16 @@ prepare_statements (struct PostgresClosure *pg)
" ON (denoms.denominations_serial = coins.denominations_serial)"
" WHERE coins.coin_pub=$1;",
1),
/* Used in #postgres_get_reserve_by_h_blind() */
/* Used in #postgres_get_reserve_by_wih() */
GNUNET_PQ_make_prepare (
"reserve_by_h_blind",
"reserve_by_wih",
"SELECT"
" reserves.reserve_pub"
",reserve_out_serial_id"
" FROM reserves_out"
" JOIN reserves"
" USING (reserve_uuid)"
" WHERE h_blind_ev=$1"
" WHERE wih=$1"
" LIMIT 1;",
1),
/* Used in #postgres_get_old_coin_by_h_blind() */
@ -2248,6 +2248,7 @@ prepare_statements (struct PostgresClosure *pg)
",link_sig"
",coin_ev"
",ev_sig"
",ewv"
",denominations_serial"
",melt_serial_id"
" FROM refresh_revealed_coins"
@ -2540,11 +2541,12 @@ prepare_statements (struct PostgresClosure *pg)
",coin_ev"
",h_coin_ev"
",ev_sig"
",ewv"
",denominations_serial"
",melt_serial_id"
") VALUES "
"($1, $2, $3, $4, $5, $6, $7, $8);",
8),
"($1, $2, $3, $4, $5, $6, $7, $8, $9);",
9),
GNUNET_PQ_make_prepare (
"insert_into_table_refresh_transfer_keys",
"INSERT INTO refresh_transfer_keys"
@ -3903,9 +3905,8 @@ postgres_select_kyc_status (void *cls,
* Get the KYC status for a wallet. If the status is unknown,
* inserts a new status record (hence INsertSELECT).
*
* @param cls the @e cls of this struct with the plugin-specific state
* @param pg the plugin-specific state
* @param payto_uri the payto URI to check
* @param oauth_username user ID to store
* @param[out] kyc set to the KYC status of the wallet
* @return transaction status
*/
@ -4327,8 +4328,7 @@ postgres_reserves_in_insert (void *cls,
* key of the hash of the blinded message.
*
* @param cls the `struct PostgresClosure` with the plugin-specific state
* @param h_blind hash of the blinded coin to be signed (will match
* `h_coin_envelope` in the @a collectable to be returned)
* @param wih hash that uniquely identifies the withdraw operation
* @param collectable corresponding collectable coin (blind signature)
* if a coin is found
* @return statement execution status
@ -4336,12 +4336,12 @@ postgres_reserves_in_insert (void *cls,
static enum GNUNET_DB_QueryStatus
postgres_get_withdraw_info (
void *cls,
const struct TALER_BlindedCoinHash *h_blind,
const struct TALER_WithdrawIdentificationHash *wih,
struct TALER_EXCHANGEDB_CollectableBlindcoin *collectable)
{
struct PostgresClosure *pg = cls;
struct GNUNET_PQ_QueryParam params[] = {
GNUNET_PQ_query_param_auto_from_type (h_blind),
GNUNET_PQ_query_param_auto_from_type (wih),
GNUNET_PQ_query_param_end
};
struct GNUNET_PQ_ResultSpec rs[] = {
@ -4353,24 +4353,15 @@ postgres_get_withdraw_info (
&collectable->reserve_sig),
GNUNET_PQ_result_spec_auto_from_type ("reserve_pub",
&collectable->reserve_pub),
GNUNET_PQ_result_spec_auto_from_type ("h_blind_ev",
&collectable->h_coin_envelope),
TALER_PQ_RESULT_SPEC_AMOUNT ("amount_with_fee",
&collectable->amount_with_fee),
TALER_PQ_RESULT_SPEC_AMOUNT ("fee_withdraw",
&collectable->withdraw_fee),
GNUNET_PQ_result_spec_end
};
#if EXPLICIT_LOCKS
struct GNUNET_PQ_QueryParam no_params[] = {
GNUNET_PQ_query_param_end
};
enum GNUNET_DB_QueryStatus qs;
if (0 > (qs = GNUNET_PQ_eval_prepared_non_select (pg->conn,
"lock_withdraw",
no_params)))
return qs;
#endif
collectable->h_coin_envelope = *h_blind;
return GNUNET_PQ_eval_prepared_singleton_select (pg->conn,
"get_withdraw_info",
params,
@ -4383,19 +4374,20 @@ postgres_get_withdraw_info (
* and possibly persisting the withdrawal details.
*
* @param cls the `struct PostgresClosure` with the plugin-specific state
* @param collectable corresponding collectable coin (blind signature)
* if a coin is found
* @param wih hash that uniquely identifies the withdraw operation
* @param[in,out] collectable corresponding collectable coin (blind signature) if a coin is found; possibly updated if a (different) signature exists already
* @param now current time (rounded)
* @param[out] found set to true if the reserve was found
* @param[out] balance_ok set to true if the balance was sufficient
* @param[out] kyc_ok set to true if the kyc status of the reserve is satisfied
* @param[out] kyc set to true if the kyc status of the reserve is satisfied
* @param[out] ruuid set to the reserve's UUID (reserves table row)
* @return query execution status
*/
static enum GNUNET_DB_QueryStatus
postgres_do_withdraw (
void *cls,
const struct TALER_EXCHANGEDB_CollectableBlindcoin *collectable,
const struct TALER_WithdrawIdentificationHash *wih,
struct TALER_EXCHANGEDB_CollectableBlindcoin *collectable,
struct GNUNET_TIME_Timestamp now,
bool *found,
bool *balance_ok,
@ -4405,6 +4397,7 @@ postgres_do_withdraw (
struct PostgresClosure *pg = cls;
struct GNUNET_TIME_Timestamp gc;
struct GNUNET_PQ_QueryParam params[] = {
GNUNET_PQ_query_param_auto_from_type (wih),
TALER_PQ_query_param_amount (&collectable->amount_with_fee),
GNUNET_PQ_query_param_auto_from_type (&collectable->denom_pub_hash),
GNUNET_PQ_query_param_auto_from_type (&collectable->reserve_pub),
@ -4415,6 +4408,9 @@ postgres_do_withdraw (
GNUNET_PQ_query_param_timestamp (&gc),
GNUNET_PQ_query_param_end
};
enum GNUNET_DB_QueryStatus qs;
bool no_out_sig;
struct TALER_BlindedDenominationSignature out_sig;
struct GNUNET_PQ_ResultSpec rs[] = {
GNUNET_PQ_result_spec_bool ("reserve_found",
found),
@ -4426,18 +4422,33 @@ postgres_do_withdraw (
&kyc->payment_target_uuid),
GNUNET_PQ_result_spec_uint64 ("ruuid",
ruuid),
GNUNET_PQ_result_spec_allow_null (
TALER_PQ_result_spec_blinded_denom_sig ("out_denom_sig",
&out_sig),
&no_out_sig),
GNUNET_PQ_result_spec_end
};
#if 0
memset (&out_sig,
0,
sizeof (out_sig));
#endif
gc = GNUNET_TIME_absolute_to_timestamp (
GNUNET_TIME_absolute_add (now.abs_time,
pg->legal_reserve_expiration_time));
kyc->type = TALER_EXCHANGEDB_KYC_WITHDRAW;
return GNUNET_PQ_eval_prepared_singleton_select (pg->conn,
qs = GNUNET_PQ_eval_prepared_singleton_select (pg->conn,
"call_withdraw",
params,
rs);
if ( (GNUNET_DB_STATUS_SUCCESS_ONE_RESULT == qs) &&
(! no_out_sig) )
{
TALER_blinded_denom_sig_free (&collectable->sig);
collectable->sig = out_sig;
}
return qs;
}
@ -4481,9 +4492,9 @@ postgres_do_withdraw_limit_check (
/**
* Compute the shard number of a given @a deposit
* Compute the shard number of a given @a merchant_pub.
*
* @param deposit deposit to compute shard for
* @param merchant_pub merchant public key to compute shard for
* @return shard number
*/
static uint64_t
@ -4513,11 +4524,11 @@ compute_shard (const struct TALER_MerchantPublicKeyP *merchant_pub)
* Perform deposit operation, checking for sufficient balance
* of the coin and possibly persisting the deposit details.
*
* FIXME: parameters missing in description!
*
* @param cls the `struct PostgresClosure` with the plugin-specific state
* @param deposit deposit operation details
* @param known_coin_id row of the coin in the known_coins table
* @param h_payto hash of the merchant's bank account details
* @param extension_blocked true if an extension is blocking the wire transfer
* @param[in,out] exchange_timestamp time to use for the deposit (possibly updated)
* @param[out] balance_ok set to true if the balance was sufficient
* @param[out] in_conflict set to true if the deposit conflicted
@ -6136,8 +6147,8 @@ postgres_insert_refresh_reveal (
GNUNET_PQ_query_param_uint32 (&i),
GNUNET_PQ_query_param_auto_from_type (&rrc->orig_coin_link_sig),
GNUNET_PQ_query_param_auto_from_type (&rrc->h_denom_pub),
GNUNET_PQ_query_param_fixed_size (rrc->coin_ev,
rrc->coin_ev_size),
TALER_PQ_query_param_blinded_planchet (&rrc->blinded_planchet),
TALER_PQ_query_param_exchange_withdraw_values (&rrc->exchange_vals),
GNUNET_PQ_query_param_auto_from_type (&rrc->coin_envelope_hash),
TALER_PQ_query_param_blinded_denom_sig (&rrc->coin_sig),
GNUNET_PQ_query_param_end
@ -6244,15 +6255,16 @@ add_revealed_coins (void *cls,
&rrc->orig_coin_link_sig),
GNUNET_PQ_result_spec_auto_from_type ("h_coin_ev",
&rrc->coin_envelope_hash),
GNUNET_PQ_result_spec_variable_size ("coin_ev",
(void **) &rrc->coin_ev,
&rrc->coin_ev_size),
TALER_PQ_result_spec_blinded_planchet ("coin_ev",
&rrc->blinded_planchet),
TALER_PQ_result_spec_exchange_withdraw_values ("ewv",
&rrc->exchange_vals),
TALER_PQ_result_spec_blinded_denom_sig ("ev_sig",
&rrc->coin_sig),
GNUNET_PQ_result_spec_end
};
if (NULL != rrc->coin_ev)
if (TALER_DENOMINATION_INVALID != rrc->blinded_planchet.cipher)
{
/* duplicate offset, not allowed */
GNUNET_break (0);
@ -6335,10 +6347,9 @@ cleanup:
struct TALER_EXCHANGEDB_RefreshRevealedCoin *rrc = &grctx.rrcs[i];
TALER_blinded_denom_sig_free (&rrc->coin_sig);
GNUNET_free (rrc->coin_ev);
TALER_blinded_planchet_free (&rrc->blinded_planchet);
}
GNUNET_free (grctx.rrcs);
return qs;
}
@ -6422,6 +6433,7 @@ add_ldl (void *cls,
pos = GNUNET_new (struct TALER_EXCHANGEDB_LinkList);
{
struct TALER_BlindedPlanchet bp;
struct GNUNET_PQ_ResultSpec rs[] = {
GNUNET_PQ_result_spec_auto_from_type ("transfer_pub",
&transfer_pub),
@ -6429,8 +6441,14 @@ add_ldl (void *cls,
&pos->orig_coin_link_sig),
TALER_PQ_result_spec_blinded_denom_sig ("ev_sig",
&pos->ev_sig),
GNUNET_PQ_result_spec_uint32 ("freshcoin_index",
&pos->coin_refresh_offset),
TALER_PQ_result_spec_exchange_withdraw_values ("ewv",
&pos->alg_values),
TALER_PQ_result_spec_denom_pub ("denom_pub",
&pos->denom_pub),
TALER_PQ_result_spec_blinded_planchet ("coin_ev",
&bp),
GNUNET_PQ_result_spec_end
};
@ -6444,6 +6462,12 @@ add_ldl (void *cls,
ldctx->status = GNUNET_SYSERR;
return;
}
if (TALER_DENOMINATION_CS == bp.cipher)
{
pos->nonce = bp.details.cs_blinded_planchet.nonce;
pos->have_nonce = true;
}
TALER_blinded_planchet_free (&bp);
}
if ( (NULL != ldctx->last) &&
(0 == GNUNET_memcmp (&transfer_pub,
@ -7223,11 +7247,10 @@ postgres_lookup_wire_transfer (
* @param merchant_pub merchant public key
* @param[out] pending set to true if the transaction is still pending
* @param[out] wtid wire transfer identifier, only set if @a pending is false
* @param[out] coin_contribution how much did the coin we asked about
* contribute to the total transfer value? (deposit value including fee)
* @param[out] coin_fee how much did the exchange charge for the deposit fee
* @param[out] execution_time when was the transaction done, or
* @param[out] exec_time when was the transaction done, or
* when we expect it to be done (if @a pending is false)
* @param[out] amount_with_fee set to the total deposited amount
* @param[out] deposit_fee set to how much the exchange did charge for the deposit
* @param[out] kyc set to the kyc status of the receiver (if @a pending)
* @return transaction status code
*/
@ -7254,7 +7277,7 @@ postgres_lookup_transfer_by_deposit (
GNUNET_PQ_query_param_end
};
char *payto_uri;
struct TALER_WireSalt wire_salt;
struct TALER_WireSaltP wire_salt;
struct GNUNET_PQ_ResultSpec rs[] = {
GNUNET_PQ_result_spec_auto_from_type ("wtid_raw",
wtid),
@ -9405,20 +9428,21 @@ postgres_select_reserve_closed_above_serial_id (
* from given the hash of the blinded coin.
*
* @param cls closure
* @param h_blind_ev hash of the blinded coin
* @param wih hash that uniquely identifies the withdraw request
* @param[out] reserve_pub set to information about the reserve (on success only)
* @param[out] reserve_out_serial_id set to row of the @a h_blind_ev in reserves_out
* @return transaction status code
*/
static enum GNUNET_DB_QueryStatus
postgres_get_reserve_by_h_blind (void *cls,
const struct TALER_BlindedCoinHash *h_blind_ev,
postgres_get_reserve_by_wih (
void *cls,
const struct TALER_WithdrawIdentificationHash *wih,
struct TALER_ReservePublicKeyP *reserve_pub,
uint64_t *reserve_out_serial_id)
{
struct PostgresClosure *pg = cls;
struct GNUNET_PQ_QueryParam params[] = {
GNUNET_PQ_query_param_auto_from_type (h_blind_ev),
GNUNET_PQ_query_param_auto_from_type (wih),
GNUNET_PQ_query_param_end
};
struct GNUNET_PQ_ResultSpec rs[] = {
@ -9430,7 +9454,7 @@ postgres_get_reserve_by_h_blind (void *cls,
};
return GNUNET_PQ_eval_prepared_singleton_select (pg->conn,
"reserve_by_h_blind",
"reserve_by_wih",
params,
rs);
}
@ -9443,6 +9467,7 @@ postgres_get_reserve_by_h_blind (void *cls,
* @param cls closure
* @param h_blind_ev hash of the blinded coin
* @param[out] old_coin_pub set to information about the old coin (on success only)
* @param[out] rrc_serial set to serial number of the entry in the database
* @return transaction status code
*/
static enum GNUNET_DB_QueryStatus
@ -11697,8 +11722,8 @@ libtaler_plugin_exchangedb_postgres_init (void *cls)
= &postgres_select_recoup_refresh_above_serial_id;
plugin->select_reserve_closed_above_serial_id
= &postgres_select_reserve_closed_above_serial_id;
plugin->get_reserve_by_h_blind
= &postgres_get_reserve_by_h_blind;
plugin->get_reserve_by_wih
= &postgres_get_reserve_by_wih;
plugin->get_old_coin_by_h_blind
= &postgres_get_old_coin_by_h_blind;
plugin->insert_denomination_revocation

105
src/exchangedb/test_exchangedb.c
View File

@ -1,6 +1,6 @@
/*
This file is part of TALER
Copyright (C) 2014-2021 Taler Systems SA
Copyright (C) 2014-2022 Taler Systems SA
TALER is free software; you can redistribute it and/or modify it under the
terms of the GNU General Public License as published by the Free Software
@ -433,10 +433,9 @@ check_refresh_reveal_cb (
&revealed_coins[cnt];
const struct TALER_EXCHANGEDB_RefreshRevealedCoin *bcoin = &rrcs[cnt];
GNUNET_assert (acoin->coin_ev_size == bcoin->coin_ev_size);
GNUNET_assert (0 ==
GNUNET_memcmp (acoin->coin_ev,
bcoin->coin_ev));
TALER_blinded_planchet_cmp (&acoin->blinded_planchet,
&bcoin->blinded_planchet));
GNUNET_assert (0 ==
GNUNET_memcmp (&acoin->h_denom_pub,
&bcoin->h_denom_pub));
@ -534,7 +533,7 @@ handle_link_data_cb (void *cls,
break;
}
}
GNUNET_assert (found);
GNUNET_assert (GNUNET_NO != found);
}
}
@ -1348,15 +1347,22 @@ run (void *cls)
unsigned int cnt;
enum GNUNET_DB_QueryStatus qs;
struct GNUNET_TIME_Timestamp now;
struct TALER_WireSalt salt;
union TALER_DenominationBlindingKeyP bks;
struct TALER_WireSaltP salt;
struct TALER_CoinPubHash c_hash;
struct TALER_WithdrawIdentificationHash wih;
uint64_t known_coin_id;
uint64_t rrc_serial;
struct TALER_EXCHANGEDB_Refresh refresh;
struct TALER_DenominationPublicKey *new_denom_pubs = NULL;
uint64_t reserve_out_serial_id;
uint64_t melt_serial_id;
struct TALER_PlanchetMasterSecretP ps;
union TALER_DenominationBlindingKeyP bks;
struct TALER_ExchangeWithdrawValues alg_values = {
/* RSA is simpler, and for the DB there is no real difference between
CS and RSA, just one should be used, so we use RSA */
.cipher = TALER_DENOMINATION_RSA
};
memset (&deposit,
0,
@ -1381,7 +1387,7 @@ run (void *cls)
plugin->create_tables (plugin->cls))
{
result = 77;
goto drop;
goto cleanup;
}
plugin->preflight (plugin->cls);
FAILIF (GNUNET_OK !=
@ -1418,7 +1424,6 @@ run (void *cls)
GNUNET_assert (GNUNET_OK ==
TALER_string_to_amount (CURRENCY ":1.000010",
&amount_with_fee));
result = 4;
now = GNUNET_TIME_timestamp_get ();
FAILIF (GNUNET_DB_STATUS_SUCCESS_ONE_RESULT !=
@ -1467,11 +1472,17 @@ run (void *cls)
TALER_denom_pub_hash (&dkp->pub,
&cbc.denom_pub_hash);
RND_BLK (&cbc.reserve_sig);
TALER_planchet_blinding_secret_create (&ps,
&alg_values,
&bks);
{
struct TALER_PlanchetDetail pd;
struct TALER_CoinSpendPublicKeyP coin_pub;
struct TALER_AgeCommitmentHash age_hash;
struct TALER_AgeCommitmentHash *p_ah[2] = {NULL, &age_hash};
struct TALER_AgeCommitmentHash *p_ah[2] = {
NULL,
&age_hash
};
/* Call TALER_denom_blind()/TALER_denom_sign_blinded() twice, once without
* age_hash, once with age_hash */
@ -1479,24 +1490,28 @@ run (void *cls)
for (size_t i = 0; i < sizeof(p_ah) / sizeof(p_ah[0]); i++)
{
RND_BLK (&coin_pub);
TALER_blinding_secret_create (&bks);
GNUNET_assert (GNUNET_OK ==
TALER_denom_blind (&dkp->pub,
&bks,
p_ah[i],
&coin_pub,
&alg_values,
&c_hash,
&pd.coin_ev,
&pd.coin_ev_size));
TALER_coin_ev_hash (pd.coin_ev,
pd.coin_ev_size,
&cbc.h_coin_envelope);
&pd.blinded_planchet));
GNUNET_assert (GNUNET_OK ==
TALER_denom_sign_blinded (&cbc.sig,
TALER_coin_ev_hash (&pd.blinded_planchet,
&cbc.denom_pub_hash,
&cbc.h_coin_envelope));
GNUNET_assert (GNUNET_OK ==
TALER_withdraw_request_hash (&pd.blinded_planchet,
&cbc.denom_pub_hash,
&wih)); GNUNET_assert (
GNUNET_OK ==
TALER_denom_sign_blinded (
&cbc.sig,
&dkp->priv,
pd.coin_ev,
pd.coin_ev_size));
GNUNET_free (pd.coin_ev);
&pd.blinded_planchet));
TALER_blinded_planchet_free (&pd.blinded_planchet);
}
}
@ -1505,6 +1520,7 @@ run (void *cls)
GNUNET_assert (GNUNET_OK ==
TALER_amount_set_zero (CURRENCY,
&cbc.withdraw_fee));
{
bool found;
bool balance_ok;
@ -1513,6 +1529,7 @@ run (void *cls)
FAILIF (GNUNET_DB_STATUS_SUCCESS_ONE_RESULT !=
plugin->do_withdraw (plugin->cls,
&wih,
&cbc,
now,
&found,
@ -1534,8 +1551,8 @@ run (void *cls)
value.fraction,
value.currency));
FAILIF (GNUNET_DB_STATUS_SUCCESS_ONE_RESULT !=
plugin->get_reserve_by_h_blind (plugin->cls,
&cbc.h_coin_envelope,
plugin->get_reserve_by_wih (plugin->cls,
&wih,
&reserve_pub3,
&reserve_out_serial_id));
FAILIF (0 != GNUNET_memcmp (&reserve_pub,
@ -1543,7 +1560,7 @@ run (void *cls)
FAILIF (GNUNET_DB_STATUS_SUCCESS_ONE_RESULT !=
plugin->get_withdraw_info (plugin->cls,
&cbc.h_coin_envelope,
&wih,
&cbc2));
FAILIF (0 != GNUNET_memcmp (&cbc2.reserve_sig,
&cbc.reserve_sig));
@ -1558,6 +1575,8 @@ run (void *cls)
TALER_denom_sig_unblind (&ds,
&cbc2.sig,
&bks,
&c_hash,
&alg_values,
&dkp->pub));
FAILIF (GNUNET_OK !=
TALER_denom_pub_verify (&dkp->pub,
@ -1575,6 +1594,8 @@ run (void *cls)
TALER_denom_sig_unblind (&deposit.coin.denom_sig,
&cbc.sig,
&bks,
&c_hash,
&alg_values,
&dkp->pub));
deadline = GNUNET_TIME_timestamp_get ();
{
@ -1727,6 +1748,8 @@ run (void *cls)
{
struct TALER_EXCHANGEDB_RefreshRevealedCoin *ccoin;
struct GNUNET_TIME_Timestamp now;
struct TALER_BlindedRsaPlanchet *rp;
struct TALER_BlindedPlanchet *bp;
now = GNUNET_TIME_timestamp_get ();
new_dkp[cnt] = create_denom_key_pair (RSA_KEY_SIZE,
@ -1739,23 +1762,26 @@ run (void *cls)
GNUNET_assert (NULL != new_dkp[cnt]);
new_denom_pubs[cnt] = new_dkp[cnt]->pub;
ccoin = &revealed_coins[cnt];
ccoin->coin_ev_size = 1 + (size_t) GNUNET_CRYPTO_random_u64 (
bp = &ccoin->blinded_planchet;
bp->cipher = TALER_DENOMINATION_RSA;
rp = &bp->details.rsa_blinded_planchet;
rp->blinded_msg_size = 1 + (size_t) GNUNET_CRYPTO_random_u64 (
GNUNET_CRYPTO_QUALITY_WEAK,
(RSA_KEY_SIZE / 8) - 1);
ccoin->coin_ev = GNUNET_malloc (ccoin->coin_ev_size);
rp->blinded_msg = GNUNET_malloc (rp->blinded_msg_size);
GNUNET_CRYPTO_random_block (GNUNET_CRYPTO_QUALITY_WEAK,
ccoin->coin_ev,
ccoin->coin_ev_size);
GNUNET_CRYPTO_hash (ccoin->coin_ev,
ccoin->coin_ev_size,
&ccoin->coin_envelope_hash.hash);
rp->blinded_msg,
rp->blinded_msg_size);
TALER_denom_pub_hash (&new_dkp[cnt]->pub,
&ccoin->h_denom_pub);
ccoin->exchange_vals = alg_values;
TALER_coin_ev_hash (bp,
&ccoin->h_denom_pub,
&ccoin->coin_envelope_hash);
GNUNET_assert (GNUNET_OK ==
TALER_denom_sign_blinded (&ccoin->coin_sig,
&new_dkp[cnt]->priv,
ccoin->coin_ev,
ccoin->coin_ev_size));
bp));
}
RND_BLK (&tprivs);
RND_BLK (&tpub);
@ -1775,11 +1801,13 @@ run (void *cls)
{
struct TALER_BlindedCoinHash h_coin_ev;
struct TALER_CoinSpendPublicKeyP ocp;
struct TALER_DenominationHash denom_hash;
GNUNET_CRYPTO_hash (revealed_coins[0].coin_ev,
revealed_coins[0].coin_ev_size,
&h_coin_ev.hash);
TALER_denom_pub_hash (&new_denom_pubs[0],
&denom_hash);
TALER_coin_ev_hash (&revealed_coins[0].blinded_planchet,
&denom_hash,
&h_coin_ev);
FAILIF (GNUNET_DB_STATUS_SUCCESS_ONE_RESULT !=
plugin->get_old_coin_by_h_blind (plugin->cls,
&h_coin_ev,
@ -2154,6 +2182,8 @@ run (void *cls)
TALER_denom_sig_unblind (&deposit.coin.denom_sig,
&cbc.sig,
&bks,
&c_hash,
&alg_values,
&dkp->pub));
RND_BLK (&deposit.csig);
RND_BLK (&deposit.merchant_pub);
@ -2381,6 +2411,7 @@ drop:
rh = NULL;
GNUNET_break (GNUNET_OK ==
plugin->drop_tables (plugin->cls));
cleanup:
if (NULL != dkp)
destroy_denom_key_pair (dkp);
if (NULL != revealed_coins)
@ -2388,7 +2419,7 @@ drop:
for (unsigned int cnt = 0; cnt < MELT_NEW_COINS; cnt++)
{
TALER_blinded_denom_sig_free (&revealed_coins[cnt].coin_sig);
GNUNET_free (revealed_coins[cnt].coin_ev);
TALER_blinded_planchet_free (&revealed_coins[cnt].blinded_planchet);
}
GNUNET_free (revealed_coins);
revealed_coins = NULL;

2
src/include/taler_auditor_service.h
View File

@ -259,7 +259,7 @@ TALER_AUDITOR_deposit_confirmation (
const struct TALER_MerchantWireHash *h_wire,
const struct TALER_ExtensionContractHash *h_extensions,
const struct TALER_PrivateContractHash *h_contract_terms,
struct GNUNET_TIME_Timestamp timestamp,
struct GNUNET_TIME_Timestamp exchange_timestamp,
struct GNUNET_TIME_Timestamp wire_deadline,
struct GNUNET_TIME_Timestamp refund_deadline,
const struct TALER_Amount *amount_without_fee,

836
src/include/taler_crypto_lib.h
View File

File diff suppressed because it is too large Load Diff

521
src/include/taler_exchange_service.h
View File

@ -1,6 +1,6 @@
/*
This file is part of TALER
Copyright (C) 2014-2021 Taler Systems SA
Copyright (C) 2014-2022 Taler Systems SA
TALER is free software; you can redistribute it and/or modify it under the
terms of the GNU Affero General Public License as published by the Free Software
@ -919,7 +919,7 @@ TALER_EXCHANGE_deposit (
const struct TALER_Amount *amount,
struct GNUNET_TIME_Timestamp wire_deadline,
const char *merchant_payto_uri,
const struct TALER_WireSalt *wire_salt,
const struct TALER_WireSaltP *wire_salt,
const struct TALER_PrivateContractHash *h_contract_terms,
const struct TALER_AgeCommitmentHash *h_age_commitment,
const json_t *extension_details,
@ -1031,6 +1031,119 @@ void
TALER_EXCHANGE_refund_cancel (struct TALER_EXCHANGE_RefundHandle *refund);
/* ********************* POST /csr *********************** */
/**
* @brief A /csr Handle
*/
struct TALER_EXCHANGE_CsRHandle;
/**
* Details about a response for a CS R request.
*/
struct TALER_EXCHANGE_CsRResponse
{
/**
* HTTP response data.
*/
struct TALER_EXCHANGE_HttpResponse hr;
/**
* Details about the response.
*/
union
{
/**
* Details if the status is #MHD_HTTP_OK.
*/
struct
{
/**
* Length of the @e alg_values array.
*/
unsigned int alg_values_len;
/**
* Values contributed by the exchange for the
* respective coin's withdraw operation.
*/
const struct TALER_ExchangeWithdrawValues *alg_values;
} success;
/**
* Details if the status is #MHD_HTTP_GONE.
*/
struct
{
/* TODO: returning full details is not implemented */
} gone;
} details;
};
/**
* Callbacks of this type are used to serve the result of submitting a
* CS R request to a exchange.
*
* @param cls closure
* @param csrr response details
*/
typedef void
(*TALER_EXCHANGE_CsRCallback) (void *cls,
const struct TALER_EXCHANGE_CsRResponse *csrr);
/**
* Information we pass per coin to a /csr request.
*/
struct TALER_EXCHANGE_NonceKey
{
/**
* Which denomination key is the /csr request for?
*/
const struct TALER_EXCHANGE_DenomPublicKey *pk;
/**
* What is the client nonce for the request?
*/
struct TALER_CsNonce nonce;
};
/**
* Get a CS R using a /csr request.
*
* @param exchange the exchange handle; the exchange must be ready to operate
* @param nks_len length of the @a nks array
* @param nks array of denominations and nonces
* @param res_cb the callback to call when the final result for this request is available
* @param res_cb_cls closure for the above callback
* @return handle for the operation on success, NULL on error, i.e.
* if the inputs are invalid (i.e. denomination key not with this exchange).
* In this case, the callback is not called.
*/
struct TALER_EXCHANGE_CsRHandle *
TALER_EXCHANGE_csr (struct TALER_EXCHANGE_Handle *exchange,
unsigned int nks_len,
struct TALER_EXCHANGE_NonceKey *nks,
TALER_EXCHANGE_CsRCallback res_cb,
void *res_cb_cls);
/**
*
* Cancel a CS R request. This function cannot be used
* on a request handle if a response is already served for it.
*
* @param csrh the withdraw handle
*/
void
TALER_EXCHANGE_csr_cancel (struct TALER_EXCHANGE_CsRHandle *csrh);
/* ********************* GET /reserves/$RESERVE_PUB *********************** */
@ -1271,6 +1384,36 @@ TALER_EXCHANGE_reserves_get_cancel (
struct TALER_EXCHANGE_WithdrawHandle;
/**
* All the details about a coin that are generated during withdrawal and that
* may be needed for future operations on the coin.
*/
struct TALER_EXCHANGE_PrivateCoinDetails
{
/**
* Private key of the coin.
*/
struct TALER_CoinSpendPrivateKeyP coin_priv;
/**
* Value used to blind the key for the signature.
* Needed for recoup operations.
*/
union TALER_DenominationBlindingKeyP bks;
/**
* Signature over the coin.
*/
struct TALER_DenominationSignature sig;
/**
* Values contributed from the exchange during the
* withdraw protocol.
*/
struct TALER_ExchangeWithdrawValues exchange_vals;
};
/**
* Details about a response for a withdraw request.
*/
@ -1289,13 +1432,7 @@ struct TALER_EXCHANGE_WithdrawResponse
/**
* Details if the status is #MHD_HTTP_OK.
*/
struct
{
/**
* Signature over the coin.
*/
struct TALER_DenominationSignature sig;
} success;
struct TALER_EXCHANGE_PrivateCoinDetails success;
/**
* Details if the status is #MHD_HTTP_ACCEPTED.
@ -1357,7 +1494,7 @@ typedef void
* @param reserve_priv private key of the reserve to withdraw from
* @param ps secrets of the planchet
* caller must have committed this value to disk before the call (with @a pk)
* @param ach (optional) hash of the age commitment that should be bound to this coin. Maybe NULL.
* @param ach hash of the age commitment that should be bound to this coin. Maybe NULL.
* @param res_cb the callback to call when the final result for this request is available
* @param res_cb_cls closure for @a res_cb
* @return NULL
@ -1369,7 +1506,7 @@ TALER_EXCHANGE_withdraw (
struct TALER_EXCHANGE_Handle *exchange,
const struct TALER_EXCHANGE_DenomPublicKey *pk,
const struct TALER_ReservePrivateKeyP *reserve_priv,
const struct TALER_PlanchetSecretsP *ps,
const struct TALER_PlanchetMasterSecretP *ps,
const struct TALER_AgeCommitmentHash *ach,
TALER_EXCHANGE_WithdrawCallback res_cb,
void *res_cb_cls);
@ -1451,53 +1588,45 @@ TALER_EXCHANGE_withdraw2_cancel (struct TALER_EXCHANGE_Withdraw2Handle *wh);
/**
* Melt (partially spent) coins to obtain fresh coins that are
* unlinkable to the original coin(s). Note that melting more
* than one coin in a single request will make those coins linkable,
* so the safest operation only melts one coin at a time.
*
* This API is typically used by a wallet. Note that to ensure that
* no money is lost in case of hardware failures, is operation does
* not actually initiate the request. Instead, it generates a buffer
* which the caller must store before proceeding with the actual call
* to #TALER_EXCHANGE_melt() that will generate the request.
*
* This function does verify that the given request data is internally
* consistent. However, the @a melts_sigs are NOT verified.
*
* Aside from some non-trivial cryptographic operations that might
* take a bit of CPU time to complete, this function returns
* its result immediately and does not start any asynchronous
* processing. This function is also thread-safe.
*
* @param melt_priv private keys of the coin to melt
* @param melt_amount amount specifying how much
* the coin will contribute to the melt (including fee)
* @param melt_sig signatures affirming the
* validity of the public keys corresponding to the
* @a melt_priv private key
* @param melt_pk denomination key information
* record corresponding to the @a melt_sig
* validity of the keys
* @param age_commitment (optional) age commitment that went into the original
* coin. Maybe NULL, if no age commitment was provided.
* @param fresh_pks_len length of the @a pks array
* @param fresh_pks array of @a pks_len denominations of fresh coins to create
* @return NULL
* if the inputs are invalid (i.e. denomination key not with this exchange).
* Otherwise, JSON data structure to store persistently
* before proceeding to #TALER_EXCHANGE_melt().
* Non-null results should be freed using GNUNET_free().
* Information needed to melt (partially spent) coins to obtain fresh coins
* that are unlinkable to the original coin(s). Note that melting more than
* one coin in a single request will make those coins linkable, so we only melt one coin at a time.
*/
json_t *
TALER_EXCHANGE_refresh_prepare (
const struct TALER_CoinSpendPrivateKeyP *melt_priv,
const struct TALER_Amount *melt_amount,
const struct TALER_DenominationSignature *melt_sig,
const struct TALER_EXCHANGE_DenomPublicKey *melt_pk,
const struct TALER_AgeCommitment *age_commitment,
unsigned int fresh_pks_len,
const struct TALER_EXCHANGE_DenomPublicKey *fresh_pks);
struct TALER_EXCHANGE_RefreshData
{
/**
* private key of the coin to melt
*/
struct TALER_CoinSpendPrivateKeyP melt_priv;
/**
* amount specifying how much the coin will contribute to the melt
* (including fee)
*/
struct TALER_Amount melt_amount;
/**
* signatures affirming the validity of the public keys corresponding to the
* @e melt_priv private key
*/
struct TALER_DenominationSignature melt_sig;
/**
* denomination key information record corresponding to the @e melt_sig
* validity of the keys
*/
struct TALER_EXCHANGE_DenomPublicKey melt_pk;
/**
* array of @e pks_len denominations of fresh coins to create
*/
const struct TALER_EXCHANGE_DenomPublicKey *fresh_pks;
/**
* length of the @e pks array
*/
unsigned int fresh_pks_len;
};
/* ********************* /coins/$COIN_PUB/melt ***************************** */
@ -1508,6 +1637,67 @@ TALER_EXCHANGE_refresh_prepare (
struct TALER_EXCHANGE_MeltHandle;
/**
* Information we obtain per coin during melting.
*/
struct TALER_EXCHANGE_MeltBlindingDetail
{
/**
* Exchange values contributed to the refresh operation
*/
struct TALER_ExchangeWithdrawValues alg_value;
};
/**
* Response returned to a /melt request.
*/
struct TALER_EXCHANGE_MeltResponse
{
/**
* Full HTTP response details.
*/
struct TALER_EXCHANGE_HttpResponse hr;
/**
* Parsed response details, variant depending on the
* @e hr.http_status.
*/
union
{
/**
* Results for status #MHD_HTTP_SUCCESS.
*/
struct
{
/**
* Information returned per coin.
*/
const struct TALER_EXCHANGE_MeltBlindingDetail *mbds;
/**
* Key used by the exchange to sign the response.
*/
struct TALER_ExchangePublicKeyP sign_key;
/**
* Length of the @a mbds array with the exchange values
* and blinding keys we are using.
*/
unsigned int num_mbds;
/**
* Gamma value chosen by the exchange.
*/
uint32_t noreveal_index;
} success;
} details;
};
/**
* Callbacks of this type are used to notify the application about the result
* of the /coins/$COIN_PUB/melt stage. If successful, the @a noreveal_index
@ -1515,17 +1705,12 @@ struct TALER_EXCHANGE_MeltHandle;
* #TALER_EXCHANGE_refreshes_reveal().
*
* @param cls closure
* @param hr HTTP response data
* @param noreveal_index choice by the exchange in the cut-and-choose protocol,
* UINT32_MAX on error
* @param sign_key exchange key used to sign @a full_response, or NULL
* @param mr response details
*/
typedef void
(*TALER_EXCHANGE_MeltCallback) (
void *cls,
const struct TALER_EXCHANGE_HttpResponse *hr,
uint32_t noreveal_index,
const struct TALER_ExchangePublicKeyP *sign_key);
const struct TALER_EXCHANGE_MeltResponse *mr);
/**
@ -1534,13 +1719,12 @@ typedef void
*
* This API is typically used by a wallet. Note that to ensure that
* no money is lost in case of hardware failures, the provided
* argument should have been constructed using
* #TALER_EXCHANGE_refresh_prepare and committed to persistent storage
* argument @a rd should be committed to persistent storage
* prior to calling this function.
*
* @param exchange the exchange handle; the exchange must be ready to operate
* @param refresh_data the refresh data as returned from
#TALER_EXCHANGE_refresh_prepare())
* @param rms the fresh secret that defines the refresh operation
* @param rd the refresh data specifying the characteristics of the operation
* @param melt_cb the callback to call with the result
* @param melt_cb_cls closure for @a melt_cb
* @return a handle for this request; NULL if the argument was invalid.
@ -1548,7 +1732,8 @@ typedef void
*/
struct TALER_EXCHANGE_MeltHandle *
TALER_EXCHANGE_melt (struct TALER_EXCHANGE_Handle *exchange,
const json_t *refresh_data,
const struct TALER_RefreshMasterSecretP *rms,
const struct TALER_EXCHANGE_RefreshData *rd,
TALER_EXCHANGE_MeltCallback melt_cb,
void *melt_cb_cls);
@ -1566,27 +1751,87 @@ TALER_EXCHANGE_melt_cancel (struct TALER_EXCHANGE_MeltHandle *mh);
/* ********************* /refreshes/$RCH/reveal ***************************** */
/**
* Information about a coin obtained via /refreshes/$RCH/reveal.
*/
struct TALER_EXCHANGE_RevealedCoinInfo
{
/**
* Private key of the coin.
*/
struct TALER_CoinSpendPrivateKeyP coin_priv;
/**
* Master secret of this coin.
*/
struct TALER_PlanchetMasterSecretP ps;
/**
* Blinding keys used to blind the fresh coin.
*/
union TALER_DenominationBlindingKeyP bks;
/**
* Signature affirming the validity of the coin.
*/
struct TALER_DenominationSignature sig;
};
/**
* Result of a /refreshes/$RCH/reveal request.
*/
struct TALER_EXCHANGE_RevealResult
{
/**
* HTTP status.
*/
struct TALER_EXCHANGE_HttpResponse hr;
/**
* Parsed response details, variant depending on the
* @e hr.http_status.
*/
union
{
/**
* Results for status #MHD_HTTP_SUCCESS.
*/
struct
{
/**
* Array of @e num_coins values about the coins obtained via the refresh
* operation. The array give the coins in the same order (and should
* have the same length) in which the original melt request specified the
* respective denomination keys.
*/
const struct TALER_EXCHANGE_RevealedCoinInfo *coins;
/**
* Number of coins returned.
*/
unsigned int num_coins;
} success;
} details;
};
/**
* Callbacks of this type are used to return the final result of
* submitting a refresh request to a exchange. If the operation was
* successful, this function returns the signatures over the coins
* that were remelted. The @a coin_privs and @a sigs arrays give the
* coins in the same order (and should have the same length) in which
* the original request specified the respective denomination keys.
* that were remelted.
*
* @param cls closure
* @param hr HTTP response data
* @param num_coins number of fresh coins created, length of the @a sigs and @a coin_privs arrays, 0 if the operation failed
* @param coin_privs array of @a num_coins private keys for the coins that were created, NULL on error
* @param sigs array of signature over @a num_coins coins, NULL on error
* @param rr result of the reveal operation
*/
typedef void
(*TALER_EXCHANGE_RefreshesRevealCallback)(
void *cls,
const struct TALER_EXCHANGE_HttpResponse *hr,
unsigned int num_coins,
const struct TALER_PlanchetSecretsP *coin_privs,
const struct TALER_DenominationSignature *sigs);
const struct TALER_EXCHANGE_RevealResult *rr);
/**
@ -1605,8 +1850,10 @@ struct TALER_EXCHANGE_RefreshesRevealHandle;
* prior to calling this function.
*
* @param exchange the exchange handle; the exchange must be ready to operate
* @param refresh_data the refresh data as returned from
#TALER_EXCHANGE_refresh_prepare())
* @param rms the fresh secret that defines the refresh operation
* @param rd the refresh data that characterizes the refresh operation
* @param num_coins number of fresh coins to be created, length of the @a exchange_vals array, must match value in @a rd
* @param alg_values array @a num_coins of exchange values contributed to the refresh operation
* @param noreveal_index response from the exchange to the
* #TALER_EXCHANGE_melt() invocation
* @param reveal_cb the callback to call with the final result of the
@ -1618,7 +1865,10 @@ struct TALER_EXCHANGE_RefreshesRevealHandle;
struct TALER_EXCHANGE_RefreshesRevealHandle *
TALER_EXCHANGE_refreshes_reveal (
struct TALER_EXCHANGE_Handle *exchange,
const json_t *refresh_data,
const struct TALER_RefreshMasterSecretP *rms,
const struct TALER_EXCHANGE_RefreshData *rd,
unsigned int num_coins,
const struct TALER_ExchangeWithdrawValues *alg_values,
uint32_t noreveal_index,
TALER_EXCHANGE_RefreshesRevealCallback reveal_cb,
void *reveal_cb_cls);
@ -1644,6 +1894,71 @@ TALER_EXCHANGE_refreshes_reveal_cancel (
struct TALER_EXCHANGE_LinkHandle;
/**
* Information about a coin obtained via /link.
*/
struct TALER_EXCHANGE_LinkedCoinInfo
{
/**
* Private key of the coin.
*/
struct TALER_CoinSpendPrivateKeyP coin_priv;
/**
* Master secret of this coin.
*/
struct TALER_PlanchetMasterSecretP ps;
/**
* Signature affirming the validity of the coin.
*/
struct TALER_DenominationSignature sig;
/**
* Denomination public key of the coin.
*/
struct TALER_DenominationPublicKey pub;
};
/**
* Result of a /link request.
*/
struct TALER_EXCHANGE_LinkResult
{
/**
* HTTP status.
*/
struct TALER_EXCHANGE_HttpResponse hr;
/**
* Parsed response details, variant depending on the
* @e hr.http_status.
*/
union
{
/**
* Results for status #MHD_HTTP_SUCCESS.
*/
struct
{
/**
* Array of @e num_coins values about the
* coins obtained via linkage.
*/
const struct TALER_EXCHANGE_LinkedCoinInfo *coins;
/**
* Number of coins returned.
*/
unsigned int num_coins;
} success;
} details;
};
/**
* Callbacks of this type are used to return the final result of submitting a
* /coins/$COIN_PUB/link request to a exchange. If the operation was
@ -1651,20 +1966,12 @@ struct TALER_EXCHANGE_LinkHandle;
* created when the original coin was melted.
*
* @param cls closure
* @param hr HTTP response data
* @param num_coins number of fresh coins created, length of the @a sigs and @a coin_privs arrays, 0 if the operation failed
* @param coin_privs array of @a num_coins private keys for the coins that were created, NULL on error
* @param sigs array of signature over @a num_coins coins, NULL on error
* @param pubs array of public keys for the @a sigs, NULL on error
* @param lr result of the /link operation
*/
typedef void
(*TALER_EXCHANGE_LinkCallback) (
void *cls,
const struct TALER_EXCHANGE_HttpResponse *hr,
unsigned int num_coins,
const struct TALER_CoinSpendPrivateKeyP *coin_privs,
const struct TALER_DenominationSignature *sigs,
const struct TALER_DenominationPublicKey *pubs);
const struct TALER_EXCHANGE_LinkResult *lr);
/**
@ -1897,8 +2204,7 @@ struct TALER_EXCHANGE_GetDepositResponse
* Function called with detailed wire transfer data.
*
* @param cls closure
* @param hr HTTP response data
* @param dd details about the deposit (NULL on errors)
* @param dr details about the deposit response
*/
typedef void
(*TALER_EXCHANGE_DepositGetCallback)(
@ -2037,6 +2343,7 @@ typedef void
* @param exchange the exchange handle; the exchange must be ready to operate
* @param pk kind of coin to pay back
* @param denom_sig signature over the coin by the exchange using @a pk
* @param exchange_vals contribution from the exchange on the withdraw
* @param ps secret internals of the original planchet
* @param recoup_cb the callback to call when the final result for this request is available
* @param recoup_cb_cls closure for @a recoup_cb
@ -2048,7 +2355,8 @@ struct TALER_EXCHANGE_RecoupHandle *
TALER_EXCHANGE_recoup (struct TALER_EXCHANGE_Handle *exchange,
const struct TALER_EXCHANGE_DenomPublicKey *pk,
const struct TALER_DenominationSignature *denom_sig,
const struct TALER_PlanchetSecretsP *ps,
const struct TALER_ExchangeWithdrawValues *exchange_vals,
const struct TALER_PlanchetMasterSecretP *ps,
TALER_EXCHANGE_RecoupResultCallback recoup_cb,
void *recoup_cb_cls);
@ -2097,7 +2405,10 @@ typedef void
* @param exchange the exchange handle; the exchange must be ready to operate
* @param pk kind of coin to pay back
* @param denom_sig signature over the coin by the exchange using @a pk
* @param ps secret internals of the original planchet
* @param exchange_vals contribution from the exchange on the withdraw
* @param rms melt secret of the refreshing operation
* @param ps coin-specific secrets derived for this coin during the refreshing operation
* @param idx index of the fresh coin in the refresh operation that is now being recouped
* @param recoup_cb the callback to call when the final result for this request is available
* @param recoup_cb_cls closure for @a recoup_cb
* @return NULL
@ -2109,7 +2420,10 @@ TALER_EXCHANGE_recoup_refresh (
struct TALER_EXCHANGE_Handle *exchange,
const struct TALER_EXCHANGE_DenomPublicKey *pk,
const struct TALER_DenominationSignature *denom_sig,
const struct TALER_PlanchetSecretsP *ps,
const struct TALER_ExchangeWithdrawValues *exchange_vals,
const struct TALER_RefreshMasterSecretP *rms,
const struct TALER_PlanchetMasterSecretP *ps,
unsigned int idx,
TALER_EXCHANGE_RecoupRefreshResultCallback recoup_cb,
void *recoup_cb_cls);
@ -2169,7 +2483,7 @@ struct TALER_EXCHANGE_KycStatus
/**
* Signature of purpose
* #TALER_SIGNATURE_ACCOUNT_SETUP_SUCCESS affirming
* #TALER_SIGNATURE_EXCHANGE_ACCOUNT_SETUP_SUCCESS affirming
* the successful KYC process.
*/
struct TALER_ExchangeSignatureP exchange_sig;
@ -2263,7 +2577,7 @@ struct TALER_EXCHANGE_KycProofResponse
* Function called with the result of a KYC check.
*
* @param cls closure
* @param ks the account's KYC status details
* @param kpr the account's KYC status details
*/
typedef void
(*TALER_EXCHANGE_KycProofCallback)(
@ -2500,10 +2814,15 @@ struct TALER_EXCHANGE_FutureKeys
struct TALER_SecurityModulePublicKeyP signkey_secmod_public_key;
/**
* Public key of the denomination security module.
* Public key of the RSA denomination security module.
*/
struct TALER_SecurityModulePublicKeyP denom_secmod_public_key;
/**
* Public key of the CS denomination security module.
*/
struct TALER_SecurityModulePublicKeyP denom_secmod_cs_public_key;
/**
* Offline master public key used by this exchange.
*/

63
src/include/taler_exchangedb_plugin.h
View File

@ -323,6 +323,7 @@ struct TALER_EXCHANGEDB_TableData
uint64_t denominations_serial;
void *coin_ev;
size_t coin_ev_size;
struct TALER_ExchangeWithdrawValues ewv;
// h_coin_ev omitted, to be recomputed!
struct TALER_BlindedDenominationSignature ev_sig;
} refresh_revealed_coins;
@ -346,7 +347,7 @@ struct TALER_EXCHANGEDB_TableData
struct TALER_MerchantPublicKeyP merchant_pub;
struct TALER_PrivateContractHash h_contract_terms;
struct TALER_CoinSpendSignatureP coin_sig;
struct TALER_WireSalt wire_salt;
struct TALER_WireSaltP wire_salt;
uint64_t wire_target_serial_id;
bool tiny;
bool done;
@ -1033,7 +1034,7 @@ struct TALER_EXCHANGEDB_Deposit
/**
* Salt used by the merchant to compute "h_wire".
*/
struct TALER_WireSalt wire_salt;
struct TALER_WireSaltP wire_salt;
/**
* Information about the receiver for executing the transaction. URI in
@ -1132,7 +1133,7 @@ struct TALER_EXCHANGEDB_DepositListEntry
/**
* Salt used to compute h_wire from the @e receiver_wire_account.
*/
struct TALER_WireSalt wire_salt;
struct TALER_WireSaltP wire_salt;
/**
* Time when this request was generated. Used, for example, to
@ -1388,12 +1389,32 @@ struct TALER_EXCHANGEDB_LinkList
*/
struct TALER_BlindedDenominationSignature ev_sig;
/**
* Exchange-provided values during the coin generation.
*/
struct TALER_ExchangeWithdrawValues alg_values;
/**
* Signature of the original coin being refreshed over the
* link data, of type #TALER_SIGNATURE_WALLET_COIN_LINK
*/
struct TALER_CoinSpendSignatureP orig_coin_link_sig;
/**
* CS nonce, if cipher is CS.
*/
struct TALER_CsNonce nonce;
/**
* Offset that generated this coin in the refresh
* operation.
*/
uint32_t coin_refresh_offset;
/**
* Set to true if @e nonce was initialized.
*/
bool have_nonce;
};
@ -1668,14 +1689,15 @@ struct TALER_EXCHANGEDB_RefreshRevealedCoin
struct TALER_BlindedDenominationSignature coin_sig;
/**
* Blinded message to be signed (in envelope), with @e coin_env_size bytes.
* Values contributed from the exchange to the
* coin generation (see /csr).
*/
void *coin_ev;
struct TALER_ExchangeWithdrawValues exchange_vals;
/**
* Number of bytes in @e coin_ev.
* Blinded message to be signed (in envelope).
*/
size_t coin_ev_size;
struct TALER_BlindedPlanchet blinded_planchet;
};
@ -1895,7 +1917,6 @@ typedef void
* @param cls closure
* @param rowid which row in the table is the information from (for diagnostics)
* @param merchant_pub public key of the merchant (should be same for all callbacks with the same @e cls)
* @param h_wire hash of wire transfer details of the merchant (should be same for all callbacks with the same @e cls)
* @param account_payto_uri which account did the transfer go to?
* @param exec_time execution time of the wire transfer (should be same for all callbacks with the same @e cls)
* @param h_contract_terms which proposal was this payment about
@ -2477,20 +2498,19 @@ struct TALER_EXCHANGEDB_Plugin
/**
* Locate the response for a withdraw request under the
* key of the hash of the blinded message. Used to ensure
* idempotency of the request.
* Locate the response for a withdraw request under a hash that uniquely
* identifies the withdraw operation. Used to ensure idempotency of the
* request.
*
* @param cls the @e cls of this struct with the plugin-specific state
* @param h_blind hash of the blinded coin to be signed (will match
* `h_coin_envelope` in the @a collectable to be returned)
* @param collectable corresponding collectable coin (blind signature)
* @param wih hash that uniquely identifies the withdraw operation
* @param[out] collectable corresponding collectable coin (blind signature)
* if a coin is found
* @return statement execution status
*/
enum GNUNET_DB_QueryStatus
(*get_withdraw_info)(void *cls,
const struct TALER_BlindedCoinHash *h_blind,
const struct TALER_WithdrawIdentificationHash *wih,
struct TALER_EXCHANGEDB_CollectableBlindcoin *collectable);
@ -2499,7 +2519,8 @@ struct TALER_EXCHANGEDB_Plugin
* and possibly persisting the withdrawal details.
*
* @param cls the `struct PostgresClosure` with the plugin-specific state
* @param collectable corresponding collectable coin (blind signature)
* @param wih hash that uniquely identifies the withdraw operation
* @param[in,out] collectable corresponding collectable coin (blind signature)
* if a coin is found
* @param now current time (rounded)
* @param[out] found set to true if the reserve was found
@ -2511,7 +2532,8 @@ struct TALER_EXCHANGEDB_Plugin
enum GNUNET_DB_QueryStatus
(*do_withdraw)(
void *cls,
const struct TALER_EXCHANGEDB_CollectableBlindcoin *collectable,
const struct TALER_WithdrawIdentificationHash *wih,
struct TALER_EXCHANGEDB_CollectableBlindcoin *collectable,
struct GNUNET_TIME_Timestamp now,
bool *found,
bool *balance_ok,
@ -2547,6 +2569,7 @@ struct TALER_EXCHANGEDB_Plugin
* @param deposit deposit operation details
* @param known_coin_id row of the coin in the known_coins table
* @param h_payto hash of the merchant's payto URI
* @param extension_blocked true if an extension is blocking the wire transfer
* @param[in,out] exchange_timestamp time to use for the deposit (possibly updated)
* @param[out] balance_ok set to true if the balance was sufficient
* @param[out] in_conflict set to true if the deposit conflicted
@ -3517,14 +3540,14 @@ struct TALER_EXCHANGEDB_Plugin
* from given the hash of the blinded coin.
*
* @param cls closure
* @param h_blind_ev hash of the blinded coin
* @param wih hash identifying the withdraw operation
* @param[out] reserve_pub set to information about the reserve (on success only)
* @param[out] reserve_out_serial_id set to row of the @a h_blind_ev in reserves_out
* @return transaction status code
*/
enum GNUNET_DB_QueryStatus
(*get_reserve_by_h_blind)(void *cls,
const struct TALER_BlindedCoinHash *h_blind_ev,
(*get_reserve_by_wih)(void *cls,
const struct TALER_WithdrawIdentificationHash *wih,
struct TALER_ReservePublicKeyP *reserve_pub,
uint64_t *reserve_out_serial_id);

67
src/include/taler_json_lib.h
View File

@ -1,6 +1,6 @@
/*
This file is part of TALER
Copyright (C) 2014, 2015, 2016, 2021 Taler Systems SA
Copyright (C) 2014, 2015, 2016, 2021, 2022 Taler Systems SA
TALER is free software; you can redistribute it and/or modify it under the
terms of the GNU General Public License as published by the Free Software
@ -117,6 +117,34 @@ TALER_JSON_pack_blinded_denom_sig (
const struct TALER_BlindedDenominationSignature *sig);
/**
* Generate packer instruction for a JSON field of type
* blinded planchet.
*
* @param name name of the field to add to the object
* @param blinded_planchet blinded planchet
* @return json pack specification
*/
struct GNUNET_JSON_PackSpec
TALER_JSON_pack_blinded_planchet (
const char *name,
const struct TALER_BlindedPlanchet *blinded_planchet);
/**
* Generate packer instruction for a JSON field of type
* exchange withdraw values (/csr).
*
* @param name name of the field to add to the object
* @param ewv values to transmit
* @return json pack specification
*/
struct GNUNET_JSON_PackSpec
TALER_JSON_pack_exchange_withdraw_values (
const char *name,
const struct TALER_ExchangeWithdrawValues *ewv);
/**
* Generate packer instruction for a JSON field of type
* amount.
@ -238,7 +266,7 @@ TALER_JSON_spec_denom_pub (const char *field,
* Generate line in parser specification for denomination signature.
*
* @param field name of the field
* @param sig the signature to initialize
* @param[out] sig the signature to initialize
* @return corresponding field spec
*/
struct GNUNET_JSON_Specification
@ -251,7 +279,7 @@ TALER_JSON_spec_denom_sig (const char *field,
* blinded denomination signature.
*
* @param field name of the field
* @param sig the blinded signature to initialize
* @param[out] sig the blinded signature to initialize
* @return corresponding field spec
*/
struct GNUNET_JSON_Specification
@ -260,6 +288,33 @@ TALER_JSON_spec_blinded_denom_sig (
struct TALER_BlindedDenominationSignature *sig);
/**
* Generate line in parser specification for
* exchange withdraw values (/csr).
*
* @param field name of the field
* @param[out] ewv the exchange withdraw values to initialize
* @return corresponding field spec
*/
struct GNUNET_JSON_Specification
TALER_JSON_spec_exchange_withdraw_values (
const char *field,
struct TALER_ExchangeWithdrawValues *ewv);
/**
* Generate line in parser specification for a
* blinded planchet.
*
* @param field name of the field
* @param[out] blinded_planchet the blinded planchet to initialize
* @return corresponding field spec
*/
struct GNUNET_JSON_Specification
TALER_JSON_spec_blinded_planchet (const char *field,
struct TALER_BlindedPlanchet *blinded_planchet);
/**
* The expected field stores a possibly internationalized string.
* Internationalization means that there is another field "$name_i18n"
@ -552,6 +607,12 @@ enum GNUNET_GenericReturnValue
TALER_JSON_extensions_config_hash (const json_t *config,
struct TALER_ExtensionConfigHash *eh);
/**
* Canonicalize a JSON input to a string according to RFC 8785.
*/
char *
TALER_JSON_canonicalize (const json_t *input);
#endif /* TALER_JSON_LIB_H_ */
/* End of taler_json_lib.h */

2
src/include/taler_mhd_lib.h
View File

@ -547,7 +547,7 @@ struct TALER_MHD_Legal;
/**
* Load set of legal documents as specified in @a cfg in section @a section
* where the Etag is given under the @param tagoption and the directory under
* where the Etag is given under the @a tagoption and the directory under
* the @a diroption.
*
* @param cfg configuration to use

59
src/include/taler_pq_lib.h
View File

@ -1,6 +1,6 @@
/*
This file is part of TALER
Copyright (C) 2014, 2015, 2016 Taler Systems SA
Copyright (C) 2014-2022 Taler Systems SA
TALER is free software; you can redistribute it and/or modify it under the
terms of the GNU General Public License as published by the Free Software
@ -58,7 +58,7 @@ TALER_PQ_query_param_amount (const struct TALER_Amount *x);
* public key will be serialized into on variable-size
* BLOB.
*
* @param x pointer to the query parameter to pass
* @param denom_pub pointer to the query parameter to pass
*/
struct GNUNET_PQ_QueryParam
TALER_PQ_query_param_denom_pub (
@ -70,25 +70,50 @@ TALER_PQ_query_param_denom_pub (
* various attributes of the signature will be serialized into on
* variable-size BLOB.
*
* @param x pointer to the query parameter to pass
* @param denom_sig pointer to the query parameter to pass
*/
struct GNUNET_PQ_QueryParam
TALER_PQ_query_param_denom_sig (
const struct TALER_DenominationSignature *denom_sig);
/**
* Generate query parameter for a blinded planchet.
* Internally, various attributes of the blinded
* planchet will be serialized into on
* variable-size BLOB.
*
* @param bp pointer to the query parameter to pass
*/
struct GNUNET_PQ_QueryParam
TALER_PQ_query_param_blinded_planchet (
const struct TALER_BlindedPlanchet *bp);
/**
* Generate query parameter for a blinded denomination signature. Internally,
* the various attributes of the signature will be serialized into on
* variable-size BLOB.
*
* @param x pointer to the query parameter to pass
* @param denom_sig pointer to the query parameter to pass
*/
struct GNUNET_PQ_QueryParam
TALER_PQ_query_param_blinded_denom_sig (
const struct TALER_BlindedDenominationSignature *denom_sig);
/**
* Generate query parameter for the exchange's contribution during a
* withdraw. Internally, the various attributes of the @a alg_values will be
* serialized into on variable-size BLOB.
*
* @param alg_values pointer to the query parameter to pass
*/
struct GNUNET_PQ_QueryParam
TALER_PQ_query_param_exchange_withdraw_values (
const struct TALER_ExchangeWithdrawValues *alg_values);
/**
* Generate query parameter for a JSON object (stored as a string
* in the DB). Note that @a x must really be a JSON object or array,
@ -166,6 +191,32 @@ TALER_PQ_result_spec_blinded_denom_sig (
struct TALER_BlindedDenominationSignature *denom_sig);
/**
* Exchange withdraw values expected.
*
* @param name name of the field in the table
* @param[out] ewv where to store the exchange values
* @return array entry for the result specification to use
*/
struct GNUNET_PQ_ResultSpec
TALER_PQ_result_spec_exchange_withdraw_values (
const char *name,
struct TALER_ExchangeWithdrawValues *ewv);
/**
* Blinded planchet expected.
*
* @param name name of the field in the table
* @param[out] bp where to store the blinded planchet
* @return array entry for the result specification to use
*/
struct GNUNET_PQ_ResultSpec
TALER_PQ_result_spec_blinded_planchet (
const char *name,
struct TALER_BlindedPlanchet *bp);
/**
* json_t expected.
*

18
src/include/taler_signatures.h
View File

@ -164,7 +164,6 @@
*/
#define TALER_SIGNATURE_EXCHANGE_AFFIRM_DENOM_UNKNOWN 1042
/**
* Signature where the Exchange confirms that it does not consider a denomination valid for the given operation
* at this time.
@ -287,6 +286,11 @@
*/
#define TALER_SIGNATURE_SM_SIGNING_KEY 1251
/**
* Signature on a denomination key announcement.
*/
#define TALER_SIGNATURE_SM_CS_DENOMINATION_KEY 1252
/*******************/
/* Test signatures */
/*******************/
@ -341,7 +345,7 @@ struct TALER_DenominationKeyAnnouncementPS
/**
* Hash of the denomination public key.
*/
struct TALER_RsaPubHashP h_rsa;
struct TALER_DenominationHash h_denom;
/**
* Hash of the section name in the configuration of this denomination.
@ -440,13 +444,7 @@ struct TALER_WithdrawRequestPS
struct GNUNET_CRYPTO_EccSignaturePurpose purpose;
/**
* Reserve public key (which reserve to withdraw from). This is
* the public key which must match the signature.
*/
struct TALER_ReservePublicKeyP reserve_pub;
/**
* Value of the coin being exchangeed (matching the denomination key)
* Value of the coin being exchanged (matching the denomination key)
* plus the transaction fee. We include this in what is being
* signed so that we can verify a reserve's remaining total balance
* without needing to access the respective denomination key
@ -1234,7 +1232,7 @@ struct TALER_MerchantWireDetailsPS
/**
* Salted hash over the account holder's payto:// URL and
* the salt, as done by #TALER_exchange_wire_signature_hash().
* the salt, as done by #TALER_merchant_wire_signature_hash().
*/
struct TALER_MerchantWireHash h_wire_details GNUNET_PACKED;

40
src/include/taler_testing_lib.h
View File

@ -1,6 +1,6 @@
/*
This file is part of TALER
(C) 2018 Taler Systems SA
(C) 2018-2022 Taler Systems SA
TALER is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as
@ -1000,10 +1000,11 @@ TALER_TESTING_cmd_bank_debits (const char *label,
/**
* Create transfer command.
*
* @param label command label.
* @param amount amount to transfer.
* @param label command label
* @param amount amount to transfer
* @param auth authentication data to use
* @param payto_credit_account which account receives money.
* @param payto_debit_account which account to withdraw money from
* @param payto_credit_account which account receives money
* @param wtid wire transfer identifier to use
* @param exchange_base_url exchange URL to use
* @return the command.
@ -1715,14 +1716,13 @@ TALER_TESTING_cmd_check_bank_empty (const char *label);
* provide a coin to be refunded.
* @param refund_transaction_id transaction id to use
* in the request.
*
* @return the command.
*/
struct TALER_TESTING_Command
TALER_TESTING_cmd_refund_with_id (const char *label,
unsigned int expected_response_code,
const char *refund_amount,
const char *deposit_reference,
const char *coin_reference,
uint64_t refund_transaction_id);
@ -1734,14 +1734,13 @@ TALER_TESTING_cmd_refund_with_id (const char *label,
* @param refund_amount the amount to ask a refund for.
* @param coin_reference reference to a command that can
* provide a coin to be refunded.
*
* @return the command.
*/
struct TALER_TESTING_Command
TALER_TESTING_cmd_refund (const char *label,
unsigned int expected_response_code,
const char *refund_amount,
const char *deposit_reference);
const char *coin_reference);
/**
@ -2090,6 +2089,7 @@ TALER_TESTING_cmd_auditor_add_denom_sig (const char *label,
const char *denom_ref,
bool bad_sig);
/**
* Add statement about wire fees of the exchange. This is always
* done for a few hours around the current time (for the test).
@ -2227,26 +2227,6 @@ TALER_TESTING_cmd_revoke_sign_key (
const char *signkey_ref);
/**
* Have the auditor affirm that it is auditing the given
* denomination key and upload the auditor's signature to
* the exchange.
*
* @param label command label.
* @param expected_http_status expected HTTP status from exchange
* @param denom_ref reference to a command that identifies
* a denomination key (i.e. because it was used to
* withdraw a coin).
* @param bad_sig should we use a bogus signature?
* @return the command
*/
struct TALER_TESTING_Command
TALER_TESTING_cmd_auditor_add_denom_sig (const char *label,
unsigned int expected_http_status,
const char *denom_ref,
bool bad_sig);
/**
* Create a request for a wallet's KYC UUID.
*
@ -2462,6 +2442,8 @@ TALER_TESTING_get_trait (const struct TALER_TESTING_Trait *traits,
#define TALER_TESTING_SIMPLE_TRAITS(op) \
op (bank_row, const uint64_t) \
op (reserve_priv, const struct TALER_ReservePrivateKeyP) \
op (planchet_secret, const struct TALER_PlanchetMasterSecretP) \
op (refresh_secret, const struct TALER_RefreshMasterSecretP) \
op (reserve_pub, const struct TALER_ReservePublicKeyP) \
op (merchant_priv, const struct TALER_MerchantPrivateKeyP) \
op (merchant_pub, const struct TALER_MerchantPublicKeyP) \
@ -2503,6 +2485,8 @@ TALER_TESTING_get_trait (const struct TALER_TESTING_Trait *traits,
op (denom_sig, const struct TALER_DenominationSignature) \
op (age_commitment, struct TALER_AgeCommitment) \
op (h_age_commitment, struct TALER_AgeCommitmentHash) \
op (planchet_secrets, const struct TALER_PlanchetMasterSecretP) \
op (exchange_wd_value, const struct TALER_ExchangeWithdrawValues) \
op (coin_priv, const struct TALER_CoinSpendPrivateKeyP) \
op (coin_pub, const struct TALER_CoinSpendPublicKeyP) \
op (absolute_time, const struct GNUNET_TIME_Absolute) \

3
src/include/taler_util.h
View File

@ -131,6 +131,7 @@ TALER_b2s (const void *buf,
/**
* Obtain denomination amount from configuration file.
*
* @param cfg configuration to extract data from
* @param section section of the configuration to access
* @param option option of the configuration to access
* @param[out] denom set to the amount found in configuration
@ -329,7 +330,7 @@ TALER_payto_get_method (const char *payto_uri);
/**
* Construct a payto://-URI from a Taler @a reserve_pub at
* a @exchange_base_url
* @a exchange_base_url
*
* @param exchange_base_url the URL of the exchange
* @param reserve_pub public key of the reserve

37
src/json/json.c
View File

@ -78,27 +78,27 @@ lowdump (struct GNUNET_Buffer *buf,
{
case 0x8:
GNUNET_buffer_write (buf,
"\b",
"\\b",
2);
break;
case 0x9:
GNUNET_buffer_write (buf,
"\t",
"\\t",
2);
break;
case 0xA:
GNUNET_buffer_write (buf,
"\n",
"\\n",
2);
break;
case 0xC:
GNUNET_buffer_write (buf,
"\f",
"\\f",
2);
break;
case 0xD:
GNUNET_buffer_write (buf,
"\r",
"\\r",
2);
break;
default:
@ -144,6 +144,9 @@ rfc8785encode (char **inp)
if ( (1 == mbl) &&
(val <= 0x1F) )
{
/* Should not happen, as input is produced by
* JSON stringification */
GNUNET_break (0);
lowdump (&buf,
val);
}
@ -193,6 +196,12 @@ rfc8785encode (char **inp)
}
}
break;
default:
mbl = 2;
GNUNET_buffer_write (&buf,
pos,
mbl);
break;
}
}
else
@ -1009,6 +1018,24 @@ TALER_deposit_extension_hash (const json_t *extensions,
}
char *
TALER_JSON_canonicalize (const json_t *input)
{
char *wire_enc;
if (NULL == (wire_enc = json_dumps (input,
JSON_ENCODE_ANY
| JSON_COMPACT
| JSON_SORT_KEYS)))
{
GNUNET_break (0);
return NULL;
}
rfc8785encode (&wire_enc);
return wire_enc;
}
enum GNUNET_GenericReturnValue
TALER_JSON_extensions_config_hash (const json_t *config,
struct TALER_ExtensionConfigHash *ech)

309
src/json/json_helper.c
View File

@ -26,6 +26,25 @@
#include "taler_json_lib.h"
/**
* Convert string value to numeric cipher value.
*
* @param cipher_s input string
* @return numeric cipher value
*/
static enum TALER_DenominationCipher
string_to_cipher (const char *cipher_s)
{
if (0 == strcasecmp (cipher_s,
"RSA"))
return TALER_DENOMINATION_RSA;
if (0 == strcasecmp (cipher_s,
"CS"))
return TALER_DENOMINATION_CS;
return TALER_DENOMINATION_INVALID;
}
json_t *
TALER_JSON_from_amount (const struct TALER_Amount *amount)
{
@ -229,9 +248,9 @@ parse_denom_pub (void *cls,
struct GNUNET_JSON_Specification *spec)
{
struct TALER_DenominationPublicKey *denom_pub = spec->ptr;
uint32_t cipher;
const char *cipher;
struct GNUNET_JSON_Specification dspec[] = {
GNUNET_JSON_spec_uint32 ("cipher",
GNUNET_JSON_spec_string ("cipher",
&cipher),
GNUNET_JSON_spec_uint32 ("age_mask",
&denom_pub->age_mask.mask),
@ -250,7 +269,7 @@ parse_denom_pub (void *cls,
GNUNET_break_op (0);
return GNUNET_SYSERR;
}
denom_pub->cipher = (enum TALER_DenominationCipher) cipher;
denom_pub->cipher = string_to_cipher (cipher);
switch (denom_pub->cipher)
{
case TALER_DENOMINATION_RSA:
@ -262,6 +281,26 @@ parse_denom_pub (void *cls,
GNUNET_JSON_spec_end ()
};
if (GNUNET_OK !=
GNUNET_JSON_parse (root,
ispec,
&emsg,
&eline))
{
GNUNET_break_op (0);
return GNUNET_SYSERR;
}
return GNUNET_OK;
}
case TALER_DENOMINATION_CS:
{
struct GNUNET_JSON_Specification ispec[] = {
GNUNET_JSON_spec_fixed ("cs_public_key",
&denom_pub->details.cs_public_key,
sizeof (denom_pub->details.cs_public_key)),
GNUNET_JSON_spec_end ()
};
if (GNUNET_OK !=
GNUNET_JSON_parse (root,
ispec,
@ -326,9 +365,9 @@ parse_denom_sig (void *cls,
struct GNUNET_JSON_Specification *spec)
{
struct TALER_DenominationSignature *denom_sig = spec->ptr;
uint32_t cipher;
const char *cipher;
struct GNUNET_JSON_Specification dspec[] = {
GNUNET_JSON_spec_uint32 ("cipher",
GNUNET_JSON_spec_string ("cipher",
&cipher),
GNUNET_JSON_spec_end ()
};
@ -345,7 +384,7 @@ parse_denom_sig (void *cls,
GNUNET_break_op (0);
return GNUNET_SYSERR;
}
denom_sig->cipher = (enum TALER_DenominationCipher) cipher;
denom_sig->cipher = string_to_cipher (cipher);
switch (denom_sig->cipher)
{
case TALER_DENOMINATION_RSA:
@ -357,6 +396,27 @@ parse_denom_sig (void *cls,
GNUNET_JSON_spec_end ()
};
if (GNUNET_OK !=
GNUNET_JSON_parse (root,
ispec,
&emsg,
&eline))
{
GNUNET_break_op (0);
return GNUNET_SYSERR;
}
return GNUNET_OK;
}
case TALER_DENOMINATION_CS:
{
struct GNUNET_JSON_Specification ispec[] = {
GNUNET_JSON_spec_fixed_auto ("cs_signature_r",
&denom_sig->details.cs_signature.r_point),
GNUNET_JSON_spec_fixed_auto ("cs_signature_s",
&denom_sig->details.cs_signature.s_scalar),
GNUNET_JSON_spec_end ()
};
if (GNUNET_OK !=
GNUNET_JSON_parse (root,
ispec,
@ -421,9 +481,9 @@ parse_blinded_denom_sig (void *cls,
struct GNUNET_JSON_Specification *spec)
{
struct TALER_BlindedDenominationSignature *denom_sig = spec->ptr;
uint32_t cipher;
const char *cipher;
struct GNUNET_JSON_Specification dspec[] = {
GNUNET_JSON_spec_uint32 ("cipher",
GNUNET_JSON_spec_string ("cipher",
&cipher),
GNUNET_JSON_spec_end ()
};
@ -440,7 +500,7 @@ parse_blinded_denom_sig (void *cls,
GNUNET_break_op (0);
return GNUNET_SYSERR;
}
denom_sig->cipher = (enum TALER_DenominationCipher) cipher;
denom_sig->cipher = string_to_cipher (cipher);
switch (denom_sig->cipher)
{
case TALER_DENOMINATION_RSA:
@ -463,6 +523,29 @@ parse_blinded_denom_sig (void *cls,
}
return GNUNET_OK;
}
case TALER_DENOMINATION_CS:
{
struct GNUNET_JSON_Specification ispec[] = {
GNUNET_JSON_spec_uint32 ("b",
&denom_sig->details.blinded_cs_answer.b),
GNUNET_JSON_spec_fixed_auto ("s",
&denom_sig->details.blinded_cs_answer.
s_scalar),
GNUNET_JSON_spec_end ()
};
if (GNUNET_OK !=
GNUNET_JSON_parse (root,
ispec,
&emsg,
&eline))
{
GNUNET_break_op (0);
return GNUNET_SYSERR;
}
return GNUNET_OK;
}
break;
default:
GNUNET_break_op (0);
return GNUNET_SYSERR;
@ -503,6 +586,214 @@ TALER_JSON_spec_blinded_denom_sig (
}
/**
* Parse given JSON object to blinded planchet.
*
* @param cls closure, NULL
* @param root the json object representing data
* @param[out] spec where to write the data
* @return #GNUNET_OK upon successful parsing; #GNUNET_SYSERR upon error
*/
static enum GNUNET_GenericReturnValue
parse_blinded_planchet (void *cls,
json_t *root,
struct GNUNET_JSON_Specification *spec)
{
struct TALER_BlindedPlanchet *blinded_planchet = spec->ptr;
const char *cipher;
struct GNUNET_JSON_Specification dspec[] = {
GNUNET_JSON_spec_string ("cipher",
&cipher),
GNUNET_JSON_spec_end ()
};
const char *emsg;
unsigned int eline;
(void) cls;
if (GNUNET_OK !=
GNUNET_JSON_parse (root,
dspec,
&emsg,
&eline))
{
GNUNET_break_op (0);
return GNUNET_SYSERR;
}
blinded_planchet->cipher = string_to_cipher (cipher);
switch (blinded_planchet->cipher)
{
case TALER_DENOMINATION_RSA:
{
struct GNUNET_JSON_Specification ispec[] = {
GNUNET_JSON_spec_varsize (
"rsa_blinded_planchet",
&blinded_planchet->details.rsa_blinded_planchet.blinded_msg,
&blinded_planchet->details.rsa_blinded_planchet.blinded_msg_size),
GNUNET_JSON_spec_end ()
};
if (GNUNET_OK !=
GNUNET_JSON_parse (root,
ispec,
&emsg,
&eline))
{
GNUNET_break_op (0);
return GNUNET_SYSERR;
}
return GNUNET_OK;
}
case TALER_DENOMINATION_CS:
{
struct GNUNET_JSON_Specification ispec[] = {
GNUNET_JSON_spec_fixed_auto (
"cs_nonce",
&blinded_planchet->details.cs_blinded_planchet.nonce),
GNUNET_JSON_spec_fixed_auto (
"cs_blinded_c0",
&blinded_planchet->details.cs_blinded_planchet.c[0]),
GNUNET_JSON_spec_fixed_auto (
"cs_blinded_c1",
&blinded_planchet->details.cs_blinded_planchet.c[1]),
GNUNET_JSON_spec_end ()
};
if (GNUNET_OK !=
GNUNET_JSON_parse (root,
ispec,
&emsg,
&eline))
{
GNUNET_break_op (0);
return GNUNET_SYSERR;
}
return GNUNET_OK;
}
break;
default:
GNUNET_break_op (0);
return GNUNET_SYSERR;
}
}
/**
* Cleanup data left from parsing blinded planchet.
*
* @param cls closure, NULL
* @param[out] spec where to free the data
*/
static void
clean_blinded_planchet (void *cls,
struct GNUNET_JSON_Specification *spec)
{
struct TALER_BlindedPlanchet *blinded_planchet = spec->ptr;
(void) cls;
TALER_blinded_planchet_free (blinded_planchet);
}
struct GNUNET_JSON_Specification
TALER_JSON_spec_blinded_planchet (const char *field,
struct TALER_BlindedPlanchet *blinded_planchet)
{
struct GNUNET_JSON_Specification ret = {
.parser = &parse_blinded_planchet,
.cleaner = &clean_blinded_planchet,
.field = field,
.ptr = blinded_planchet
};
return ret;
}
/**
* Parse given JSON object to exchange withdraw values (/csr).
*
* @param cls closure, NULL
* @param root the json object representing data
* @param[out] spec where to write the data
* @return #GNUNET_OK upon successful parsing; #GNUNET_SYSERR upon error
*/
static enum GNUNET_GenericReturnValue
parse_exchange_withdraw_values (void *cls,
json_t *root,
struct GNUNET_JSON_Specification *spec)
{
struct TALER_ExchangeWithdrawValues *ewv = spec->ptr;
const char *cipher;
struct GNUNET_JSON_Specification dspec[] = {
GNUNET_JSON_spec_string ("cipher",
&cipher),
GNUNET_JSON_spec_end ()
};
const char *emsg;
unsigned int eline;
(void) cls;
if (GNUNET_OK !=
GNUNET_JSON_parse (root,
dspec,
&emsg,
&eline))
{
GNUNET_break_op (0);
return GNUNET_SYSERR;
}
ewv->cipher = string_to_cipher (cipher);
switch (ewv->cipher)
{
case TALER_DENOMINATION_RSA:
return GNUNET_OK;
case TALER_DENOMINATION_CS:
{
struct GNUNET_JSON_Specification ispec[] = {
GNUNET_JSON_spec_fixed (
"r_pub_0",
&ewv->details.cs_values.r_pub[0],
sizeof (struct GNUNET_CRYPTO_CsRPublic)),
GNUNET_JSON_spec_fixed (
"r_pub_1",
&ewv->details.cs_values.r_pub[1],
sizeof (struct GNUNET_CRYPTO_CsRPublic)),
GNUNET_JSON_spec_end ()
};
if (GNUNET_OK !=
GNUNET_JSON_parse (root,
ispec,
&emsg,
&eline))
{
GNUNET_break_op (0);
return GNUNET_SYSERR;
}
return GNUNET_OK;
}
default:
GNUNET_break_op (0);
return GNUNET_SYSERR;
}
}
struct GNUNET_JSON_Specification
TALER_JSON_spec_exchange_withdraw_values (const char *field,
struct TALER_ExchangeWithdrawValues *
ewv)
{
struct GNUNET_JSON_Specification ret = {
.parser = &parse_exchange_withdraw_values,
.field = field,
.ptr = ewv
};
return ret;
}
/**
* Closure for #parse_i18n_string.
*/

Some files were not shown because too many files have changed in this diff Show More