[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-anastasis] branch master updated: cleanup
|
From: |
gnunet |
|
Subject: |
[taler-anastasis] branch master updated: cleanup |
|
Date: |
Mon, 26 Apr 2021 22:46:07 +0200 |
This is an automated email from the git hooks/post-receive script.
grothoff pushed a commit to branch master
in repository anastasis.
The following commit(s) were added to refs/heads/master by this push:
new cf0d7a0 cleanup
cf0d7a0 is described below
commit cf0d7a024fcdd59ec97e164c601a5cae7b81eee0
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Mon Apr 26 22:46:05 2021 +0200
cleanup
---
doc/thesis/.gitignore | 1 -
doc/thesis/Journal.tex | 228 ----
doc/thesis/abstract.tex | 29 -
doc/thesis/acknowledgments.tex | 7 -
doc/thesis/bibliothek.bib | 407 ------
doc/thesis/business_model.tex | 217 ---
doc/thesis/client_architecture.tex | 309 -----
doc/thesis/conclusion.tex | 16 -
doc/thesis/design.tex | 466 -------
doc/thesis/glossary.tex | 19 -
doc/thesis/images/BFH_Logo_A_en_100_4CU.pdf | Bin 21180 -> 0 bytes
doc/thesis/images/SD_truthupload.jpeg | Bin 72655 -> 0 bytes
doc/thesis/images/anastasis-db.png | Bin 58761 -> 0 bytes
doc/thesis/images/bitcoin-keys.png | Bin 166153 -> 0 bytes
doc/thesis/images/client_api.png | Bin 17388 -> 0 bytes
doc/thesis/images/keys_anastasis.png | Bin 128275 -> 0 bytes
doc/thesis/images/legend_keys_anastasis.png | Bin 33015 -> 0 bytes
doc/thesis/images/original/Secret split.drawio | 1 -
doc/thesis/images/original/architecture.drawio | 1 -
doc/thesis/images/original/assemble.drawio | 1 -
doc/thesis/images/original/keys_anastasis.xml | 1 -
.../images/original/legend_keys_anastasis.xml | 1 -
doc/thesis/images/original/truth_signing.drawio | 1 -
doc/thesis/images/project_plan.png | Bin 50611 -> 0 bytes
doc/thesis/images/project_plan_anastasis.png | Bin 78409 -> 0 bytes
doc/thesis/images/recovery_process.png | Bin 56690 -> 0 bytes
doc/thesis/images/secret_split.png | Bin 71801 -> 0 bytes
doc/thesis/images/selbst_dennis.pdf | Bin 721719 -> 0 bytes
doc/thesis/images/selbst_meister.pdf | Bin 517723 -> 0 bytes
doc/thesis/images/server_api.png | Bin 32112 -> 0 bytes
doc/thesis/images/system-architecture.png | Bin 139182 -> 0 bytes
doc/thesis/images/system-architecture_2.png | Bin 76910 -> 0 bytes
doc/thesis/images/system_design.png | Bin 57272 -> 0 bytes
doc/thesis/images/truth_anastasis.png | Bin 29767 -> 0 bytes
doc/thesis/images/user_id.png | Bin 44157 -> 0 bytes
doc/thesis/implementation.tex | 421 ------
doc/thesis/introduction.tex | 224 ----
doc/thesis/project_management.tex | 25 -
doc/thesis/related_work.tex | 484 -------
doc/thesis/rest_api_documentation.tex | 333 -----
doc/thesis/server_architecture.tex | 134 --
doc/thesis/thesis.bbl | 1412 --------------------
doc/thesis/thesis.lot | 3 -
doc/thesis/thesis.out | 80 --
doc/thesis/thesis.run.xml | 91 --
doc/thesis/thesis.tex | 118 --
46 files changed, 5030 deletions(-)
diff --git a/doc/thesis/.gitignore b/doc/thesis/.gitignore
deleted file mode 100644
index f109c26..0000000
--- a/doc/thesis/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-thesis.toc
diff --git a/doc/thesis/Journal.tex b/doc/thesis/Journal.tex
deleted file mode 100644
index 566c214..0000000
--- a/doc/thesis/Journal.tex
+++ /dev/null
@@ -1,228 +0,0 @@
-%\title{Anastasis work journal}
-%\date{\today} %% or \date{01 november 2018}
-%\author{Dominik Meister (\texttt{dominiksamuel.meister@students.bfh.ch}) \\
-% Dennis Neufeld (\texttt{dennis.neufeld@students.bfh.ch })}
-%\maketitle
-%\clearpage
-
-\section{Work journal}
-\section*{Meeting 20.02.2020}
-Present at the Meeting were: Dominik Meister, Dennis Neufeld and Christian
Grothoff.
-\subsection*{Reflection}
-It was the first meeting of the Bachelor's thesis. The main focus was on the
planing of the project and discussing the next steps.
-The conclusion was there is a lot of work to do and we need to focus from the
beginning.
-\subsection*{Next Steps}
-The next meeting will be at the 27.2. Until this meeting drafts of several
project documents should be completed. Task schedule, project document, work
journal, business plan, abstract, motivation. Additionally a draft for the
BRIDGE funding proposal should be written.
-
-\section*{Meeting 27.02.2020}
-Present at the Meeting were: Dominik Meister, Dennis Neufeld and Christian
Grothoff.
-\subsection*{Reflection}
-The main topic of the meeting was the BRIDGE proposal which is due at the 9th
of March. Additionally we discussed the documents and plan we created.
-\subsection*{Next Steps}
-The next steps are the completion of the BRIDGE proposal.
-
-\section*{Meeting 05.03.2020}
-Present at the Meeting were: Dominik Meister, Dennis Neufeld and Christian
Grothoff.
-\subsection*{Reflection}
-In this meeting the main topic was the finalization of the BRIDGE proposal. We
also discussed the related work and Business model of Anastasis.
-Through the extensive work on the BRIDGE proposal the development has not
continued very fast. But we already could write key parts for the Bachelor
thesis.
-\subsection*{Next Steps}
-Next is the completion and delivery of the BRIDGE proposal.
-
-\section*{Meeting 12.03.2020}
-Present at the Meeting were: Dominik Meister, Dennis Neufeld and Christian
Grothoff.
-\subsection*{Reflection}
-The BRIDGE proposal was sent and we can now focus on the development. We did
not estimate that the proposal would be this time consuming. We are now a bit
behind our task schedule.
-\subsection*{Next Steps}
-Completion of the Anastasis Client API tests and start of the implementation
of the crypto library.
-
-\section*{Meeting 19.03.2020}
-Present at the Meeting were: Dominik Meister, Dennis Neufeld and Christian
Grothoff.
-\subsection*{Reflection}
-We ran into problems while testing the Anastasis client API, the development
is slow at the moment because the bugfixing takes a lot of time.
-We also have made some design mistakes in the crypto API which needed to be
fixed.
-\subsection*{Next Steps}
-Completion of the Anastasis Client API tests and continue on the
implementation of the crypto library.
-
-\section*{Meeting 26.03.2020}
-Present at the Meeting were: Dominik Meister, Dennis Neufeld and Christian
Grothoff.
-\subsection*{Reflection}
-We ran into a lot of problems and decided to make more frequent meetings. We
need to fix some design issues, the imports
-of the different files are done wrong. Additionally we need to be more clear
with the names.
-We need to focus more on the implementation and be more precise with the
documentation.
-\subsection*{Next Steps}
-Implementation of the Crypto library, fix issues mentioned.
-
-\section*{Meeting 30.03.2020}
-Present at the Meeting were: Dominik Meister, Dennis Neufeld and Christian
Grothoff.
-\subsection*{Reflection}
-We could fix the issues from the last meetings and are now in the development
of the crypto library.
-We had some problems with pointers which we could discuss and fix. We are
happy that we can see progress.
-\subsection*{Next Steps}
-Implementation of the Crypto library, finishing API.
-
-\section*{Meeting 02.04.2020}
-Present at the Meeting were: Dominik Meister, Dennis Neufeld and Christian
Grothoff.
-\subsection*{Reflection}
-Dennis is still fixing issues with the API communication, the process is very
time consuming and
-we are pretty behind. Dominik was sick for some days and was not able to work
for the project. We are now
-pretty behind our task schedule and need to work harder.
-\subsection*{Next Steps}
-Implementation of the Crypto library, finishing API.
-
-\section*{Meeting 06.04.2020}
-Present at the Meeting were: Dominik Meister, Dennis Neufeld and Christian
Grothoff.
-\subsection*{Reflection}
-We could finally fix the API's and can now focus on the planned components. We
also found some bugs in payment
-process we need to fix.
-\subsection*{Next Steps}
-Implementation Crypto library and testing
-
-\section*{Meeting 09.04.2020}
-Present at the Meeting were: Dominik Meister, Dennis Neufeld and Christian
Grothoff.
-\subsection*{Reflection}
-We found some errors in our specification regarding the Key Shares. We are
currently still in the development of
-Crypto library tests. The development is very slow because we have some
problems with the pointers in C.
-\subsection*{Next Steps}
-Implementation Crypto library tests, work on Anastasis client
-
-\section*{Meeting 13.04.2020}
-Present at the Meeting were: Dominik Meister, Dennis Neufeld and Christian
Grothoff.
-\subsection*{Reflection}
-We are still in the development of the Crypto library tests. The problems are
mostly the handling of
-the data. We had some problems with the datatypes and the conversions.
-\subsection*{Next Steps}
-Implementation Crypto library testing, work on the Anastasis client.
-
-\section*{Meeting 16.04.2020}
-Present at the Meeting were: Dominik Meister, Dennis Neufeld and Christian
Grothoff.
-\subsection*{Reflection}
-We could not finish the crypto library jet and had problems with the json
objects we need to
-handle inside the crypto library. The development of the Anastasis client is
also slow, since
-it is a very complex part which needs to integrate all other components.
-\subsection*{Next Steps}
-Finish Crypto library testing, implementation Anastasis client
-
-\section*{Meeting 24.04.2020}
-Present at the Meeting were: Dominik Meister, Dennis Neufeld and Christian
Grothoff.
-\subsection*{Reflection}
-We still have some bugs in the crypto library. We should focus that the
application
-is not crashing if something unexpected happens, the application should
continue.
-Additionally there were some security issues in the code we need to fix.
-The development of this component is very complex and needs a lot of time, we
-hope that we soon can finish the crypto library. Also the development of the
Anastasis
-client is finished we can now start with the testing.
-\subsection*{Next Steps}
-Finish Crypto library testing, implementation Anastasis client tests
-
-\section*{Meeting 27.04.2020}
-Present at the Meeting were: Dominik Meister, Dennis Neufeld and Christian
Grothoff.
-\subsection*{Reflection}
-After some final optimization the crypto library of Anastasis is finished. We
can now focus
-on the tests of the client API. This will show if the whole flow of the
application works as
-intended.
-\subsection*{Next Steps}
-Implementation Anastasis client tests
-
-\section*{Meeting 30.04.2020}
-Present at the Meeting were: Dominik Meister, Dennis Neufeld and Christian
Grothoff.
-\subsection*{Reflection}
-The testing of the Anastasis client API is progressing slowly. We could find a
lot of bugs
-in the other components we were not able to see with our previous testing. We
needed to
-fix some of the protocol flows. We hope that we can finish the client as soon
as possible
-since we also need to implement the authentication procedure and the command
line application.
-\subsection*{Next Steps}
-Implementation Anastasis client tests and start working on the authentication
backend
-
-\section*{Meeting 04.05.2020}
-Present at the Meeting were: Dominik Meister, Dennis Neufeld and Christian
Grothoff.
-\subsection*{Reflection}
-We continued the work on the Anastasis client API and the authentication
backend,
-we still found problems in the other components.
-To finish the Anastasis client we will need the authentication backend. So we
decided to implement the most basic authentication, secure question.
-We also still have some issues with our naming conventions which are not
always clear.
-\subsection*{Next Steps}
-Finish implementation Anastasis client tests and authentication backend
-
-\section*{Meeting 07.05.2020}
-Present at the Meeting were: Dominik Meister, Dennis Neufeld and Christian
Grothoff.
-\subsection*{Reflection}
-We could finish the authentication backend and now need to implement the
client logic for the authentication.
-We also need to finish the client tests. We have roughly one month left to
finish the project, we started to
-think that we can't develop a complex authentication method. We planned that
we first will finish the rest
-and afterwards look if we have time to implement a different authentication
method.
-\subsection*{Next Steps}
-Finish client API and tests
-
-\section*{Meeting 11.05.2020}
-Present at the Meeting were: Dominik Meister, Dennis Neufeld and Christian
Grothoff.
-\subsection*{Reflection}
-In the last couple days we could make good progress we managed to nearly
finish the Anastasis client API tests.
-For the most part the components are working. We think that we can finish this
project within the time without the
-complex authentication method.
-\subsection*{Next Steps}
-Finish client API and tests
-
-\section*{Meeting 14.05.2020}
-Present at the Meeting were: Dominik Meister, Dennis Neufeld and Christian
Grothoff.
-\subsection*{Reflection}
-%Something unexpected happened this week. We applied for funding last semester
and were rejected.
-%But we were informed that we can still present our work. Therefore we have to
prepare a business
-%pitch in the next few days. This will be quite stressfull since we are also
behind in our development.
-We are still behind in our development.
-Nevertheless, industry interest suggests we should prepare a business pitch.
-
-\subsection*{Next Steps}
-%Prepare business pitch and
-finish client API
-
-\section*{Meeting 18.05.2020}
-Present at the Meeting were: Dominik Meister, Dennis Neufeld and Christian
Grothoff.
-\subsection*{Reflection}
-The last couple of days were quite stressful but we manged to complete the
Anastasis client tests. This
-means our application flow is working. This is a huge relief.
-%We also have to finish the business pitch which is held
-%tomorow.
-\subsection*{Next Steps}
-Finish business pitch, start developing Anastasis CLI, write bachelor book,
create bachelor poster
-
-\section*{Meeting 21.05.2020}
-Present at the Meeting were: Dominik Meister, Dennis Neufeld and Christian
Grothoff.
-\subsection*{Reflection}
-The development of the Anastasis CLI went very fast, since all the other
components are working correctly.
-The Anastasis splitter and assembler are nearly finished. We also created the
bachelor book article and the poster.
-Both of these still need some adjustments.
-\subsection*{Next Steps}
-Finish Anastasis splitter and assembler, start to finish documentation, fix
book and poster
-
-\section*{Meeting 28.05.2020}
-Present at the Meeting were: Dominik Meister, Dennis Neufeld and Christian
Grothoff.
-\subsection*{Reflection}
-We nearly could finish the Anastasis CLI and can now start to focus on the
documentation.
-We already have a lot of documentation available which needs to be put
together in one document.
-%We also succeeded in the proposal we sent, we are very happy that we can
continue our work on Anastasis after the thesis.
-Additionally the book abstract and the poster are finished and we could
deliver them.
-\subsection*{Next Steps}
-Work on documentation
-
-\section*{Meeting 04.06.2020}
-Present at the Meeting were: Dominik Meister, Dennis Neufeld and Christian
Grothoff.
-\subsection*{Reflection}
-There is only one week left, our document is nearly finished. We discussed
which last sections need to be added. The thesis overall is now in a nearly
finished state, there are some minor problems with the illustrations and the
text which should be easy fixed.
-
-\subsection*{Next Steps}
-Fix illustrations, rework client client documentation
-
-\section*{Meeting 08.06.2020}
-Present at the Meeting were: Dominik Meister, Dennis Neufeld and Christian
Grothoff.
-\subsection*{Reflection}
-This is the second last meeting of our thesis. We discussed the last changes
which need to be done. The text is completed, we decided that we could add more
illustrations to give a better understanding of the document. We are very proud
of our work and think that we have done a good job.
-\subsection*{Next Steps}
-Add illustration for key flow, rework some minor inconsistencies
-
-\section*{Meeting 11.06.2020}
-Present at the Meeting were: Dominik Meister, Dennis Neufeld and Christian
Grothoff.
-\subsection*{Reflection}
-This was the last meeting of our bachelor thesis. We fixed the last pieces in
the documentation and sent the thesis. We are very happy with the final result.
-\subsection*{Next Steps}
--
diff --git a/doc/thesis/abstract.tex b/doc/thesis/abstract.tex
deleted file mode 100644
index d34c9c0..0000000
--- a/doc/thesis/abstract.tex
+++ /dev/null
@@ -1,29 +0,0 @@
-\phantomsection
-\begin{abstract}
-%\addcontentsline{toc}{section}{Abstract} % Usually not in TOC
-
-
-This thesis describes the design and implementation of Anastasis, a
-Free Software key escrow system that offers a practical way for
-ordinary users to bridge the conflicting requirements of keeping key
-material confidential and also available.
-
-Anastasis fills this gap by providing a solution for secure recovery
-of secret keys, which works without passwords or other key
-material. This is achieved by splitting the key material across
-multiple independent Anastasis service providers, and enabling users
-to recover their master key by authenticating with each provider. Our
-protocol ensures that --- without prior knowledge --- the service
-providers learn nothing from the protocol except the minimum amount of
-data required to authenticate the user. Even that information is only
-disclosed at the time of authentication. Anastasis offers users
-control over the set of escrow providers, selection of authentication
-methods and desired policies for key recovery.
-
-Many cryptographic protocols rely on keys being both kept secret, but
-also available for data processing. This thesis will highlight
-application domains for Anastasis and explore how to build a business
-around Anastasis.
-
-
-\end{abstract}
diff --git a/doc/thesis/acknowledgments.tex b/doc/thesis/acknowledgments.tex
deleted file mode 100644
index 4f0a46c..0000000
--- a/doc/thesis/acknowledgments.tex
+++ /dev/null
@@ -1,7 +0,0 @@
-\section*{Acknowledgements}
-%\addcontentsline{toc}{section}{Acknowledgements}
-We wish to thank Christian Grothoff for the help and support he has provided
throughout our work on Anastasis. He helped us resolve bugs and provided us
feedback for the development. Additionally he helped us to edit our bachelor
thesis documents.\\
-We want to thank Pierre-Yves Voirol for agreeing to serve as an expert for the
thesis.
-We also wish to thank the GNU Taler team, Vaishnavi Mohan, Nana Karlstetter
and Leon Schumacher which supported us writing and presenting a funding
proposal.
-Additionally, we want to thank Florian Dold which gave us feedback for our
REST API documentation.\\
-We also want to thank Emmanuel Benoist for providing us the paper for MIDATA.
diff --git a/doc/thesis/bibliothek.bib b/doc/thesis/bibliothek.bib
deleted file mode 100644
index 8d8789a..0000000
--- a/doc/thesis/bibliothek.bib
+++ /dev/null
@@ -1,407 +0,0 @@
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%% File : thesis.bib
-%% Date : Saturday Sep 15 15:54:56 2018
-%% Author : Dominik Meister, Dennis Neufeld
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%% Description : Sample bibliography file
-%% WARNING : To be used with biblatex and biber, this file should be
-%% UTF-8 encoded
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%% Usage :
-%% 1) add the lines in the preamble of your document:
-%% \usepackage[backend=biber, style=ieee]{biblatex}
-%% \addbibresource{template.bib}
-%%
-%% 2) Compile the document at least once (preferably with lualatex), e.g.
-%% lualatex template.tex
-%%
-%% 3) Run the command "biber" on your document, e.g.
-%% biber template
-%%
-%% 4) Compile the document twice with lualatex
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-@online{global_data_index,
- title = {Global Data Protection Index 2018 – Key Findings},
- organization = {Dell EMC.},
- year = 2018,
- urldate = {2020-03-07},
- url =
{https://www.delltechnologies.com/content/dam/uwaem/production-design-assets/en/gdpi/assets/infographics/dell-gdpi-vb-key-findings-deck.pdf)},
-}
-@online{gnu_taler,
- title = {GNU Taler: Features},
- organization = {Taler Systems SA},
- year = 2020,
- urldate = {2020-06-02},
- url = {https://taler.net/en/features.html},
-}
-@online{postgresql,
- title = {PostgreSQL: The World's Most Advanced Open Source
Relational Database},
- organization = {The PostgreSQL Global Development Group},
- year = 2020,
- urldate = {2020-06-02},
- url = {https://www.postgresql.org/},
-}
-@online{libmicrohttpd,
- title = {GNU Libmicrohttpd},
- organization = {GNU project},
- year = 2020,
- urldate = {2020-06-02},
- url = {https://www.gnu.org/software/libmicrohttpd/?},
-}
-@online{gnu_project,
- title = {What is GNU?},
- organization = {GNU project},
- year = 2020,
- urldate = {2020-06-02},
- url = {https://www.gnu.org/},
-}
-@online{libcurl,
- title = {libcurl - the multiprotocol file transfer library },
- organization = {Curl},
- year = 2020,
- urldate = {2020-06-02},
- url = {https://curl.haxx.se/libcurl/},
-}
-@online{ccc_merkel,
- title = {CCC-Tüftler hackt Merkels Iris und von der Leyens
Fingerabdruck},
- author = {Stefan Krempl},
- organization = {heise online},
- year = 2014,
- urldate = {2020-03-07},
- url =
{https://www.heise.de/security/meldung/31C3-CCC-Tueftler-hackt-Merkels-Iris-und-von-der-Leyens-Fingerabdruck-2506929.html},
-}
-@online{millions_lost,
- title = {Bitcoin: Millions of dollars of cryptocurrency 'lost'
after man dies with only password},
- author = {Anthony Cuthbertson},
- organization = {INDEPENDENT},
- year = 2019,
- urldate = {2020-03-07},
- url =
{https://www.independent.co.uk/life-style/gadgets-and-tech/news/bitcoin-exchange-quadrigacx-password-cryptocurrency-scam-a8763676.html},
-}
-@online{forgot_my_pin,
- title = {I Forgot My PIN’: An Epic Tale of Losing \$30,000 in
Bitcoin},
- author = {Mark Frauenfelder},
- organization = {WIRED},
- year = 2017,
- urldate = {2020-03-07},
- url =
{https://www.wired.com/story/i-forgot-my-pin-an-epic-tale-of-losing-dollar30000-in-bitcoin/},
-}
-@inproceedings{pedersen_sharing_0,
- title={Non-interactive and information-theoretic secure verifiable secret
sharing},
- author={Pedersen, Torben Pryds},
- booktitle={Annual international cryptology conference},
- pages={129--140},
- year=1991,
- organization={Springer},
- chapter={0},
-}
-@inproceedings{pedersen_sharing_5.2,
- title={Non-interactive and information-theoretic secure verifiable secret
sharing},
- author={Pedersen, Torben Pryds},
- booktitle={Annual international cryptology conference},
- pages={129--140},
- year=1991,
- organization={Springer},
- chapter={5.2},
-}
-@article{shamir_sharing,
- title={How to share a secret},
- author={Shamir, Adi},
- journal={Communications of the ACM},
- volume={22},
- number={11},
- pages={612--613},
- year=1979,
- publisher={ACm New York, NY, USA},
-}
-@inproceedings{feldman_sharing,
- title={A practical scheme for non-interactive verifiable secret sharing},
- author={Feldman, Paul},
- booktitle={28th Annual Symposium on Foundations of Computer Science (sfcs
1987)},
- pages={427--438},
- year=1987,
- organization={IEEE},
-}
-@article{authentication_methods_review,
- title = {A Review on Authentication Methods},
- author = {Syed Idrus, Syed Zulkarnain and Cherrier, Estelle and Rosenberger,
Christophe and Schwartzmann, Jean-Jacques},
- url = {https://hal.archives-ouvertes.fr/hal-00912435},
- journal = {Australian Journal of Basic and Applied Sciences},
- volume = {7},
- number = {5},
- pages = {95-107},
- year = 2013,
-}
-@book{rieck_detection,
- title={Detection of Intrusions and Malware, and Vulnerability Assessment:
10th International Conference, DIMVA 2013, Berlin, Germany, July 18-19, 2013.
Proceedings},
- author={Rieck, Konrad and Stewin, Patrick and Seifert, Jean-Pierre},
- volume={7967},
- year=2013,
- publisher={Springer}
-}
-@article{biometric_auth,
- title={Privacy-preserving biometric authentication: challenges and
directions},
- author={Pagnin, Elena and Mitrokotsa, Aikaterini},
- journal={Security and Communication Networks},
- volume={2017},
- year=2017,
- publisher={Hindawi}
-}
-@article{multifactor_authentication,
- title={Multi-factor authentication: A survey},
- author={Ometov, Aleksandr and Bezzateev, Sergey and Makitalo, Niko and
Andreev, Sergey and Mikkonen, Tommi and Koucheryavy, Yevgeni},
- journal={Cryptography},
- volume={2},
- number={1},
- pages={1},
- year=2018,
- publisher={Multidisciplinary Digital Publishing Institute}
-}
-@book{midata,
- title={Applied Approach to Privacy and Security for the Internet of Things},
- author={Parag Chatterjee, Emmanuel Benoist and Asoke Nath},
- year={in print},
- publisher={IGI Global}
-}
-@Inbook{Preneel1999,
- author={Preneel, Bart},
- editor={Damg{\aa}rd, Ivan Bjerre},
- title={The State of Cryptographic Hash Functions},
- bookTitle={Lectures on Data Security: Modern Cryptology in Theory and
Practice},
- year=1999,
- publisher={Springer Berlin Heidelberg},
- address={Berlin, Heidelberg},
- pages={158},
- abstract={This paper describes the state of the art for cryptographic hash
functions. Different definitions are compared, and the few theoretical results
on hash functions are discussed. A brief overview is presented of the most
important constructions, and some open problems are presented.},
- isbn={978-3-540-48969-6},
- doi={10.1007/3-540-48969-X_8},
- url={https://doi.org/10.1007/3-540-48969-X_8}
-}
-@article{SG2012,
- title={Cryptographic hash functions: a review},
- author={Sobti, Rajeev and Geetha, G},
- journal={International Journal of Computer Science Issues (IJCSI)},
- volume={9},
- number={2},
- pages={462},
- year=2012,
- publisher={International Journal of Computer Science Issues (IJCSI)}
-}
-@article{BCK1996,
- title={Message authentication using hash functions: The HMAC construction},
- author={Bellare, Mihir and Canetti, Ran and Krawczyk, Hugo},
- journal={RSA Laboratories’ CryptoBytes},
- volume={2},
- number={1},
- pages={12--15},
- year=1996
-}
-@inproceedings{krawczyk2010,
- title={Cryptographic extraction and key derivation: The HKDF scheme},
- author={Krawczyk, Hugo},
- booktitle={Annual Cryptology Conference},
- pages={631--648},
- year={2010},
- organization={Springer}
-}
-@inproceedings{BDK2016,
- title={Argon2: new generation of memory-hard functions for password hashing
and other applications},
- author={Biryukov, Alex and Dinu, Daniel and Khovratovich, Dmitry},
- booktitle={2016 IEEE European Symposium on Security and Privacy (EuroS\&P)},
- pages={292--302},
- year={2016},
- organization={IEEE}
-}
-@book{trimberger2012,
- title={Field-programmable gate array technology},
- author={Trimberger, Stephen M},
- year={2012},
- publisher={Springer Science \& Business Media}
-}
-@misc{madurawe2006,
- title={Alterable application specific integrated circuit (ASIC)},
- author={Madurawe, Raminda Udaya},
- year={2006},
- month=6,
- publisher={Google Patents},
- note={US Patent 7,064,579}
-}
-@article{stamp2003,
- title={Once upon a time-memory tradeoff},
- author={Stamp, Mark},
- journal={San Jose State University, Department of Computer Science},
- year={2003}
-}
-@article{vadhan2012,
- title={Pseudorandomness},
- author={Vadhan, Salil P and others},
- journal={Foundations and Trends{\textregistered} in Theoretical Computer
Science},
- volume={7},
- number={1--3},
- pages={1--336},
- year={2012},
- publisher={Now Publishers, Inc.}
-}
-@inproceedings{nielsen2002,
- title={A threshold pseudorandom function construction and its applications},
- author={Nielsen, Jesper Buus},
- booktitle={Annual International Cryptology Conference},
- pages={401--416},
- year={2002},
- organization={Springer}
-}
-@article{GGM1986,
- author = {Goldreich, Oded and Goldwasser, Shafi and Micali, Silvio},
- title = {How to Construct Random Functions},
- year = {1986},
- issue_date = {Oct. 1986},
- publisher = {Association for Computing Machinery},
- address = {New York, NY, USA},
- volume = {33},
- number = {4},
- issn = {0004-5411},
- url = {https://doi.org/10.1145/6490.6503},
- doi = {10.1145/6490.6503},
- journal = {J. ACM},
- month = aug,
- pages = {792–807},
- numpages = {16}
-}
-@article{RK2011,
- title={Designing an algorithm with high Avalanche Effect},
- author={Ramanujam, Sriram and Karuppiah, Marimuthu},
- journal={IJCSNS International Journal of Computer Science and Network
Security},
- volume={11},
- number={1},
- pages={106--111},
- year={2011}
-}
-@inproceedings{GJW2011,
- title={SHA-512/256},
- author={Gueron, Shay and Johnson, Simon and Walker, Jesse},
- booktitle={2011 Eighth International Conference on Information Technology:
New Generations},
- pages={354--358},
- year={2011},
- organization={IEEE}
-}
-@article{just2004,
- title={Designing and evaluating challenge-question systems},
- author={Just, Mike},
- journal={IEEE Security \& Privacy},
- volume={2},
- number={5},
- pages={32--39},
- year={2004},
- publisher={IEEE}
-}
-@inproceedings{MBSS2013,
- title={SMS-based one-time passwords: attacks and defense},
- author={Mulliner, Collin and Borgaonkar, Ravishankar and Stewin, Patrick and
Seifert, Jean-Pierre},
- booktitle={International Conference on Detection of Intrusions and Malware,
and Vulnerability Assessment},
- pages={150--159},
- year={2013},
- organization={Springer}
-}
-@article{pohlmann2017,
- title={Wenn der Softbot menschliche Identit{\"a}t best{\"a}tigt.
Videoident-Verfahren II: Die Technik},
- author={Pohlmann, Norbert and Frintrop, Jan-Hendrik and Widdermann, Rick and
Ziegler, Tim},
- year={2017}
-}
-@book{garfinkel1995,
- title={PGP: pretty good privacy},
- author={Garfinkel, Simson},
- year={1995},
- publisher={" O'Reilly Media, Inc."}
-}
-@inproceedings{LLLW*2017,
- title={An efficient method to enhance Bitcoin wallet security},
- author={Liu, Yi and Li, Ruilin and Liu, Xingtong and Wang, Jian and Zhang,
Lei and Tang, Chaojing and Kang, Hongyan},
- booktitle={2017 11th IEEE International Conference on Anti-counterfeiting,
Security, and Identification (ASID)},
- pages={26--29},
- year={2017},
- organization={IEEE}
-}
-@online{emailauthowasp,
- title = {Forgot Password Cheat Sheet},
- organization = {OWASP Foundation},
- year = 2020,
- urldate = {2020-06-05},
- url =
{https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html},
-}
-@online{pepdoc,
- title = {Welcome to p≡p Documentation!},
- organization = {pEp Security SA},
- year = 2020,
- urldate = {2020-06-06},
- url = {https://www.pep.security/docs/},
-}
-@online{coinbase,
- title = {Backup your encrypted private keys on Google Drive and
iCloud with Coinbase Wallet},
- organization = {Coinbase},
- year = 2020,
- urldate = {2020-06-06},
- url =
{https://blog.coinbase.com/backup-your-private-keys-on-google-drive-and-icloud-with-coinbase-wallet-3c3f3fdc86dc},
-}
-@online{bitcoin-keys,
- title = {BIP 32 - Hierarchical Deterministic Wallets},
- organization = {Bitcoin},
- year = 2020,
- urldate = {2020-06-06},
- url =
{https://github.com/bitcoin/bips/blob/master/bip-0032/derivation.png},
-}
-@online{bitlocker,
- title = {BitLocker},
- organization = {Microsoft},
- year = 2020,
- urldate = {2020-06-06},
- url =
{https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-overview},
-}
-@article{bajikar2002,
- title={Trusted platform module (tpm) based security on notebook pcs-white
paper},
- author={Bajikar, Sundeep},
- journal={Mobile Platforms Group Intel Corporation},
- volume={1},
- pages={20},
- year={2002}
-}
-@article{marlinspike2011,
- title={SSL and the future of authenticity},
- author={Marlinspike, Moxie},
- journal={Black Hat USA},
- volume={6},
- year={2011}
-}
-@article{jerome2015,
- title={AHV-Nummer als einheitlicher, organisations{\"u}bergreifender
Personenidentifikator},
- author={J{\'e}r{\^o}me, Brugger and Angelina, BFH Dungga and Esther, BFH
Hefti and ZH, Kt},
- year={2015},
- organization={BFH}
-}
-@inproceedings{caronni2000,
- title={Walking the web of trust},
- author={Caronni, Germano},
- booktitle={Proceedings IEEE 9th International Workshops on Enabling
Technologies: Infrastructure for Collaborative Enterprises (WET ICE 2000)},
- pages={153--158},
- year={2000},
- organization={IEEE}
-}
-@article{heron2009,
- title={Advanced encryption standard (AES)},
- author={Heron, Simon},
- journal={Network Security},
- volume={2009},
- number={12},
- pages={8--12},
- year={2009},
- publisher={Elsevier}
-}
-@inproceedings{josefsson2017,
- title={Edwards-curve digital signature algorithm (EdDSA)},
- author={Josefsson, Simon and Liusvaara, Ilari},
- booktitle={Internet Research Task Force, Crypto Forum Research Group, RFC},
- volume={8032},
- year={2017}
-}
-
-
diff --git a/doc/thesis/business_model.tex b/doc/thesis/business_model.tex
deleted file mode 100644
index bfc2646..0000000
--- a/doc/thesis/business_model.tex
+++ /dev/null
@@ -1,217 +0,0 @@
-\section{Business model}
-
-We are currently in the process of building a start-up for the
-Anastasis application. This business model shows an overview how we
-want to build our start-up and how we want to continue our work on the
-project.
-
-\subsection{Executive summary}
-
-Users of cryptography are frequently facing the challenge to secure
-their core secrets (private keys), and the contemporary default of
-asking them to remember strong passphrases is inadequate for mass
-adoption. The loss of such a core secret can cause severe damage for a
-user. Our project was conceived as a solution to similar problems
-several privacy enhancing software projects are facing
-today. Specifically, the Swiss Pretty Easy Privacy
-project\footnote{\url{https://pep.foundation/}}, an E-Mail encryption
-solution which needs an easy way for users to recover their private
-keys to avoid the loss of encrypted E-Mails. The GNU Taler team is
-building an electronic payment system and is facing an equivalent
-challenge: the European Central Bank informed them about a requirement
-for electronic wallets denominated in Euros to support password-less
-data recovery. We designed Anastasis to address this common problem
-of cryptographic consumer products. Within our bachelor thesis we
-could build a working prototype of the application. But this
-application is not a finished product. Within the thesis we only could
-implement rudimentary authentication methods. To satisfy the
-requirements of our industry partners we need to have several
-different authentication methods implemented. Additionally, the
-Anastasis environment will need proper automatization. Specifically,
-monitoring of the integration with external authentication providers,
-the correct operation of the backup mechanism and the business
-logic. To make Anastasis ready for public usage we estimate the need
-of an additional year of development. The resulting start-up would
-initially receive B2B revenue from companies that need our solution
-for their cryptographic consumer product. In addition to Taler and PEP
-we are in discussion with developers of crypto currencies from Zug and
-Lausanne. Subsequently these contacts would evolve into distribution
-channels, and Anastasis would eventually earn money directly from its
-users. Cryptographic solutions which are not open to the public are
-not trustworthy. As seen lately with the Crypto AG. Experts recommend
-to only use Free and Libre Open Source Software (FLOSS) especially for
-cryptography. Therefore, Anastasis is licensed under the Affero GPL
-which will prevent other companies from creating or operating
-proprietary forks. Being first to market and thus the default
-provider in various consumer products will be a key business
-advantage.
-
-\subsection{Market review and innovation potential}
-
-There are already some key recovery or key splitting solutions on the
-market. For example, there is a solution from Coinbase. Coinbase is a
-global digital asset exchange company, providing a venue to buy and
-sell digital currencies. Coinbase also uses wallets secured with
-private keys. To recover this private key the user has to provide a 12
-words recovery phrase. Coinbase now offers a solution to securely
-deposit this recovery phrase onto the users Google Drive. The security
-here lies within the Google Account and the password used to encrypt
-the security phrase~\cite{coinbase}. The problem here is that this approach
undermines
-confidentiality. It exchanges a hard to guess password with a shorter
-and easier to guess password. The difficulty is to simultaneously
-assure availability and confidentiality, instead of trading one for
-the other. By allowing citizens to simultaneously achieve
-confidentiality and availability we improve their ability to exercise
-their right to informational self-determination.
-
-Today information losses from security incidents are rampant, either
-because data is exposed (loss of confidentiality) or because users
-lose their data because of lacking backups (loss of availability). As
-seen in the study of the Global Data Protection Index
-2018~\cite{global_data_index}, 76\% of those interviewed had an
-availability incident. 1TB of data loss or 20 hours of downtime
-reportedly costs half a million dollars. On the other hand, loss of
-confidential private data can result in fines under data protection
-regulation, as well as a difficult to quantify loss of reputation.
-Prominent cases in which sometimes enormous amounts of money have been
-gone useless by losing the key to the digital wallet clarify the
-urgent need of a key recovery system like Anastasis. For example the
-case QuadrigaCX exchange was heavily discussed in the media when the
-chief executive, Gerald Cotton, unexpectedly died and left £145
-million in a “cold wallet”.~\cite{millions_lost}
-
-In some cases there is a workaround to recover a lost key, provided
-there is a security hole in the digital wallet software that can be
-exploited, but it is far from user friendly and also questions the
-confidentiality of data in such a system. In his article “’I Forgot My
-PIN’: An Epic Tale of Losing \$30,000 in Bitcoin” \cite{forgot_my_pin}
-Mark Frauenfelder, a former editor at WIRED and the director of
-research at the Institute of the Future’s Blockchain Futures Lab,
-writes about his experiences in losing and trying to recover his
-wallet key.
-
-\subsection{Business model canvas}
-
-\subsubsection{Key partners}
-
-Our key partners for Anastasis are three entities. First the business
-partners, Taler Systems SA and p$\equiv$p Foundation, with whom we could
-already make contracts and wish to integrate our product. Second are
-the providers of Cloud services. To operate Anastasis with minimal
-cost we need the service of these providers. These providers can
-additionally provide us authentication services, this also minimizes
-the complexity of our solution since we do not have to implement these
-services by ourselves. Such a provider could be for example Amazon
-AWS, Azure, Google.
-
-In addition to these industry partners, we also count on the continued
-support by the BFH for hosting and mentoring. Prof. Dubius has already
-agreed to serve on our advisory board, and Prof. Grothoff would be
-happy to serve as non-executive chairman for the company.
-
-\subsubsection{Key activities}
-
-The main work of our start up is the completion of our software for
-commercial use. This involves the integration of different
-authentication methods and the integration of our application into the
-different consumer applications. Another key activity is the
-maintenance and deployment of our service.
-
-\subsubsection{Key resources}
-
-Our developers need a device to work with, we agreed to the policy to
-“bring your own device” this means the start-up does not have to
-invest in hardware. To operate our application, we will need servers
-to provide our service, as previously mentioned we would provide our
-service on a Cloud provider. For the timely further development of
-our service and integration with various authentication providers,
-payment solutions and applications needing key recovery, we see an
-initial need for at least two fulltime employees. These developers
-would also be responsible for the maintenance and deployment of the
-application.
-
-Additionally, the start-up needs a person who is responsible for the
-business of Anastasis. This employee would be responsible to find new
-business partners and present our application to investors. This
-employee might initially work only part-time. To be able to properly
-launch the start-up, we are hoping to find a combination of investors
-and grants.
-
-\subsubsection{Value propositions}
-
-As mentioned earlier there are many applications which need a key
-recovery system. Anastasis is also a privacy friendly and transparent
-solution. Furthermore, Anastasis will make sure that the application
-is user friendly and inexpensive.
-
-\subsubsection{Customer relationships}
-
-In the early stages of our start-up our customers are primary going to
-be business customers like Taler Systems SA, p$\equiv$p Foundation,
-Fraunhofer AISEC and NymTech, which all want to integrate our solution
-into their products. Thus, early on we will likely pursue B2B sales,
-lining up businesses that would want to integrate Anastasis with
-existing security products.
-
-Once successful products exist in the market, our revenue should
-inherently shift to a B2C model, as then customers will pay for the
-recovery service. We may then also ourselves invest in integration of
-Anastasis with further software solutions to grow the business, even
-in domains where there is no significant business partner. This will
-be the case for applications where popular non-commercial solutions
-are freely available. An example for this domain would be consumer
-software that enables disk encryption.
-
-\subsubsection{Customer segments}
-
-Our business customers will be primarily developers of security
-applications which need a way to enable end-users to securely
-backup end-user key material.
-
-End-users paying for the recovery service will be all users using
-privacy-enhancing technologies, where the putting the user in charge
-of their data also burdens the user with taking care of their private
-keys. Specific applications include payment services including
-crypto-currencies and end-to-end encrypted communication services.
-
-\subsubsection{Cost structure}
-
-The main cost for our start-up is the salary of our employees. We need
-to have two or more fulltime employees for the development and one
-part time employee for the business development. Additional costs for
-the start-up are the costs for registering a company. To provide
-Anastasis as a service, we expect to make use of existing public Cloud
-services, which also cost a little bit.
-
-\subsubsection{Revenue streams}
-
-In the beginning, businesses like Taler Systems SA will pay us to
-operate an Anastasis server and to help them integrate our protocol
-with their software. Once we have many end-users utilizing Anastasis,
-they will have to pay directly for the service. The users have to pay
-a subscription fee and possibly additional fees for expensive recovery
-operations. For example a user might pay 0.10 CHF per month for the
-subscription and 0.01 CHF for each encrypted truth
-upload. Additionally, the user would have to pay for expensive
-authentication methods like video identification.
-
-\subsection{Project plan}
-
-Our objective for the first year is for Anastasis to implement several
-authentication services, have a working cloud deployment with good
-monitoring, and to be integrated with various cryptographic consumer
-products (Figure~\ref{fig:bi_project_plan}). We plan to hire one
-developer for the integration with external authentication providers
-and monitoring of our cloud deployment, and a second one to focus on
-the integration of Anastasis with consumer products. Key milestones
-are the various integrations of the different authentication methods,
-the integration of cryptographic consumer products, and the deployment
-of our application. Additionally, we would always look out for new
-customers and clients who could benefit from Anastasis.
-
-\begin{figure}[H]
- \centering
- \includegraphics[scale=0.65]{images/project_plan.png}
- \caption{Business project plan}
- \label{fig:bi_project_plan}
-\end{figure}
diff --git a/doc/thesis/client_architecture.tex
b/doc/thesis/client_architecture.tex
deleted file mode 100644
index fb10fd1..0000000
--- a/doc/thesis/client_architecture.tex
+++ /dev/null
@@ -1,309 +0,0 @@
-\subsection{Client architecture}
-
-The Anastasis client architecture consists of two main components. A client
-API which communicates with the server and a command line application
-which interacts with the user. The structure of these two components
-is shown in Figure~\ref{fig:anastasis:client}.
-
-\begin{figure}[H]
- \centering
- \includegraphics[scale=0.6]{images/client_api.png}
- \caption{Anastasis client architecture}
- \label{fig:anastasis:client}
-\end{figure}
-
-The Anastasis client implementation includes three distinctive APIs: a
-{\em Crypto API} which provides the different cryptographic functions,
-a {\em Service API} which sends the request to the server and the {\em
- Client API} which manages the main data structures and provides an
-abstraction for the application.
-
-\subsubsection{Crypto API}
-
-The most important data structures in the crypto API are the following:
-
-\begin{itemize}
- \item
-The kdf\_id is a hash code which was generated with Argon2. The
-entropy source is the user's unforgettable secret. The kdf\_id is used
-to create various key's, for more details see Chapter~\ref{chap:design}.
-
-\begin{lstlisting}
-struct kdf_id
-{
- Hashcode; //512-bit
-}
-\end{lstlisting}
-
-\item
-The account\_private\_key is used to sign the data and check the signature
later. It is a 256-bit EdDSA private key. It is generated with the kdf\_id as
entropy source.
-\begin{lstlisting}
-struct account_private_key
-{
- eddsa_private_key;
-}
-\end{lstlisting}
-
-\item
-The account\_public\_key is used as the user identification on the different
providers. It is generated from the private\_key.
-\begin{lstlisting}
-struct account_public_key
-{
- eddsa_public_key;
-}
-\end{lstlisting}
-
-\item
-The truth\_key is a randomly generated AES-256 GCM key. It is used to encrypt
the user specify data in the truth object.
-\begin{lstlisting}
-struct truth_key
-{
- key; //256-bit
-}
-\end{lstlisting}
-
-\item
-The truth\_seed is a randomly generated nonce with a size of 32 Bytes. It is
used to derive a truth\_private\_key
-and is stored within an encrypted recovery document.
-\begin{lstlisting}
-struct truth_seed
-{
- nonce; //256-bit
-}
-\end{lstlisting}
-
-\item
-The truth\_private\_key is used to sign the encrypted key share and the
encrypted authentication data. It is a 256-bit EdDSA private key. It is
generated with the truth seed as entropy source.
-\begin{lstlisting}
-struct truth_private_key
-{
- eddsa_private_key;
-}
-\end{lstlisting}
-
-The truth\_public\_key is used as the user identification on the different
providers in case of uploaded truths. It is generated from the truth private
key.
- \begin{lstlisting}
-struct truth_public_key
-{
- eddsa_public_key;
-}
-\end{lstlisting}
-
-
-\item
-Anastasis needs different symmetric keys to encrypt data for example, the
recovery document. These symmetric keys are all 256-bit large hashcodes. These
symmetric keys are generated through the key routine defined in Implementation
Key usage.
-\begin{lstlisting}
-struct symmetric_key
-{
- hashcode; //256-bit
-}
-\end{lstlisting}
-
-\item
-Each policy has a separate policy\_key. The key is used to encrypt the
master\_key.
-The policy\_key is also a AES-256 GCM key. It is generated through the
combination of a set of key\_shares.
-\begin{lstlisting}
-struct policy_key
-{
- hashcode; //256-bit
-}
-\end{lstlisting}
-
-\item
-Every truth object contains a key\_share. A key\_share is a 256-bit random
generated bit sequence.
-\begin{lstlisting}
-struct key_share
-{
- hashcode; //256-bit
-}
-\end{lstlisting}
-
-\item
-Before every encryption a random 256-bit large nonce is generated. This gives
the encryption algorithm a random factor.
-\begin{lstlisting}
-struct nonce
-{
- hashcode; //256-bit
-}
-\end{lstlisting}
-
-\item
-To use AES-256 GCM an IV must be generated. It is generated with an HKDF over
a salt the kdf\_id and a symmetric key.
-\begin{lstlisting}
-struct iv
-{
- hashcode; //128-bit
-}
-\end{lstlisting}
-
-\item
-The aes\_tag is generated after each encryption, it is later used to check the
integrity of the data.
-\begin{lstlisting}
-struct aes_tag
-{
- hashcode; //128-bit
-}
-\end{lstlisting}
-\end{itemize}
-
-The functions of the crypto API basically provide the canonical set of
-cryptographic operations (hash, encrypt, decrypt, etc.) over these
-basic data structures.
-
-
-\subsubsection{Client API}
-
-The most important data structures in the client API are the following:
-
-\begin{itemize}
- \item
-The secret share data structure is used to upload a new recovery document.
-\begin{lstlisting}
-struct secret_share
-{
- kdf_id;
- last_etag;
- policies;
- core_secret;
-}
-\end{lstlisting}
-\begin{itemize}
-\item kdf\_id: is used to compute the account public and private key. The hash
is 512bit large.
-\item last\_etag: this hash is sent with the recovery document. The server
will check the hash if the document on the server is the same. This prevents
unnecessary uploads. The hash is 512-bit large.
-\item policies: is a list of all generated policies the user wants to combine
into a recovery document.
-\item core\_secret: is the user provided core secret. This is just a binary
blob so Anastasis does not have a restriction for the user secret. This could
be a for example a private key or a password the user wants to backup.
-\end{itemize}
-
- \item
-The recovery information data structure holds a recovery document. It is
downloaded within the recovery process and stored inside a recovery data
structure.
-\begin{lstlisting}
-struct recovery_information
-{
- struct decryptption_policies;
- struct challenges;
- version;
- salt;
-}
-\end{lstlisting}
-\begin{itemize}
-\item decryption\_policies: holds all available policies within the downloaded
recovery document.
-\item challenges: holds all available authentication methods within the
recovery document.
-\item version: the version of the downloaded recovery document is stored here.
-\item salt: this is the salt used for the generation of the policy keys. The
salt is a 512-bit value.
-\end{itemize}
-
-\item
-The recovery data structure is generated at the start of a secret recovery. It
contains all available policies and lists which challenges are solved. Through
this
-struct the client can check if a policy was solved completely.
-\begin{lstlisting}
-struct recovery
-{
- kdf_id;
- version;
- provider_url;
- salt;
- solved_challenges;
- struct recovery_information;
-}
-\end{lstlisting}
-\begin{itemize}
-\item kdf\_id: is used to compute the account public and private key. The hash
is 512bit large.
-\item version: hold the user desired version he wishes to download. This can
be null then the client downloads the latest version.
-\item provider\_url: the client will download the recovery document from this
provider url.
-\item salt: this is the salt of the provider specified in provider\_url.
-\item solved\_challenges: this is a list of all solved challenges. This list
is updated after each successful authentication. This allows the client to
check if a policy is solved.
-\item recovery\_information: as previously mentioned this data structure holds
the downloaded recover document to process within the recovery
-\end{itemize}
-
-\item
-A truth data structure is used to upload a new authentication method to a
provider. It is identified by the TRUTH\_PUB which the user creates through a
HKDF over the truth\_seed. The truth data structure is only used for the secret
share process and not for the recovery.
-\begin{lstlisting}
-struct truth
-{
- truth_seed;
- method;
- mime_type;
- encrypted_truth;
- encrypted_key_share;
-}
-\end{lstlisting}
-\begin{itemize}
-\item truth\_seed: the truth\_seed is the identification of the truth object.
-It is used as entropy source to generate the TRUTH\_PUB, which later
identificates the truth object. The truth objects are not linked to the user. A
list of these truth\_seeds are stored inside the recovery document, with this
the user data is more anonymous.
-\item method: this defines which method the user chose to configure, for
example SMS, email, secure question.
-\item mime\_type: this defines in which format the truth was safed, for
example jpeg, png, txt, json.
-\item encrypted\_truth: the encrypted truth holds the authentication specific
data. It holds for example the hashed answer and the question. It is encrypted
with the specific truth\_key which is stored inside the recovery\_document.
-\item encrypted\_key\_share: this is the key\_share protected by this truth.
It is encrypted with a key which was derived with the kdf\_id of the user. The
server will later send this key\_share to the user upon successful
authentication.
-\end{itemize}
-\newpage
-\item
-The policy data structure is used to create new policies to combine them into
the recovery document. The policy data structure is only used for the secret
share process.
-\begin{lstlisting}
-struct policy
-{
- truths;
- policy_key;
- salt;
-}
-\end{lstlisting}
-\begin{itemize}
-\item truths: every policy has a set of truths which need to be solved to
recover the policy\_key
-\item policy\_key: the policy\_key is created through the combination of the
different key\_shares within each of the truth objects. It is later used to
encrypt the master\_key.
-\item salt: defines the salt used to create the policy\_key.
-\end{itemize}
-
-\item
-The decryption\_policy data structure is used in the recovery process. It has
slightly different values as the policy structure.
-\begin{lstlisting}
-struct decryption_policy
-{
- truth_seeds;
- encrypted_master_key;
- salt;
-}
-\end{lstlisting}
-\begin{itemize}
-\item truth\_seeds: is a list of truth\_seeds which need to be solved to
recreate the policy key. Each truth\_seed has a corresponding challenge.
-\item encrypted\_master\_key: holds an encrypted version of the master\_key
which was used to encrypt the core secret. In every policy lies the same
master\_key which was encrypted by the specific policy\_key.
-\item salt: defines the salt which was used to create this policy\_key.
-\end{itemize}
-\newpage
-\item
-The challenge data structure is used for the several key\_share lookups.
-We named the process of authentication on the providers as challenges.
-It has slightly different variables as the truth data structure.
-\begin{lstlisting}
-struct challenge
-{
- truth_seed;
- url;
- truth_key;
- method;
- key_share;
- instructions;
-}
-\end{lstlisting}
-\begin{itemize}
-\item truth\_seed: Entropy source to generate the TRUTH\_PUB, which identifies
the challenge on the server.
-\item url: defines the provider URL on which the truth was stored.
-\item truth\_key: this key is sent to the server within the authentication
procedure. The server can decrypt the truth with this key to start the
authentication.
-\item method: defines the method of this challenge, for example email, SMS,
secure question.
-\item key\_share: After each successful authentication the key\_share which
was sent by the server will be saved within this variable. It is later used to
recreate a policy\_key.
-\item instructions: this contains a string with the instructions for the user.
This could for example be:” What is your favourite colour?” or” An SMS was sent
to the number +41...... please provide the pin”.
-\end{itemize}
-\end{itemize}
-
-The functions of the client API basically provide a way to
-backup a core secret by providing user's identity attributes,
-the secret and constructing the policies, as well as a way
-to recover a core secred by providing the user's identity
-attributes and then satisfying the authentication challenges.
-
-
-\subsubsection{Service API}
-
-The service API is responsible for sending the requests to the REST
-API of the server. The client has implemented functions for every
-endpoint.
-For more details see REST API documentation in
-appendix~\ref{appendix_server_api}.
diff --git a/doc/thesis/conclusion.tex b/doc/thesis/conclusion.tex
deleted file mode 100644
index bd95a7d..0000000
--- a/doc/thesis/conclusion.tex
+++ /dev/null
@@ -1,16 +0,0 @@
-\section{Conclusion and outlook}
-
-Anastasis is a privacy-preserving and robust technical solution to the
-problem of key recovery. Open challenges remain in particular with
-respect to usability, as the user experience --- and in particular
-convincing the users that their private data truly remains private
-with Anastasis --- will be crucial for commercial success. While we
-have started to make plans for a graphical user interface, it was not
-possible to conduct actual usability studies in the scope of the
-thesis.
-
-Overall, the thesis was an interesting experience for us. We learned
-much about software development and had our first successful B2B
-interactions. The Anastasis project will not be finished at the end
-of the thesis, but instead we plan to build a start-up to be able to
-launch a proper product around our work on Anastasis.
diff --git a/doc/thesis/design.tex b/doc/thesis/design.tex
deleted file mode 100644
index 650beb1..0000000
--- a/doc/thesis/design.tex
+++ /dev/null
@@ -1,466 +0,0 @@
-\section{Design} \label{chap:design}
-
-Anastasis is a service that allows the user to securely deposit a {\em core
-secret} with an open set of escrow providers and recover it if the
-secret is lost. The core secret itself is protected from the escrow
-providers by encrypting it with a {\em master key}. The main objective of
-Anastasis is to ensure that the user can reliably recover the core
-secret, while making this difficult for everyone else. Furthermore, Anastasis
-supports situations where the user is unable to reliably remember any secret
-with sufficiently high entropy, so Anastasis does not simply encrypt using some
-other key material in exclusive possession of the user.
-
-To uniquely identify users and to provide a first layer of protection,
-an “unforgettable” identifier is used. This identifier should be
-difficult to guess for anybody but the user. However, the identifier
-is not expected to have sufficient entropy or secrecy to be
-cryptographically secure. Examples for such an identifier would be a
-concatenation of the full name of the user and their social security
-or passport number(s). For Swiss citizens, the AHV number could also
-be used.
-
-\subsection{Overview}
-
-The Figure~\ref{fig:legend_keys_anastasis} shows the legend for the
-illustration of the Anastasis key usage shown in
Figure~\ref{fig:keys_anastasis}
-on page~\pageref{fig:keys_anastasis} and in
-Figure~\ref{fig:truth_keys} on page~\pageref{fig:truth_keys}.
-The Figure~\ref{fig:keys_anastasis} gives an overview of the keys used in
Anastasis. It also shows how they are created and used.
-Figure~\ref{fig:truth_keys} shows how the keys to sign the (encrypted) truth
-data used during authentication are generated. The truth seed(s) used in
-Figure~\ref{fig:truth_keys} are part of the recovery document.
-\newline
-\begin{figure}[H]
- \centering
- \includegraphics[scale=0.48]{images/legend_keys_anastasis.png}
- \caption{Legend of Figure~\ref{fig:keys_anastasis}} on
page~\pageref{fig:keys_anastasis}
- \label{fig:legend_keys_anastasis}
-\end{figure}
-
-\begin{figure}[H]
- \centering
- \includegraphics[scale=0.48]{images/keys_anastasis.png}
- \caption{Secrets used in Anastasis}
- \label{fig:keys_anastasis}
-\end{figure}
-
-\noindent In the following the keys shown in the
Figure~\ref{fig:keys_anastasis} on
-page~\pageref{fig:keys_anastasis} are explained:
-
-\begin{description}
- \item[kdf id] {The {\em kdf id} is derived from the user attributes and
a
- randomly generated public and constant salt value provided by the
escrow provider using Argon2. It is used to derive
- the {\em private account key}, the {\em symmetric key 1} and the {\em
symmetric key 2}.}
- \item[private account key] {The {\em private account key} is used to
sign the {\em encrypted
- recovery document}. It is derived from the {\em identity key} using
{\em HKDF-1}}.
- \item[public account key] {The {\em public account key} is derived from
its corresponding
- {\em private account key}. It used to verify the signature of the {\em
encrypted recovery
- document} and also is the identifier of the user which is needed by the
provider.}
- \item[symmetric key 1] {The {\em symmetric key 1} is derived from the
{\em identity key} using
- {\em HKDF-2}. It is used to encrypt and decrypt the {\em encrypted
recovery document} which is stored by
- the provider.}
- \item[symmetric key 2] {The {\em symmetric key 2} is derived from the
{\em identity key} using
- {\em HKDF-3}. It is used to encrypt and decrypt the different {\em
encrypted key shares} which
- are stored by the escrow providers.}
- \item[truth key] {The {\em truth key} is randomly generated for each
{\em encrypted authentication data}
- and is stored within the {\em encrypted recovery document}. It may
later be disclosed by the user to
- the escrow provider to let it decrypt the {\em encrypted
authentication data} which allows the provider
- to then run the recovery authorization process.}
- \item[master key] {The {\em master key} is randomly generated and is
used to encrypt and decrypt the
- {\em encrypted core secret} which is stored within an {\em encrypted
recovery document}. The {\em encrypted master key} also is stored within the
{\em encrypted recovery document}.}
- \item[policy key] {The {\em policy keys} are used for encryption and
decryption of the {\em encrypted master key}. A {\em policy key} is constructed
by hashing a specific combination of {\em key shares} specified by the
- user. For hashing SHA512 is used here.}
-\end{description}
-\newpage
-
-\begin{figure}[H]
- \centering
- \includegraphics[scale=0.48]{images/truth_anastasis.png}
- \caption{Key generation for signing of encrypted ``Truth'' data in
Anastasis}
- \label{fig:truth_keys}
-\end{figure}
-
-\noindent In the following the keys shown in the Figure~\ref{fig:truth_keys} on
-page~\pageref{fig:truth_keys} are explained:
-\begin{description}
-\item[truth seed] {Clients generate a random {\em truth seed} for each truth
- which is stored in the encrypted recovery document.}
-\item[private truth key] {{\em Private keys} are derived per truth upload. They
- are used to sign the uploaded data. This way, the escrow provider
- can later prove that they preserved the data correctly. We use
EdDSA~\cite{josefsson2017} for
- the signatures.}
-\item[public truth key] {{\em Public keys} are used to identify the truth
- in the provider's database. Providers only store the first truth upload with
- a valid signature. Changes to truth are thus not possible, clients must
- create a fresh seed for every upload.}
- \end{description}
-
-
-
-\subsection{Adversary model}
-
-The adversary model of Anastasis has two types of adversaries: {\em
- weak adversaries} which do not know the user’s identifier (the {\em
- kdf id}), and {\em strong adversaries} which somehow do know a
-user’s identifier. Against weak adversaries, the system guarantees
-full confidentiality, except for a provider-specific public account
-key which links certain requests from the same user, and the data necessary
-for authentication. The latter is only disclosed to the providers when
-the user requests key recovery. Weak adversaries cannot break
-confidentiality even if all escrow providers are part of a conspiracy
-of weak adversaries. For strong adversaries, breaking confidentiality
-of the core secret still requires that a sufficient subset of the
-Anastasis escrow providers must have colluded with the strong
-adversary. The user can specify a set of policies which determine
-which Anastasis escrow providers would need to collude to break
-confidentiality. These policies also set the bar for the user to
-recover their core secret.
-
-Anastasis providers are also not individually trusted to provide
-availability or authenticity. Users can specify multiple policies, and
-satisfying any one of the policies would allow them to recover their
-core secret assuming the subset of providers specified in the policy
-is available (and preserved the authenticity of the data). As clients
-sign their uploads, they can verify the authenticity of the data
-returned by checking the signatures. Only strong adversaries are able
-to forge signatures, so they could create fraudulent recovery
-documents and/or key shares resulting in invalid restored core
-secrets. However, because uploads are never destructive, strong
-adversaries can only succeed in breaking availability if they collude
-with a subset of escrow providers that are present in all policies
-selected by the user.
-
-Thus, users can improve confidentiality by having many different
-escrow providers in their policies, and improve availability by having
-many policies with few escrow providers. Anastasis does not resolve
-this trade-off, but allows users to make individual choices and gives
-them agility with respect to the parties whom they offer their
-trust, resulting in trust agility~\cite{marlinspike2011}.
-
-
-\subsection{Encryption of the core secret}
-
-The {\em core secret} of the user is (AES)~\cite{heron2009} encrypted using a
symmetric
-{\em master key}. Recovering the master key requires the user to
-satisfy a {\em policy}. Policies specify a set of escrow methods, each
-of which leads the user to a {\em key share}. Combining those key
-shares (by hashing) allows the user to obtain a policy key, which can
-be used to decrypt the master key. There can be many policies,
-satisfying any of these will allow the user to recover the master key.
-
-Which escrow methods are combined into which policies and which
-providers are involved can be different for each user. As users are
-unlikely to remember all the details, Anastasis needs a way to
-remember the specific configuration a user made.
-
-This process description is provided in a {\em recovery document}.
-
-% Figure~\ref{fig:recoverydoc} gives an example for a the contents of
-% a recovery document.
-% FIXME: actually include example!
-
-
-\subsection{The recovery document}
-
-A {\em recovery document} includes all the information a user needs to
-recover access to their core secret. It primarily identifies a set of
-{\em encrypted key shares} which have been entrusted to different
-Anastasis providers. For each key share, the recovery document
-specifies the respective Anastasis provider and also prescribes the
-{\em authentication method}, which specifies how the user should
-convince the Anastasis server that they are authorized to retrieve the
-encrypted key share. Authentication methods can for example include
-SMS-based verification, video-identification or a security question.
-
-For each authentication method, specific Anastasis providers are separately
-provided (see Section~\ref{sec:truth}) with the associated {\em encrypted key
- share} and (separately encrypted) {\em authentication
- data}. Anastasis operators may learn the authentication data during
-the recovery process to authenticate the user. Examples for
-authentication data would be a phone number (for SMS), a picture of
-the user (for video identification), or the (hash of) a security
-answer. A strong adversary is assumed to be able to learn the
-authentication data, while weak adversaries must not (except if they
-are the provider and then they may learn it only during key recovery).
-
-The recovery document also specifies {\em policies}, which describe
-the combination(s) of the key shares (and thus authentication
-processes) that would suffice to obtain access to the core secret. For
-example, a policy could say that the authentication methods ``$A$ and
-$B$'' suffice, and a second policy may permit ``$A$ and $C$''. A
-different user may choose to use the policy that ``$A$ and $B$ and
-$C$'' are all required. Anastasis imposes no limit on the number of
-policies in a recovery document, or the set of providers or
-authentication methods involved in guarding a user’s secret.
-
-Weak adversaries must not be able to deduce information about a user’s
-recovery document (except for meta data such as its length or
-approximate creation time, which may be exposed to an adversary which
-monitors the user’s network traffic or operates an escrow provider).
-
-
-\subsection{Identity-derived encryption}
-
-To start, a user provides their private (alas not really secret),
-unique and unforgettable user attributes as a seed to identify their
-account. For example, this could be a social security number together
-with their full name. Specifics may depend on the cultural context, in
-this document we will simply refer to this information as the
-{\em user attributes}.
-
-For each Anastasis provider, a {\em kdf id} key is derived from the
-user’s attributes and a provider salt using Argon2~\cite{BDK2016}, a
-computationally expensive cryptographic hash function. Using an
-expensive hash algorithm is assumed to make it harder for a weak
-adversary to determine user attributes by brute force guessing. The
-salt ensures that the keys for the same user cannot be easily
-correlated across the various Anastasis servers. However, it is
-assumed that a strong adversary performing a targeted attack can
-compute the {\em kdf id}s.
-
-The listing in Figure~\ref{fig:argon2} provides pseudo-code for
-the computation of the {\em kdf id}. The inputs are:
-
-\begin{description}
- \item[attributes] {The personal attributes provided by the user.}
- \item[server\_salt]{The salt from the Anastasis provider.}
- \item[keysize]{The desired output size of the KDF, here 32 bytes.}
-\end{description}
-
-\begin{figure}[H]
-\begin{lstlisting}
-user_identifier_derive(attributes, server_salt, keysize)
-{
- kdf_id = Argon2(attributes, server_salt, keysize)
- return kdf_id
-}
-\end{lstlisting}
-\caption[Use of Argon2 to derive user attributes]{The user's attributes are
hashed with Argon2, to provide a
- kdf\_id which will be used to derive other keys later. The hash must
- also be made over the respective provider's server\_salt. This
- ensures that the kdf\_id is different on each server. The use of
- Argon2 and the respective server\_salt are intended to make it
- difficult to brute-force kdf\_id values and help protect user’s
- privacy. Also this ensures that the kdf\_ids on every server
- differs. However, we do not assume that the identifier or the
- kdf\_id cannot be determined by an adversary performing a targeted
- attack, as a user’s identifier is likely to always be known to state
- actors and may likely also be available to other actors.}
-\label{fig:argon2}
-\end{figure}
-
-Anastasis derives symmetric key material --- but not the master secret ---
from the {\em kdf id} using different HKDFs~\cite{krawczyk2010}.
-
-When confidential data --- such as the recovery document or the truth
---- is uploaded to an Anastasis server, the respective payload is
-encrypted using AES-GCM with the respective symmetric key and
-initialization vector derived key material as shown in
-Figure~\ref{fig:keys_anastasis} and a high-entropy nonce. The nonce
-and the GCM tag are prepended to the ciphertext before being uploaded
-to the Anastasis server. This is done whenever confidential data is
-stored with the server, so both for encrypted authentication data
-(\texttt{/truth} uploads) and encrypted recovery documents
-(\texttt{/policy} uploads).
-
-To ensure that the key derivation for the encryption of the recovery
-document differs fundamentally from that of an individual key share,
-we use different salts for different types of operations (“erd” and
-“eks” respectively):
-
-\begin{lstlisting}
-encryption_key_create(kdf_id, salt, nonce)
-{
-iv, key = HKDF (kdf_id, nonce, salt, keysize + ivsize)
-return iv,key
-}
-\end{lstlisting}
-
-\begin{description}
- \item[HKDF()] {The HKDF-function uses to phases: First we use
HMAC-SHA512 for the extraction phase, then HMAC-SHA256 is used for expansion
phase.}
- \item[kdf\_id] {Hashed identifier.}
- \item[keysize] {Size of the AES symmetric key, here 32 bytes.}
- \item[ivsize] {Size of the AES GCM IV, here 12 bytes.}
- \item[nonce] {32-byte nonce, must never match “ver” (which it cannot as
the length is different). Of course, we must avoid key reuse. So, we must use
different nonces to get different keys and ivs (see below).}
- \item[key] {Symmetric key which is later used to encrypt the documents
with AES256-GCM.}
- \item[iv] {IV which will be used for AES-GCM.}
-\end{description}
-
-
-\begin{lstlisting}
-encrypt(kdf_id, data, salt)
-{
-nonce = generate_random_bytes(32)
-iv, key = encryption_key_create(kdf_id, salt, nonce)
-encrypted_data, aes_gcm_tag = AES256_GCM(data, iv, key)
-encrypted_data = nonce + aes_gcm_tag + encrypted_data
-return encrypted_data
-}
-
-key_share_encrypt(kdf_id, key_share)
-{
-encrypted_key_share = encrypt(kdf_id, key_share, "eks")
-return encrypted_key_share
-}
-
-recovery_document_encrypt(kdf_id, recovery_document)
-{
-encrypted_recovery_document =
-encrypt(kdf_id, recovery_document, "erd")
-return encrypted_recovery_document
-}
-
-\end{lstlisting}
-
-\begin{description}
- \item[encrypted\_recovery\_document] {The encrypted recovery document
which contains the authentication methods, policies and the encrypted core
secret.}
- \item[encrypted\_key\_share] {The encrypted key\_share which the escrow
provider must release upon successful authentication.}
- \item[nonce] {Nonce which is used to generate keys and ivs which are
used for the encryption. The nonce must contain either eks or erd.}
- \item[encrypted\_data] {The encrypted data contains the either a
recovery document or a key share which was encrypted and the nonce and the
aes\_gcm\_tag. To be able to decrypt it the first 32 Bytes are the nonce and
the next 12 Bytes are the aes\_gcm\_tag.}
-\end{description}
-
-
-\subsection{Authenticity of recovery documents}
-
-\texttt{/policy/} requests are used to upload new encrypted recovery
-documents. For users to authorize \texttt{/policy} operations, we need
-an account key pair. Thus, in addition to the symmetric keys, an
-EdDSA-based {\em account key} is derived from the {\em kdf id} (see
-Figure~\ref{fig:keys_anastasis}) and used to identify the ``account''
-of the user at each Anastasis server. EdDSA public keys are always
-points on Curve25519 and represented using the standard 256-bit
-Ed25519 compact format. The binary representation is converted to
-Crockford Base32 when transmitted inside JSON or as part of URLs in
-the RESTful API of Anastasis (see Section~\ref{sec:serverarch}).
-EdDSA signatures are also provided in Crockford Base32-encoding and
-transmitted using the HTTP header
-\texttt{Anastasis-Account-Signature}. Encrypted recovery documents
-are stored using the public account key as the identifier.
-
-As the account keys are derived from the {\em kdf id} --- which strong
-adversaries are assumed to know ---, we cannot assure that the corresponding
-private account key is truly secret. Thus, policy operations must
-never be destructive: A strong adversary can derive the private key
-and access (and with the {\em kdf id} also decrypt) the user’s
-recovery document (but not the core secret!), and also upload a new
-version of the encrypted recovery document. However, because uploads
-are not destructive, even a strong adversary cannot delete an existing
-version and thus cannot break availability.
-
-For the generation of the private key we use the {\em kdf id} as the
-entropy source, hash it to derive a base secret which will then be
-processed to fit the requirements for EdDSA private keys. From the
-private key we can then generate the corresponding public key. Here,
-the string “ver” is used for the salt value for the HKDF to ensure
-that the result differs from other cases where we hash {\em kdf id}:
-
-\begin{lstlisting}
-eddsa_keys_create (kdf_id, salt, keysize)
-{
- ver_secret = HKDF(kdf_id, salt, keysize)
- eddsa_priv = eddsa_d_to_a(ver_secret)
- eddsa_pub = get_eddsa_pub(eddsa_priv)
- return eddsa_priv, eddsa_pub
-}
-\end{lstlisting}
-
-\begin{description}
- \item[HKDF()] {The HKDF-function uses to phases: First we use
HMAC-SHA512 for the extraction phase, then HMAC-SHA256 is used for expansion
phase.}
- \item[kdf\_id] {Hashed identifier.}
- \item[salt] {Is used that different keys are generated, the salt here
is "ver".}
- \item[key\_size] {Size of the output, here 32 bytes.}
- \item[ver\_secret] {Derived key from the kdf\_id, serves as
intermediate step for the generation of the private key.}
- \item[eddsa\_d\_to\_a()] {Function which converts the ver\_key to a
valid EdDSA private key. Specifically, assuming the value eddsa\_priv is in a
32-byte array “digest”, the function clears and sets certain bits as follows:}
-\end{description}
-
-\begin{lstlisting}
-digest[0] = (digest[0] & 0x7f) | 0x40;
-digest[31] &= 0xf8;
-\end{lstlisting}
-
-\begin{description}
- \item[eddsa\_priv] {The generated EdDSA private key.}
- \item[eddsa\_pub] {The generated EdDSA public key.}
-\end{description}
-
-
-\subsection{Account signatures}
-
-The EdDSA account keys are used to sign the encrypted recovery
-document sent from the client to the server.
-
-% FIXME: "everything"? I don't think we can sign the encrypted truth
-% with the eddsa_priv, as that would link the truth to the ERD.
-% We need ANOTHER account key here, one per truth + provider?
-
-\begin{lstlisting}
-(anastasis-account-signature) = eddsa_sign(h_body, eddsa_priv)
-ver_res =
- eddsa_verifiy(h_body, anastasis-account-signature, eddsa_pub)
-\end{lstlisting}
-
-\begin{description}
- \item[anastasis-account-signature] {Signature over the SHA-512 hash of
the body using the purpose code TALER\_SIGNATURE\_ANASTASIS\_POLICY\_UPLOAD
(1400) (see GNUnet EdDSA signature API for the use of purpose).}
- \item[h\_body] {The hashed body.}
- \item[ver\_res] {A Boolean value. True: Signature verification passed,
False: Signature verification failed.}
-\end{description}
-
-\noindent
-When requesting \texttt{/policy} downloads, the client must also provide a
signature:
-\begin{lstlisting}
-(anastasis-account-signature) = eddsa_sign(version, eddsa_priv)
-ver_res =
- eddsa_verifiy(version, anastasis-account-signature, eddsa_pub)
-\end{lstlisting}
-
-\begin{description}
- \item[anastasis-account-signature] {Signature over the SHA-512 hash of
the body using the purpose code TALER\_SIGNATURE\_ANASTASIS\_POLICY\_DOWNLOAD
\\
- (1401) (see GNUnet EdDSA signature API for the use of purpose).}
- \item[version] {The version requested as a 64-bit integer, for the
“latest version”.}
- \item[ver\_res] {A Boolean value. True: Signature verification passed,
False: Signature verification failed.}
-\end{description}
-
-
-\subsection{Authenticity of truth} \label{sec:truth}
-
-\texttt{/truth/} requests are used to upload encrypted authentication data
-and encrypted key shares to an Anastasis escrow service. As an additional
-layer of protection, an Anastasis escrow service cannot link truth data to
-policy data, except maybe by observing the timing of the requests.
-
-Anastasis uses EdDSA-based {\em truth key}s to identify truth
-objects. For those, the truth keys are derived from a {\em truth
- seed}, as show in Figure~\ref{fig:truth_keys}. The private truth
-key is used to authorize the truth upload. The signatures also
-authenticate the encrypted key shares returned from the Anastasis
-provider during recovery. The signature process for truth is
-analogous to that for accounts.
-
-
-\subsection{Availability considerations}
-
-Anastasis considers two main threats against availability. First, the
-Anastasis server operators must be protected against denial-of-service
-attacks where an adversary attempts to exhaust operator’s
-resources. The API protects against these attacks by allowing
-operators to set fees for expensive operations. Furthermore, all data stored
-comes with an expiration logic, so an attacker cannot force servers to
-store data indefinitely.
-
-A second availability issue arises from strong adversaries that may be
-able to compute the account keys of some user. While we assume that
-such an adversary cannot successfully authenticate against the truth,
-the account key does inherently enable these adversaries to upload a
-new policy for the account. This cannot be prevented, as the
-legitimate user must be able to set or change a policy using only the
-account key. To ensure that an adversary cannot exploit this, policy
-uploads first of all never delete existing policies, but merely create
-another version. This way, even if an adversary uploads a malicious
-policy, a user can still retrieve an older version of the policy to
-recover access to their data. This append-only storage for policies
-still leaves a strong adversary with the option of uploading many
-policies to exhaust the Anastasis server’s capacity. We limit this
-attack by requiring a policy upload to include a reference to a
-payment identifier from a payment made by the user. Thus, a policy
-upload requires both knowledge of the identity and making a
-payment. This effectively prevents and adversary from using the
-append-only policy storage from exhausting Anastasis server capacity.
diff --git a/doc/thesis/glossary.tex b/doc/thesis/glossary.tex
deleted file mode 100644
index 7dced87..0000000
--- a/doc/thesis/glossary.tex
+++ /dev/null
@@ -1,19 +0,0 @@
-\section*{Glossary}
-\label{sec:glossary}
-\addcontentsline{toc}{section}{\nameref{sec:glossary}}
-\begin{description}
- \item[account key] {A public-private key pair used to sign and
authenticate the encrypted policy document upload.}
- \item[authentication method] {An authentication method specifies how
the user should convince the escrow provider that he is authorized to get a key
share.}
- \item[challenge] {A challenge is a data structure which holds
information about a user authentication for a escrow provider.}
- \item[core secret] {The core secret is the data which the user wants to
protect with Anastasis.}
- \item[escrow provider] {An escrow provider is referred to servers
which operate Anastasis.}
- \item[kdf id] {The kdf id is an Argon2 hash over the user's
unforgettable password.}
- \item[key share] {A key share is a random byte sequence which is
combined with other key shares to create a policy key.}
- \item[master key] {The master key is a randomly generated key which is
used to encrypt the user's core secret.}
- \item[policy] {A policy is a list of challenges which need to be solved
to recover the core secret.}
- \item[policy key] {Every policy holds a separate policy key which is
built through the combination of the key shares. The policy key is used to
encrypt the master key.}
- \item[recovery document] {A data structure which contains a set of
policies and challenges.}
- \item[truth] {A truth is a data structure which defines how a user
authentication is performed, it also contains the key share which is released
upon successful authentication.}
- \item[truth key] {A public-private key pair used to sign and
authenticate the truth upload.}
- \item[truth seed] {A nonce used to generate the key material to sign the
truth upload.}
-\end{description}
diff --git a/doc/thesis/images/BFH_Logo_A_en_100_4CU.pdf
b/doc/thesis/images/BFH_Logo_A_en_100_4CU.pdf
deleted file mode 100644
index 9fe2ca6..0000000
Binary files a/doc/thesis/images/BFH_Logo_A_en_100_4CU.pdf and /dev/null differ
diff --git a/doc/thesis/images/SD_truthupload.jpeg
b/doc/thesis/images/SD_truthupload.jpeg
deleted file mode 100644
index 57e2c0c..0000000
Binary files a/doc/thesis/images/SD_truthupload.jpeg and /dev/null differ
diff --git a/doc/thesis/images/anastasis-db.png
b/doc/thesis/images/anastasis-db.png
deleted file mode 100644
index a3ab262..0000000
Binary files a/doc/thesis/images/anastasis-db.png and /dev/null differ
diff --git a/doc/thesis/images/bitcoin-keys.png
b/doc/thesis/images/bitcoin-keys.png
deleted file mode 100644
index 7e2e78f..0000000
Binary files a/doc/thesis/images/bitcoin-keys.png and /dev/null differ
diff --git a/doc/thesis/images/client_api.png b/doc/thesis/images/client_api.png
deleted file mode 100644
index 3c1bdae..0000000
Binary files a/doc/thesis/images/client_api.png and /dev/null differ
diff --git a/doc/thesis/images/keys_anastasis.png
b/doc/thesis/images/keys_anastasis.png
deleted file mode 100644
index ec48ee8..0000000
Binary files a/doc/thesis/images/keys_anastasis.png and /dev/null differ
diff --git a/doc/thesis/images/legend_keys_anastasis.png
b/doc/thesis/images/legend_keys_anastasis.png
deleted file mode 100644
index 7778a31..0000000
Binary files a/doc/thesis/images/legend_keys_anastasis.png and /dev/null differ
diff --git a/doc/thesis/images/original/Secret split.drawio
b/doc/thesis/images/original/Secret split.drawio
deleted file mode 100644
index b984718..0000000
--- a/doc/thesis/images/original/Secret split.drawio
+++ /dev/null
@@ -1 +0,0 @@
-<mxfile host="app.diagrams.net" modified="2020-06-11T09:38:56.231Z" agent="5.0
(X11)" etag="5MHzSdf81DS1tZsiEoSH" version="13.2.1" type="device"><diagram
id="C5RBs43oDa-KdzZeNtuy"
name="Page-1">7Vxbd6I6FP41rjXnwS5uoj5We5vTnl5G2545L10RomaKhEKwOr9+EgggCadeKi1WH6YDG7NZfPv7snc20ZrenczOfeCN/8E2dGqaYs9q+klN01qKSv8ywzw2GKYRG0Y+smOTmhl66DfkRoVbQ2TDIPdBgrFDkJc3Wth1oUVyNuD7+DX/sSF28nf1wAhKhp4FHNn6iGwy5o+lNTP7BUSjcXJn1WzHVyYg+TB/kmAMbPy6YNJPa3rXx5jER5NZFzoMuwSXx+/zR+fq2Tz/+y54Afedy/71Qz12drbOkPQRfO
[...]
\ No newline at end of file
diff --git a/doc/thesis/images/original/architecture.drawio
b/doc/thesis/images/original/architecture.drawio
deleted file mode 100644
index dabe015..0000000
--- a/doc/thesis/images/original/architecture.drawio
+++ /dev/null
@@ -1 +0,0 @@
-<mxfile host="Electron" modified="2020-06-08T17:14:49.488Z" agent="5.0 (X11;
Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/13.0.3
Chrome/80.0.3987.163 Electron/8.2.1 Safari/537.36" etag="dMqTqm28w4aWaqFP5ALS"
version="13.0.3" type="device"><diagram id="gmhu5a6k70m_uNo_Q5m0"
name="Page-1">3Ztbc9soFMc/jR+bkdDNfsw6aZpeZj3rnWn61MESltjqNghftJ9+UQS2BKrjqpaMNy+BA0jmzw84HOyJNU/2TwTm0ZcsQPEEGMF+Yj1MADBNA7B/laWsLVPHqA0hwQGvdDQs8b+IG0W1DQ5Q0apIsyymOG8b/SxNkU9bNkhItmtXW2dx+605DJFiWPow
[...]
\ No newline at end of file
diff --git a/doc/thesis/images/original/assemble.drawio
b/doc/thesis/images/original/assemble.drawio
deleted file mode 100644
index 873b691..0000000
--- a/doc/thesis/images/original/assemble.drawio
+++ /dev/null
@@ -1 +0,0 @@
-<mxfile host="app.diagrams.net" modified="2020-06-11T09:34:30.852Z" agent="5.0
(X11)" etag="v6wUs5AL9fcLf7RuAbdu" version="13.2.1" type="device"><diagram
id="C5RBs43oDa-KdzZeNtuy"
name="Page-1">7VvbUuM4EP2aVO0+hPIthjyScBmGGW4hy+6+UIqtxCocyyPJJJmvH8mWHVtyBQgxBMLDgNWO2uPT53SrpdCy+9P5KQFx8BP7MGxZhj9v2Ucty+o6Fv8pDIvM0HHczDAhyM9M5tIwQL+hNBrSmiAf0soHGcYhQ3HV6OEogh6r2AAheFb92BiH1afGYAI1w8ADoW69Qz4LMuuBtb+0f4NoEuRPNt1udmcK8g/LN6EB8PGsZLKPW3afYMyyq+m8D0OBXY7L3dniLvzx4J5+v6a/wLB3fnvxTztzdvKSKcUrEB
[...]
\ No newline at end of file
diff --git a/doc/thesis/images/original/keys_anastasis.xml
b/doc/thesis/images/original/keys_anastasis.xml
deleted file mode 100644
index 484c5fe..0000000
--- a/doc/thesis/images/original/keys_anastasis.xml
+++ /dev/null
@@ -1 +0,0 @@
-<mxfile host="Electron" modified="2020-06-10T22:10:55.543Z" agent="5.0 (X11;
Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/13.0.3
Chrome/80.0.3987.163 Electron/8.2.1 Safari/537.36" etag="8e-sJDh7hZnLgeOFmvhG"
version="13.0.3" type="device"><diagram id="y88xZ1jZEfnO60AMu_A7"
name="Seite-1">7V3fk6M2Ev5b7sFVSarsQhI/H2dms9nK5S5bN3eX7KMMsk0GAwE8M85fHwkQRhJ4MAZsT8087NpCCOj++utuqZFn6GH7+lOC482/Io8EM6h5rzP0aQYhABqk/7GWfdFiG1rRsE58r+x0aHj0/yJlI++28z2SCh2zKAoyPxYb3SgMiZsJbThJohex2yo
[...]
\ No newline at end of file
diff --git a/doc/thesis/images/original/legend_keys_anastasis.xml
b/doc/thesis/images/original/legend_keys_anastasis.xml
deleted file mode 100644
index f61a06e..0000000
--- a/doc/thesis/images/original/legend_keys_anastasis.xml
+++ /dev/null
@@ -1 +0,0 @@
-<mxfile host="Electron" modified="2020-06-10T22:08:35.325Z" agent="5.0 (X11;
Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/13.0.3
Chrome/80.0.3987.163 Electron/8.2.1 Safari/537.36" etag="Rxu-dl2hcfe4VS6jo7me"
version="13.0.3" type="device"><diagram id="Dbx-aSpqoDdGa1gFz_tw"
name="Seite-1">5VjJbtswEP0aXwo0sCSvR8dN0gIpECCHnmlxJBGhRJekbKtf36FEWatrI5GbBr1oGQ6Xee9pONTIW8eHB0m20XdBgY/cMT2MvC8j13WcsYs3Y8kKy2I6LgyhZNQ6VYZn9gussXRLGQXVcNRCcM22TaMvkgR83bARKcW+6RYI3px1S0LoGJ59wrvWH4z
[...]
\ No newline at end of file
diff --git a/doc/thesis/images/original/truth_signing.drawio
b/doc/thesis/images/original/truth_signing.drawio
deleted file mode 100644
index ff9af1e..0000000
--- a/doc/thesis/images/original/truth_signing.drawio
+++ /dev/null
@@ -1 +0,0 @@
-<mxfile host="Electron" modified="2020-06-11T08:52:23.756Z" agent="5.0 (X11;
Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/13.0.3
Chrome/80.0.3987.163 Electron/8.2.1 Safari/537.36" etag="koHNblYfoay_AOa3GdKR"
version="13.0.3" type="device"><diagram id="zHgjgIgxK0MXml55a55n"
name="Page-1">3Znxb6M2FMf/GqRtUiowAZofm7Z31Xa33dRtd/1pcrBD0AjmjNMk99fvOdiADbkmKEmrqyIVP+zn2N8P7z0Tx79dbt5zXCw+MkIzB7lk4/h3DkLeGCFHflyyrSzXQVAZEp4S1akxPKbfqDK6yrpKCS2NjoKxTKSFaYxZntNYGDbMOVub3eYsM2ctcEI7
[...]
\ No newline at end of file
diff --git a/doc/thesis/images/project_plan.png
b/doc/thesis/images/project_plan.png
deleted file mode 100644
index 3ede596..0000000
Binary files a/doc/thesis/images/project_plan.png and /dev/null differ
diff --git a/doc/thesis/images/project_plan_anastasis.png
b/doc/thesis/images/project_plan_anastasis.png
deleted file mode 100644
index b21586e..0000000
Binary files a/doc/thesis/images/project_plan_anastasis.png and /dev/null differ
diff --git a/doc/thesis/images/recovery_process.png
b/doc/thesis/images/recovery_process.png
deleted file mode 100644
index af2de2d..0000000
Binary files a/doc/thesis/images/recovery_process.png and /dev/null differ
diff --git a/doc/thesis/images/secret_split.png
b/doc/thesis/images/secret_split.png
deleted file mode 100644
index 876bfdf..0000000
Binary files a/doc/thesis/images/secret_split.png and /dev/null differ
diff --git a/doc/thesis/images/selbst_dennis.pdf
b/doc/thesis/images/selbst_dennis.pdf
deleted file mode 100644
index 6e5ef42..0000000
Binary files a/doc/thesis/images/selbst_dennis.pdf and /dev/null differ
diff --git a/doc/thesis/images/selbst_meister.pdf
b/doc/thesis/images/selbst_meister.pdf
deleted file mode 100644
index a38c749..0000000
Binary files a/doc/thesis/images/selbst_meister.pdf and /dev/null differ
diff --git a/doc/thesis/images/server_api.png b/doc/thesis/images/server_api.png
deleted file mode 100644
index c344eaa..0000000
Binary files a/doc/thesis/images/server_api.png and /dev/null differ
diff --git a/doc/thesis/images/system-architecture.png
b/doc/thesis/images/system-architecture.png
deleted file mode 100644
index db46705..0000000
Binary files a/doc/thesis/images/system-architecture.png and /dev/null differ
diff --git a/doc/thesis/images/system-architecture_2.png
b/doc/thesis/images/system-architecture_2.png
deleted file mode 100644
index 7c2cbd0..0000000
Binary files a/doc/thesis/images/system-architecture_2.png and /dev/null differ
diff --git a/doc/thesis/images/system_design.png
b/doc/thesis/images/system_design.png
deleted file mode 100644
index 52ff118..0000000
Binary files a/doc/thesis/images/system_design.png and /dev/null differ
diff --git a/doc/thesis/images/truth_anastasis.png
b/doc/thesis/images/truth_anastasis.png
deleted file mode 100644
index 76fb520..0000000
Binary files a/doc/thesis/images/truth_anastasis.png and /dev/null differ
diff --git a/doc/thesis/images/user_id.png b/doc/thesis/images/user_id.png
deleted file mode 100644
index 42c741c..0000000
Binary files a/doc/thesis/images/user_id.png and /dev/null differ
diff --git a/doc/thesis/implementation.tex b/doc/thesis/implementation.tex
deleted file mode 100644
index d01bcd4..0000000
--- a/doc/thesis/implementation.tex
+++ /dev/null
@@ -1,421 +0,0 @@
-\section{Implementation}
-
-The Anastasis is written in C. We decided to use C because of the
-various dependencies, including cryptographic libraries. Especially,
-GNU Taler and Sync, which are working in concert with Anastasis, are
-also written in C. Using the same language makes integration and
-testing of Anastasis much easier.
-
-The whole Anastasis application consists of multiple components.
-Figure~\ref{fig:secret_split:overview} gives an overview over all the
-components.
-
-\begin{figure}[H]
- \centering
- \includegraphics[scale=0.5]{images/system-architecture.png}
- \caption{System architecture overview}
- \label{fig:system_arch:overview}
-\end{figure}
-
-\noindent In the center is the core implementation of Anastasis.
-On the left are some of the planned authentication methods from the
-application. On the right side of the box are the core parts which are
-necessary to operate Anastasis commercially. These parts are
-anticipated for a production deployment, but not part of the
-implementation for this thesis.
-
-At the bottom section are the external libraries used for the project.
-These libraries are presented in Section~\ref{sec:libraries}.
-\newpage
-
-
-\subsection{System architecture}
-
-This graphic shows the basic architecture of the Anastasis
-application. It shows a simplified flow of the application. The
-details of each component are explained later.
-
-\begin{figure}[H]
- \centering
- \includegraphics[scale=0.4]{images/system_design.png}
- \caption{System design overview}
- \label{fig:system_design}
-\end{figure}
-
-\begin{enumerate}
-\item The Anastasis CLI interacts with the Anastasis API. The
- Anastasis API is responsible for triggering interactions with the
- user, and also manages the interactions between the
- various client-side components.
-\item After the user provided their unforgettable secret, the
- Crypto API derives the needed key material for the further
- communication. This is simplified, in reality the client would first
- need to download the server salt to generate the user keys. The
- crypto API is later also responsible for the decryption and
- encryption of the data, sent or received from the server.
-\item The Service API is responsible for the communication with the
- Anastasis server. The Anastasis API sends the previously generated
- data and the user selected request to the service.
- The Service API is also responsible to handle
- the server's response to the request.
-\item The central webserver logic handles HTTP requests sent to it by the
- clients. It will dispatch requests to the corresponding handler. The
- webserver's core logic also returns the response and the status code
- of the operation to the client application.
-\item Each REST endpoint of the Anastasis server is implemented by
- a specific handler. The handler processes the requests, typically
- by storing or looking up the requested
- data with the database. When the request is finished, the handler will
- send back the data or the status code to the webserver's core logic.
-\end{enumerate}
-
-
-\input{server_architecture}
-
-\input{client_architecture}
-
-\newpage
-\subsection{Application flow}
-
-This section describes a happy flow of the two protocols of Anastasis,
-secret splitting and secret recovery.
-
-\subsubsection{Secret splitting}
-
-Figure~\ref{fig:secret_split} illustrates the secret splitting
-process.
-
-\begin{figure}[H]
- \centering
- \includegraphics[scale=0.5]{images/secret_split.png}
- \caption{Secret split process}
- \label{fig:secret_split}
-\end{figure}
-\newpage
-\begin{enumerate}
-\item The user selects a new escrow provider on which per wants to
- store a truth object.
-\item The client software downloads the terms of service for this
- provider (GET /terms). This is also a check if the server is
- available if this command doesn't respond the client will abort the
- process.
-\item Next the client requests the server configuration (GET
- /configuration). The configuration lists the available
- authentication methods and the protocol version of the server.
-\item The client downloads the server salt (GET /salt). The salt is
- used to generate the server specific account public key, which
- identifies the user.
-\item After the user has generated the public key, per will create a
- truth object on the client. The truth object contains all the needed
- information for the recovery for this key share. This truth object
- is sent encrypted to the server and stored under the TRUTH\_PUB the client
- generated (POST /truth/\$TRUTH\_PUB).
-\item In this scenario the client has not jet paid for the
- upload. This means the server will respond with the HTTP status code
- \texttt{402 Payment required}. The client first must do a payment with our
- payment provider --- GNU Taler. After the successful payment the client
- will receive a payment identifier. With this payment identifier he
- can resend the previously failed request.
-\item The user will now repeat the steps 1-6 until per thinks that they
- have setup a sufficient amount of authentication methods. The user
- can now combine these providers to create policies. For example per
- may have stored three truth objects at three different providers.
- This means per can now define combinations with these providers,
- for example A+B, A+C and B+C. This means the user has three ways to
- recover their secret.
-\item After the user has generated the policies the client will
- generate a recovery document. The recovery document contains a list
- of all truth\_seed's used, a list of the policies and the encrypted core
- secret of the user. The client will now send a encrypted recovery
- document to each provider used in the recovery document (POST
- /policy/\$ACCOUNT\_PUB). Through this, the recovery document is
- replicated and recovery can proceed without a single point of
- failure.
-\end{enumerate}
-\newpage
-\subsubsection{Secret recovery}
-
-Figure~\ref{fig:recovery_process} illustrates the recovery process.
-\begin{figure}[H]
- \centering
- \includegraphics[scale=0.5]{images/recovery_process.png}
- \caption{Secret recovery process}
- \label{fig:recovery_process}
-\end{figure}
-\begin{enumerate}
-\item The user selects a server on which per previously stored a
- recovery document.
-\item Next the client downloads the server salt to compute the server
- specific account public key (GET /salt).
-\item After the user generated the public key, per will download the
- recovery document. At this point per can define a
- specific version or the latest version of the recovery document. In
- the illustration the client downloads the latest version (GET
- /policy/\$ACCOUNT\_PUB).
-\item The client will now decrypt the recovery document and list all
- policies and authentication methods. The user now has to solve these
- challenges. In this example the user has to answer a secure question
- which was sent to them in the recovery document. (GET
- /truth/\$TRUTH\_PUB?response=\$RESPONSE) \\
-\item Note the server can define that a challenge has a certain cost,
- in this scenario the server rejects the first request because the
- user has not yet paid for recovery. After the payment the user can
- resend the request. After each successfully solved challenge the
- client will check if one of the policies is completely satisfied.
- If all shares needed for one of the policies have been recovered,
- the client will decrypt the core secret and provide it to the user.
-\end{enumerate}
-
-Figure~\ref{fig:recovery_process} shows the flow using a secure
-question for the authentication challenge. If the user would have
-chosen a complex authentication method like SMS or E-Mail, the client
-would first need to start the challenge with the request (GET
-/truth/\$TRUTH\_PUB). The server would then notify the user that per will
-receive some token out of bounds. After that, the user would have to
-provide for example the PIN sent to them via SMS with the same request
-as before (GET /truth/\$TRUTH\_PUB?response=\$RESPONSE).
-
-
-\subsection{Client Application Command Line Interface (CLI)}
-
-There are two client applications which interact with the user. First
-the Anastasis {\em splitter} and second the Anastasis {\em
- assembler}. The splitter application is responsible for the backup
-of the core secret. The assembler is then responsible for the recovery
-of the core secret.
-
-Both commands are started with a configuration option ``--me=FILE''
-that gives the name of a file with the user's identity attributes.
-
-\subsubsection{Anastasis splitter}
-
-The user starts the assembler by passing a JSON document with their
-unforgettable identity attributes (name, social security number, ...).
-
-The following commands are available:
-
-\begin{itemize}
-\item server add \$URL: this command lets the user add escrow
- providers. The command will check if a supported escrow service is
- available under the provided URL. Afterwards it will download its
- terms and salt. The server needs to be added before the user can do
- any uploads on it.
-\item truth add \$server \$method \$truth: with this command the user
- can upload a truth on a previously added server. The user needs to
- specify the authorization method used and the truth for the
- authorization process, for example the phone number for SMS
- authentication. The application will check if the server supports the
- provided method before uploading.
-\item policy add \$truth1 \$truth2...: after a user has added all the
- truths, per can start to create policies. Per can combine the truths
- in any way they wish. It is also possible to just store one truth in
- a policy, but this is not recommended since it defies the design of
- the application.
-\item policy: shows all created policies.
-\item truth: shows all created truths.
-\item server: shows all added servers.
-\item publish \$secret: if the user is finished per can publish the
- configuration. The application will then generate the recovery
- document with the provided information and secret. Afterwards, it
- will upload the recovery document on every server that was used. For
- recovery, the user only needs to remember any one of the servers.
-\end{itemize}
-
-Below is an example transcript of an interaction with the splitter:
-
-\begin{lstlisting}
-$ anastasis-splitter --me=identity.json
-anastasis-splitter> server add $URL1
-version: 1.0
-annual fee: 4.99 KUDOS,
-available policy methods: sms
-Server #1 available
-anastasis-splitter> server add $URL2
-version: 1.0
-annual fee: 3.99 KUDOS,
-available policy methods: sms, question
-Server #2 available
-anastasis-splitter> truth add server#1 sms +492452526
-Truth #1 added for server #1
-anastasis-splitter> truth add server#2 mail "hoehenweg 80, Biel"
-Sorry, server #2 does not support 'mail'
-anastasis-splitter> truth add question "favorite color" "red"
-Truth #2 added
-anastasis-splitter> policy add truth#1 truth#2
-Policy #1 defined
-anastasis-splitter> policy
-Policy#1: #truth#1 #truth2
-anastasis-splitter> truth
-truth#1: server#1 sms +492452526
-truth#2: server#2 question "favorite color" <OMITTED>
-anastasis-splitter> truth --secrets
-truth#1: sms +492452526
-truth#2: question "favorite color" "red"
-anastasis-splitter> server
-server#1: http://anastasis.example.com/ methods: sms,
-insured up to: 420 KUDOS, cost: 0.4 KUDOS
-anastasis-splitter> publish
-Server#1 failure: 402 payment required:
-payto://pay/ABALSASDFA KUDOS:0.3
-Server#2 failure: 402 payment required:
-payto://pay/ABALSAADAS KUDOS:0.5
-Total: 0.8 KUDOS
-# Here: taler-wallet-cli payto://pay/ABALASDFA used to pay!
-anastasis-splitter> publish
-Server#2 failure: 402 payment required
-# Here: taler-wallet-cli payto://pay/ABASDFASDF used to pay!
-anastasis-splitter> publish "my super secret"
-Thank you for using Anastasis.
-$
-\end{lstlisting}
-
-\subsubsection{Anastasis assembler}
-
-The user starts the assembler by passing a JSON document with their
-unforgettable identity attributes (name, social security number, ...).
-They also must pass the URL of an escrow provider which stores their
-recovery document, as well as the requested version of the recovery
-document. The assembler will then download and decrypt the recovery
-document and begin the recovery process.
-
-
-The following commands are available:
-\begin{itemize}
-\item truth: shows all available authorization challenges
- from the recovery document and their status (``(-)'' not solved, ``(+)''
solved)
-\item policies: shows all available policies in the recovery document and
- the respective status of the truths used in each policy.
-\item try \$truth: this command starts an authorization process which
- needs interaction with external services like SMS or email. It shows
- the instructions to follow to authorize release of the share.
-\item answer \$truth \$answer: this command tries to answer the
- selected challenge with the provided answer. The application will
- check the answer and give a feedback to the user. Every time a
- challenge is solved, the client API will check if as a result any of
- the policies is completely satisfied. If any policy was completely
- satisfied, the assembler will print out the recovered core secret
- and exit.
-\end{itemize}
-
-Below is an example transcript of an interaction with the assembler:
-
-\begin{lstlisting}
-$ anastasis-assembler --import https://anastasis.example.com/
---policy-version=42 --me=identity.json
-anastasis-assembler> truth
-truth#1(-): KUDOS 0.0 question "favorite color"
-truth#2(-): KUDOS 0.4 sms
-truth#3(-): KUDOS 2.6 post
-anastasis-assembler> policies
-policy#1: KUDOS 0.4 truth#1 truth#2 missing
-policy#2: KUDOS 3.0 truth#1 truth#2 truth#3 missing
-anastasis-assembler> try truth#2
-payto://pay/BASDFASD
-# SMS arrives asynchronously
-anastasis-assembler> answer truth#2 1234
-Success truth#2
-anastasis-assembler> answer truth#1 "blue"
-Failed truth#1
-anastasis-assembler> truth
-truth#1(-): KUDOS 0.0 question "favorite color"
-truth#2(+): KUDOS 0.4 sms
-truth#3(-): KUDOS 2.6 post
-anastasis-assembler> policies
-policy#1: KUDOS 0.0 truth#1 missing
-policy#2: KUDOS 2.6 truth#1 truth#3 missing
-anastasis-assembler> answer truth#2 "red"
-Success truth#2
-//One of the policies was solved successfully and the secret is recovered.
-Secret was: "my super secret"
-$
-\end{lstlisting}
-
-
-
-\subsection{Libraries} \label{sec:libraries}
-
-In this section the libraries used by Anastasis are presented.
-
-\subsubsection{GNU Taler}
-
-GNU Taler is one of the main reasons why we started to implement
-Anastasis, since the application needs a system to back up the private
-keys of their users. ``GNU Taler is a privacy-preserving payment
-system. Customers can stay anonymous, but merchants can not hide their
-income through payments with GNU Taler. This helps to avoid tax
-evasion and money laundering.''~\cite{gnu_taler}
-
-To operate GNU Taler the user needs to install an electronic
-wallet. Backups of the wallet are secured with a secret key. Here
-comes Anastasis into play, Anastasis will secure this secret key for
-the user.
-
-In our implementation GNU Taler is also our payment system. We decided
-to use GNU Taler because both Anastasis and GNU Taler are privacy
-preserving applications. If we for example used credit cards for
-payments the user would no longer be anonymous which is helpful for
-the security of Anastasis as it allows us to use the user's name in
-the user's identity attributes. GNU Taler is also a GNU package
-and Free Software.~\cite{gnu_taler}
-\newpage
-\subsubsection{PostgreSQL}
-
-PostgreSQL is a Free/Libre Open Source object-relational
-database. PostgreSQL has over 30 years of active development which
-makes it a stable and reliable software.
-
-We use PostgreSQL as our database on the Anastasis server. We decided
-to use PostgreSQL because it is an open source and lightweight
-software which has a big community. This means there are a lot of
-helpful documentations and forums.~\cite{postgresql}
-
-\subsubsection{Libcurl}
-
-Libcurl is a libre URL transfer library. Libcurl supports a wide range
-of protocols and a C API. Libcurl is also ready for IPv6 and SSL
-certificates.
-
-For Anastasis we use Libcurl to generate the client-side HTTP
-requests. We decided to use Libcurl because it is also written in C
-and free software. The software is also well supported and has a good
-documentation. This makes the integration in our application
-easy.~\cite{libcurl}
-
-\subsubsection{GNU Libmicrohttpd}
-
-GNU libmicrottpd is a small C library which provides an easy way to
-run a HTTP server. We use GNU Libmicrohttpd in Anastasis to provide a
-simple webserver. The main reason why we did not use apache or nginx
-is that we do not need a standalone webserver. The Anastasis webserver
-just must handle some API requests, a standalone webserver is not
-needed for that and would make the infrastructure more complex to
-maintain and develop. GNU Libmicrohttpd is also a GNU package
-and Free Software.~\cite{libmicrohttpd}
-
-\subsection{Testing}
-
-To test our application, we used the GNU Taler testing library as our
-foundation for t of our testings. This library allows you to create testing
instances of
-both the Anastasis application and the GNU Taler payment system. We
-implemented unit tests for the crypto functions and the database operations.
-The following four tests are independently performed.
-
-\begin{itemize}
-\item The first test is the database test. The Anastasis testing library first
connects to a test database, this database is only used for the testing, we
never test on the live database. The test first deletes and recreates the
database. After that it will perform several unit tests to check if the
database queries of the application are working as intended.
-\item Next we test the Anastasis crypto API, it tests all the
-cryptographic functions used in the API with unit tests.
-The most important part is that the recreation of the keys
-and decryption works as intended.
-\item After the basic parts of the application are tested the client
-will test every request in the Anastasis server API. For this we need the
-Taler Testing library. The Taler testing library will start an instance
-of the Anastasis webserver and a GNU Taler merchant service. The merchant
-service is needed to process the payment operations. The testing library
-will now send a request to every end point of the Anastasis REST API. It will
-check if every response of the REST API is as intended.
-\item At the end the whole application flow is tested. For this
-we need to start a Anastasis server, Taler merchant and Taler exchange
instance.
-The library will now perform a full secret split and secret recovery.
-This test is successful if the provided core secret at the begin, matches the
-recovered core secret.
-\end{itemize}
diff --git a/doc/thesis/introduction.tex b/doc/thesis/introduction.tex
deleted file mode 100644
index 882345d..0000000
--- a/doc/thesis/introduction.tex
+++ /dev/null
@@ -1,224 +0,0 @@
-\section{Introduction}
-
-Keys are used to encrypt high sensitive personal data and therefore
-they must be kept safely. Secure storage of private keys is known to
-be a difficult problem --- especially for end-users with limited
-skills in system administration and insufficiently redundant hardware.
-A central objective for any solution is that only the legitimated
-owner of a key must have the possibility to recover a lost key.
-
-But how can one create a confidential backup of a key? It certainly
-makes no sense to encrypt a key with a different password and then use
-the result as a backup. After all, this merely shifts the problem from
-the original key to the password, which is basically yet another key.
-So simply encrypting the key is not helpful. But without encryption,
-any copy of a key increases availability, but also the risk of the
-key's confidentiality being compromised.
-
-Most people have difficulties memorizing a high-entropy
-passphrase. Hence, existing key management ``solutions'' often reduce
-the problem of memorizing one or more high-entropy passphrases or keys
-to memorizing a single low-entropy passphrase. This is not a good
-solution, as the low-entropy passphrase undermines security.
-
-In this thesis, we describe a software solution for the described
-problem using secret splitting. We call our solution ``Anastasis'',
-which is a medical term for the prognosis of full recovery. We will
-call the information that Anastasis allows the user to recover their
-{\em core secret}.
-
-\subsection{Principles}
-
-For Anastasis we have following design objectives, in order of importance:
-
-\begin{enumerate}
- \item Anastasis must be Free Software\footnote{\url{https://www.fsf.org/}}.
Everyone must have the right to
- run the program, study the source code, make modifications and share
- their modifications with others.
- \item Anastasis must not rely on the trustworthiness of individual providers.
- It must be possible to use Anastasis safely, even if a subset of the
- providers is malicious. Anastasis must minimize the amount of information
- exposed to providers and the network.
- \item Anastasis must put the user in control: They get to decide which
- providers to use, and which combinations of authentication steps will
- be required to restore their core secret. The core secret always remains
exclusively
- under the user's control, even during recovery.
- \item Anastasis must be economical viable to operate. This implies usability
- and efficiency of the system.
- \item Anastasis must support a diverse range of use cases.
-\end{enumerate}
-
-
-\subsection{Approach}
-
-\subsubsection*{Secret sharing and recovery}
-
-Our approach to solve the problem of key recovery is to let the user
-split their core secret across multiple escrow providers (see
-Figure~\ref{fig:system_arch2}). To recover their core secret, the user has to
-authorize key the recovery, usually by passing an authentication check
-which they configured for the respective provider.
-
-After successful authentication the user receives the secret shares
-and is able to reassemble their core secret locally on their computer.
-
-\begin{figure}[H]
-\centering
-\includegraphics[scale=0.33]{images/system-architecture_2.png}
-\caption{System architecture}
-\label{fig:system_arch2}
-\end{figure}
-
-\subsubsection*{Derive user identifier}
-
-Every person has some hard to guess, semi-private and unforgettable
-inherent attributes such as name and passport number, social security
-number or AHV~\cite{jerome2015} number (in Switzerland). We use those
attributes to
-improve the security and privacy provided by Anastasis. Basically,
-these attributes serve as weak key material, raising the bar for
-attackers without the availability disadvantages of passphrases ---
-which users may forget. Anastasis derives a ``user identifier'' from
-such a set of unforgettable attributes (see Figure~\ref{fig:user_id}).
-
-\begin{figure}[H]
-\centering
-\includegraphics[scale=0.3]{images/user_id.png}
-\caption{Derivation of a user identifier}
-\label{fig:user_id}
-\end{figure}
-
-\subsubsection*{Encrypt and encrypt and encrypt}
-
-Anastasis uses several layers of encryption. First, the user's core
-secret is encrypted with a master key. The master key is encrypted
-with various policy keys. The policy keys are derived from various
-secrets which are encrypted and distributed across various providers
-together with information about the desired recovery authorization
-procedure. This last encryption is done based on keys derived from the
-user identity. These many layers of encryption are designed to
-distribute trust and to minimize or delay information disclosure.
-
-\subsubsection*{Private payments are integrated}
-
-The Anastasis protocol includes provisions for privacy-preserving
-electronic payments to the service providers, as well as resource
-limitations to protect service providers against resource exhaustion
-attacks. This ensures that it should be possible to operate the
-service commercially.
-
-
-\subsection{Use cases}
-
-There are several applications which are in need of a key escrow
-system like Anastasis. Some of them shall be introduced in this
-section.
-
-\subsubsection{Encrypted email communication}
-
-For email encryption using Pretty Good Privacy
-(PGP)~\cite{garfinkel1995} users need a private key which is typically
-stored on the device running PGP. PGP uses a ``Web of trust'' to
-establish the authenticity of keys.
-
-Pretty Easy privacy (short p\equiv p) is ``a cyber security solution
-which protects the confidentiality and reliability of communications
-for citizens, for public offices and for
-enterprises''~\cite{pepdoc}. It secures communication via email by
-providing end-to-end encryption similar to PGP. A major difference is
-that p\equiv p uses opportunistic encryption and so-called trustwords
-to establish authenticity to avoid usability and privacy problems
-associated with the ``Web of trust''~\cite{caronni2000}.
-
-The impact of losing control over the private key is similar in both
-systems:
-
-\begin{itemize}
- \item If the private key becomes unavailable, all emails which were
-encrypted to that key become unreadable. Furthermore, the user would
-likely need to rebuild their ``Web of trust''.
- \item If the private key is
-disclosed to an adversary, they might be able to decrypt that user's
-encrypted emails -- which may go back years and could include highly
-sensitive information. An adversary could also use the private key
-to send cryptographically signed emails pretending to be the user.
-\end{itemize}
-
-
-\subsubsection{Digital currencies and payment solutions}
-
-Another application relying on a core secret are cryptocurrencies like
-Bitcoin. Each user of Bitcoin needs an electronic wallet which stores
-and protects the private keys of the user. Those private keys
-legitimate its owners to spend the bitcoins corresponding to the
-keys.~\cite{LLLW*2017}
-
-Losing Bitcoin wallet keys means losing all of the corresponding
-Bitcoins. The reader may be familiar with stories from the mass media
-about people who claim to have lost their key to their electronic
-wallet and therefore huge sums of
-cryptocurrency~\cite{millions_lost}. Backup systems are essential to
-avoid such cases.
-
-The following graphic illustrates the keys used in Bitcoin
-wallets. In this case, the core secret Anastasis would store
-is the ``master key'' $m$:
-
-\begin{figure}[H]
- \centering
- \includegraphics[scale=3.5]{images/bitcoin-keys.png}
- \caption[Master key in Bitcoin wallets]{Master key in Bitcoin wallets
(from~\cite{bitcoin-keys})}
- \label{fig:bitcoin_keys}
-\end{figure}
-
-GNU Taler\footnote{\url{https://taler.net/de/}} is a new electronic instant
payment system for
-privacy-friendly online transactions. The GNU Taler digital wallets are
-storing electronic coins, and backups are protected with a key.
-Losing the backup key means losing all the money stored in the wallet,
-as well as the transaction history kept in the wallet.
-
-The European Central Bank (ECB) informally informed Taler Systems SA
-about the requirement for electronic wallets denominated in Euros to
-support password-less data recovery to ensure users would not loose
-their electronic funds if their device were to be damaged or lost.
-
-This was the key impulse which motivated us to create Anastasis,
-with the goal of enabling recovery of GNU Taler's backup keys via
-Anastasis.
-
-
-\subsubsection{Password managers}
-
-To avoid using low-entropy passwords and password reuse, some people
-use software password managers like
-KeePass\footnote{\url{https://keepass.info/}}. Such password managers
-relieve you of the burden of remembering many passwords and in most
-cases allow the generation of high-entropy passwords.
-
-The user only has to remember the password for the password
-manager. However, as discussed before, this is still a major problem:
-\begin{itemize}
- \item On the one hand, users could use an insecure, easy to
-remember password. In this case, an adversary gaining control
-over the password manager's database could break into all systems
-secured by keys managed by the password manager.
-\item On the other hand, users could use a complex, high-entropy
- passphrase. However, if that passphrase is forgotten, users
- face the loss of all passwords and thus also all online
- services that the password manager controlled for them.
-\end{itemize}
-
-Anastasis can be used to enable recovery of strong passphrases,
-such as those that should be used to secure password managers.
-
-
-\subsubsection{Hard drive encryption}
-
-Data at rest is often protected using (full) drive encryption, for
-example using software like
-LUKS\footnote{\url{https://guardianproject.info/archive/luks/}}. For
-encryption and decryption of the drive a combination of key files,
-passphrases and Trusted Platform Modules (TPMs)~\cite{bajikar2002} are
-used.
-
-Anastasis can be used to backup and restore such key files or
-passphrases.
diff --git a/doc/thesis/project_management.tex
b/doc/thesis/project_management.tex
deleted file mode 100644
index 826ef09..0000000
--- a/doc/thesis/project_management.tex
+++ /dev/null
@@ -1,25 +0,0 @@
-\section{Project management}
-
-This section describes the project planing of Anastasis. A detailed
-reflection on the work on Anastasis is in the work journal in the
-appendix.
-
-Figure~\ref{fig:project_plan_anastasis} shows our original project
-plan for implementing Anastasis and writing our Bachelor's thesis.
-
-\begin{figure}[H]
- \includegraphics[scale=0.5]{images/project_plan_anastasis.png}
- \caption{Anasasis project plan}
- \label{fig:project_plan_anastasis}
-\end{figure}
-
-We were able to write our thesis roughly according to our original
-project plan. The software development took a bit longer, as we had
-to relearn certain aspects of the C language and understand many APIs
-used by the overall system. Because of this, we cut the
-implementation of the complex authentication method from the plan.
-
-On the flip side, due to the interest of many groups and businesses in
-Anastasis, we invested more time than expected into the business part,
-including the pursuit for external funding, which we hope will enable
-us to launch a successful business with Anastasis.
diff --git a/doc/thesis/related_work.tex b/doc/thesis/related_work.tex
deleted file mode 100644
index 7f4d879..0000000
--- a/doc/thesis/related_work.tex
+++ /dev/null
@@ -1,484 +0,0 @@
-\section{Related work}
-
-This chapter explains some important cryptographic functions and which
-are used in Anastasis or related to our work. We also describe issues
-with existing solutions in this domain.
-
-\subsection{Cryptographic primitives}
-
-\subsubsection{Pseudo-randomness}
-
-A pseudo random generator (PRG) is an algorithm producing an infinite
-sequence of bits for which there is no efficient algorithm to
-distinguish it from a truly random sequence~\cite{vadhan2012}. The
-algorithm ``takes as input a short, perfectly random
-seed''~\cite{vadhan2012} which determines the output value.\\
-
-A pseudo random function (PRF) is a deterministic function which
-output is finite and indistinguishable from a true random
-function.~\cite{nielsen2002} PRFs can be constructed using
-PRGs.~\cite{GGM1986}
-
-\subsubsection{Hash function}
-
-Hash functions "compress a string of arbitrary length to a string of
-fixed length [...]"~\cite{Preneel1999}. The output of a hash function
-often is called a "hash". Hash functions in general should be very
-fast to compute. Cryptographic hash functions need to fulfil
-additional security requirements which are
-
-\begin{itemize}
- \item (first) pre-image resistance,
- \item second pre-image resistance,
- \item collision resistance,
- \item pseudo randomness, and the
- \item avalanche effect.
-\end{itemize}
-
-Pre-image resistance, also called the ``one way property'', means that
-for a given hash function $H$ and a hash value $H(x)$, it is
-computationally infeasible to find $x$.~\cite{SG2012} For example,
-since in Anastasis we derive the key to encrypt the personal details
-required for user authentication (e.g. the mobile phone number for
-authentication via SMS) using functions based on hash functions (see
-HKDF), it is very important that you cannot derive the corresponding
-input values from the key.
-
-The second pre-image resistance is described by following: For a given
-hash function $H$ and a hash value $H(x)$, it is computationally
-infeasible to find $x$ and $x'$ such that $H(x) = H(x')$ and $x \not=
-x'$.~\cite{SG2012} In Anastasis hash functions also are involved in
-signing our so called recovery document. Hence an attacker should not
-be able to create a malicious recovery document with the same hash
-value as the original one.
-
-The definition of collision resistance slightly differs from the
-second pre-image resistance: For a given hash function $H$, it is
-computationally infeasible to find a pair $x, y$ such that $H(x) =
-H(y)$ \cite{SG2012}.
-%CG: the text below does NOT related to collision resistance!
-%As we are using HKDFs for deriving keys in
-%Anastasis, an attacker should not be able to find some other input
-%values also leading to the same keys we use.
-Anastasis does not rely upon collision resistance in its use of hash
-functions. % CG: at least no case comes to mind for me right now...
-
-A cryptographic hash function should also behave as a pseudo random
-function. This means that although a hash function is purely
-deterministic, the output must not be predictable.
-
-The avalanche effect describes the property of an algorithm that
-causes a significant change of the output value, usually a bit
-flipping of more than half the output is desired, if the input is
-changed slightly (for example, flipping a single bit).~\cite{RK2011}
-The more bits are flipping in the output value the higher the entropy
-of the randomness of the hash function.
-
-There are many applications for cryptographic hash functions. For
-example, you can store the hash value of a passphrase instead of the
-passphrase itself in a computer to protect the passphrase. Another
-important application is verification of message integrity: Before and
-after transmission of a message one can calculate the hash values of
-it and compare hashes later to determine if the message changed during
-transmission.
-
-In Anastasis we use SHA-512~\cite{GJW2011} for fast hash functions.
-
-\subsubsection{HMAC}
-
-When it comes to integrity of messages during communication of two
-parties over an insecure channel Keyed-Hash Message Authentication
-Codes (HMAC) are used as check values. An HMAC function is based on a
-hash function and takes two arguments, a key $K$ and a message $M$:
-
-$HMAC_{K}(M) = H(K \oplus opad,H(K \oplus ipad, M))$ with "ipad" and
-"opad" being constants which fill up the key $K$ to the blocksize of
-the hash function~\cite{BCK1996}. The blocksize of a modern hash
-function like SHA-512 is 64 bytes.
-
-\subsubsection{HKDF}
-
-A HKDF is a key derivation function (KDF) based on HMAC. A KDF ``is a
-basic and essential component of cryptographic systems: Its goal is
-to take a source of initial keying material, usually containing some
-good amount of randomness, but not distributed uniformly or for which
-an attacker has some partial knowledge, and derive from it one or more
-cryptographically strong secret keys''~\cite{krawczyk2010}.
-
-Anastasis uses HKDFs based on SHA-512 to derive symmetric keys for
-encryption.
-
-\subsubsection{Argon2}
-
-Hash functions like SHA-512 are designed to be very fast. Therefore
-passwords being stored using this kind of hash are vulnerable to
-dictionary attacks with new hardware architectures like
-FPGAs~\cite{trimberger2012} and dedicated ASIC~\cite{madurawe2006}
-modules. But those architectures ``experience difficulties when
-operating on large amount of memory''~\cite{BDK2016}.
-
-In contrast to standard hash functions there are functions designed to
-be memory-hard. Argon2 is such a memory-hard function that won the
-Password Hashing Competition in 2015. It minimizes time-memory
-tradeoff~\cite{stamp2003} and thus maximizes the costs to implement an
-ASIC for given CPU computing time~\cite{BDK2016}. Aside from the fact
-that Argon2 makes dictionary attacks much harder, Argon2 can be used
-for another feature too: Memory-hard schemes like Argon2 are very
-useful for key derivation from low-entropy sources~\cite{BDK2016}.
-
-Argon2 is used in Anastasis to derive an identifier for the user from
-the user's attributes, which serve as low-entropy inputs.
-
-
-\subsection{Secret sharing}
-
-Secret splitting, also known as secret sharing, is a technique for
-distributing a secret amongst multiple recipients. This is achieved by
-assigning a share of the secret to each recipient. By combining a
-sufficient number of those shares, it is possible to reconstruct the
-secret. In a secret sharing theme the recipients of a share often are
-called \textit{players}. The figure who gives a share of the secret to
-the players is called \textit{dealer}.
-
-In Anastasis the user is the trusted dealer who splits the secret and
-also reconstructs it.
-
-\subsubsection{Shamir's secret sharing} \label{sec:rel:shamir}
-
-The algorithm ``Shamir's secret sharing'' is probably the most well
-known secret sharing scheme. It ``divide[s] data D into n pieces in
-such a way that D is easily reconstructible from any k pieces, but
-even complete knowledge of $k - 1$ pieces reveals absolutely no
-information about D''~\cite{shamir_sharing}.
-
-Shamir’s simple secret sharing scheme has two key limitations. First,
-it requires a trusted dealer who initially generates the secret to be
-distributed, and second the shares are not verifiable during
-reconstruction. Therefore, malicious shareholders could submit corrupt
-shares to prevent the system from reconstructing the secret --- without
-these corrupt shareholders being detectable as malicious. Furthermore,
-the dealer distributing the shares could be corrupt and distribute
-some inconsistent shares to the others. Also, in some scenarios the
-dealer cannot be trusted with the knowledge of the original core
-secret.
-
-Additionally, Shamir's secret sharing is inflexible because it is a
-simple $k$-out-of-$n$ threshold scheme. While this makes the scheme
-reasonably efficient even for big values of $n$, efficiency with
-respect to a large number of escrow providers and authorization
-procedures is not important for Anastasis: it is already difficult to
-conceive users providing more than a handful of authentication methods
-(Section~\ref{sec:rel:authentication} describes common choices.)
-
-For Anastasis, we thus decided to opt for more flexible approach that
-allows complex policies for recovery authorization, instead of only
-$k$-out-of-$n$. Each user of Anastasis is also able to decide which
-combinations of \textit{players}, which in case of Anastasis are the
-escrow providers, shall be permitted.
-
-\subsubsection{Verifiable secret sharing}
-
-Verifiability can be achieved by using so called commitment schemes
-like the Pederson commitment. It allows ``to distribute a secret to n
-persons such that each person can verify that he has received correct
-information about the secret without talking with other
-persons''~\cite{pedersen_sharing_0}. In his paper ``A Practical Scheme
-for Non-interactive Verifiable Secret
-Sharing''~\cite{feldman_sharing}, Paul Feldman combines the two
-schemes Shamir Secret Sharing and Pederson commitment. His algorithm
-for verifiable secret sharing (VSS), allows each recipient to
-verify the correctness of their share. But like in the Shamir Secret
-Sharing scheme, the dealer in the VSS scheme
-also can't be trusted with the knowledge of the original core secret.
-
-Because in Anastasis each user can act as their own trusted dealer,
-the shares must not be verified and therefore Anastasis do not need
-any form of VSS.
-
-\subsubsection{Distributed key generation}
-
-Distributed key generation (DKG) algorithms solve the problem of
-needing a trustworthy dealer by instead relying on a threshold of
-honest persons for key generation. Contrary to the above-mentioned
-schemes, in distributed key generation algorithms every participant is
-involved in key generation. The Pederson DKG is such ``a secret
-sharing scheme without a mutually trusted
-authority''~\cite{pedersen_sharing_5.2}. Basically, this DKG works as
-follows: First, each involved party generates a pre-secret and
-distributes it to all parties using the verifiable secret sharing
-scheme of Feldman. Afterwards, each party recombines the received
-shares, including its own pre-secret, to a share of the main
-secret. The main secret can be reconstructed by summing up each
-recombination of the shared pre-secrets.
-
-Because in Anastasis each user can act as their own trusted dealer, we
-also do not worry about the dealer learning the user's key and hence
-Anastasis do not need any form of DKG.
-
-\subsection{Authentication} \label{sec:rel:authentication}
-
-To build a secure authentication procedure, today multi-factor
-authentication is the standard~\cite{multifactor_authentication}. A
-single authentication method by itself is usually vulnerable.
-Multi-factor authentication combines multiple authentication
-procedures to enhance the security of the system.
-
-During procedure of some authentication methods a so called token is
-sent to the user. The user than has to provide the token to authorize.\\
-The token should be a randomly generated passphrase which has at
-least 128 bits of entropy. It is best practice for a token to have an
-expiration time, although this is not relevant for security of Anastasis.\\
-
-Anastasis is designed to use a wide range of authentication methods to
-authenticate its users. Even though the user in Anastasis is free to
-specify only one authentication method, we strongly recommend the use
-of multi-factor authentication, typically using different
-authentication methods at different providers.
-
-A short overview of common authentication methods and issues with
-each of them is presented here.
-
-\subsubsection{Password authentication}
-
-Password authentication is probably the most widely used
-authentication procedure. But as studies show the procedure has its
-drawbacks~\cite{authentication_methods_review}. For example the
-handling of the passwords, like storage or transmission, often is done
-poorly. Another problem is that the user must remember his
-password. Therefore the password is limited to the capabilities of the
-user to remember it. Thus people tend to use passwords with low
-entropy. Those passwords are vulnerable to brute force attacks or
-dictionary attacks. Another problem using passwords is the possibility
-of replay attacks: A password can be stolen by an eavesdropper during
-online transmission and used by the attacker.
-
-Because passwords can be forgotten, we do not recommend using this
-method for provider-authentication in Anastasis. Users could easily
-add a passwords into their set of ``invariant'' attributes used to
-derive the identity key, and then would automatically obtain all of
-the possible benefits (and drawbacks) from using a password.
-Specifically, they must make sure that the password cannot be
-forgotten, even if it means that the password has low entropy.
-
-\subsubsection{Secure question}
-
-Similar to password authentication the use of an authentication method
-based on a secure question requires the user to remember the correct
-answer to a specific question. The difference here is that the
-question provides a context that helps the user to remember the answer
-and the user does not necessarily need to memorize something
-new~\cite{just2004}.
-
-There are several variations to implement authentication using a
-secure question:
-
-\begin{itemize}
- \item The questions and answers are predefined.
- \item Just the questions are predefined.
- \item The user is free to create custom questions and answers.
-\end{itemize}
-
-The first option is the easiest one. But predefining the answers has
-the disadvantage being impersonal and inflexible. The questions must
-inevitably be general, which may allow an attacker to obtain answers
-by collecting public information about the victim, or even simply
-solving the challenge by brute-forcing trying all possible choices.
-Therefore the first option is not ideal.
-
-The second option is more applicable but has some drawbacks, too. For
-example there may be questions whose answers have multiple syntactic
-representations (for example, ``St.'' versus
-``Street'')~\cite{just2004}. Another problem could be a question whose
-answer may change over time. Asking for the favourite actor for
-example could be problematic. In addition, there is a challenge to
-define questions for all kind of people. Some people for example could
-not answer to the question, what the name of their pet is, because
-they do not have one.
-
-In case of the third option, we have all of the issues of the second
-one, but additionally there is the difficulty for the user to ask
-creative questions. A good question should only be answerable by the
-user. Also, it would be perfect to have the attacker on the wrong
-track by using ambiguous questions with word plays the adversary
-cannot easily comprehend.
-
-Authentication using a secure question requires checking the validity
-of an answer that may include private personal information.
-Consequently, Anastasis does not store the answers of secure questions
-in cleartext. Instead, Anastasis only stores the hash value of a
-(salted) answer. Thus the user only has to provide the hash value of
-the answer and not disclose the answer itself.
-
-\subsubsection{SMS authentication}
-
-Another way to authenticate users that have a mobile phone is to use
-SMS authentication. The most popular use case is the so called Mobile
-TAN used to authorize online banking transactions. A Mobile TAN is an
-SMS based One-Time Password (OTP), short SMS OTP. SMS OTPs ``were
-introduced to counter phishing and other attacks against
-authentication and authorization of Internet
-services''~\cite{MBSS2013}.
-
-However, SMS authentication is not very secure, as it relies on the
-security of the mobile network, which has various
-vulnerabilities~\cite{rieck_detection}. There are also specialized
-mobile trojans which are used to eavesdrop on these messages directly
-on the user's mobile device.
-
-While likely not as sensitive as answers to security questions, we
-still consider user's phone numbers as private information that
-deserves protection. Naturally, a service authenticating the user
-needs the phone number to send a message to the user during SMS
-authentication.
-
-Hence, Anastasis providers have to learn the phone number during SMS
-authentication. However, we can use cryptography to ensure that the
-provider only gets the keys to decrypt the phone number when the
-authentication process is started by the user as part of a recovery
-operation. Thus, a compromise of the provider's database would not
-directly reveal the phone numbers to the attacker.
-
-
-\subsubsection{E-mail authentication}
-
-Authentication by email is similar to SMS authentication. Here,
-the user receives a token by email and has to provide it during the
-authentication process.
-
-It is important that the email should not already contain the
-requested information, so in the case of Anastasis the keyshare. This
-is because the SMTP protocol used for email offers no hard security
-assurances. In particular, the email is likely to be stored for a
-indefinite period in the user's mailbox, which could be easily
-compromised and read by a mailbox provider.~\cite{emailauthowasp}
-
-Like with SMS authentication, Anastasis also encrypts the email
-addresses when they are stored at the provider. The user has to
-provide the corresponding decryption key to the server during
-the authentication process.
-
-
-\subsubsection{VideoIdent}
-
-VideoIdent uses a video chat to verify the identity of a user. The
-user needs to show their face using a camera to an employee of the
-VideoIdent service. The service then verifies the identity of the user
-by comparing the video stream to a picture of the
-user~\cite{pohlmann2017}.
-
-Prerequisites for error-free identification are a video camera with
-good video quality and a high-resolution image of the user on which
-the face can be clearly seen. The user should also not change their
-outward appearance too much over time. For example, growing or
-trimming a beard could lead to the VideoIdent-service employee not
-being able to recognise a user with sufficient confidence.
-
-For an attacker who looks similar to the user, there is a chance that
-the employee incorrectly confirms the identification.
-
-%CG: that's IMO then e-mail based verification, should not mix
-% the two: this is basically multi-factor, so I'd leave it out here!
-%Therefore, some interaction of the user is needed like for example
-%telling the employee a short code which has been sent right before to
-%the user by mail.
-
-In Anastasis, pictures of users for VideoIdent authentication are
-considered private information stored encrypted at the providers.
-During the authentication process, the user has to provide the correct
-key for decryption to the service.
-
-\subsubsection{PostIdent}
-
-It is also possible to sent a verification code to the user by
-physical mail. A major drawback of this authentication method is
-that it has high latency, and there is also the possibility that
-physical mail gets intercepted or lost during transmission.
-
-Anastasis providers using PostIndent would not store the address of
-their users in cleartext. Instead the address is encrypted by the user
-and the provider would receive the key to decrypt the address only
-during the authentication process.
-
-\subsubsection{Biometric authentication}
-
-Another way of authenticating is the biometric
-approach~\cite{biometric_auth}. Biometric authentication is based on
-``something you are'', like your iris or your fingerprint.
-
-Biometric authentication is highly problematic because the attributes
-are invariant and frequently shared involuntarily. Unlike passphrases
-or phone numbers, users cannot change their genome or fingerprint in
-case their private biometric information is exposed. Furthermore,
-there are credible threats against biometric authentication, in
-paritcular there are documented inexpensive attacks against
-fingerprint and iris scan authentication. For example, a member of the
-German CCC e.V. was able to generate replicas from Angela Merkel's
-iris and Ursula von der Leyen's fingerprint~\cite{ccc_merkel}.
-
-
-
-\subsection{Existing solutions for key recovery}
-
-This section introduces some existing solutions for key recovery and
-why they are problematic.
-
-
-\subsubsection{Coinbase}
-
-Coinbase\footnote{\url{https://www.coinbase.com/}} is a global digital
-asset exchange company, providing a venue to buy and sell digital
-currencies. Coinbase also uses wallets secured with private keys. To
-recover this private key the user has to provide a 12 words recovery
-phrase.
-
-Coinbase offers a solution to securely deposit this recovery phrase
-onto the users Google Drive or iCloud.~\cite{coinbase} The security
-here lies within the Google or iCloud account and another password
-used to encrypt the security phrase. The problem here is that this
-approach undermines confidentiality, as encrypting a strong key with a
-weak key simply reduces the security to that of the weaker key.
-
-\subsubsection{MIDATA}
-
-MIDATA is a project that aims to give patients back control over their
-medical data and to enable them to share their data only with those
-they trust.\footnote{\url{https://www.midata.coop/}} In case a patient
-lost their device with the MIDATA-application and also forgot their
-MIDATA password, MIDATA provides a key recovery system using the
-Shamir Secret Sharing scheme (as described in
-Section~\ref{sec:rel:shamir}).
-
-In their case, a few ``persons working at MIDATA have generated a
-public-private key pair (Recovery key) on their own computer. They
-keep the private recovery key for themselves and never share it. The
-public keys are made public so that the apps can also access
-them''~\cite{midata}. Using Shamir's Secret Sharing the MIDATA
-application splits the user's app private key into 5 parts which are
-encrypted with one of the published recovery keys. The encrypted parts
-are then stored into the MIDATA server. During the recovery process at
-least two of the 5 parts need to be decrypted by the persons owning
-the private key part of the recovery key. ``The decrypted parts are
-sent to the server and {\em the server} may now reconstruct the app
-private key if enough parts of the key have been
-decrypted''~\cite{midata}. (Emphasis ours.)
-
-The security of MIDATA as described in ``Patient empowerment in IoT
-for eHealth - How to deal with lost keys?''~\cite{midata} is broken in
-three ways:
-
-\begin{enumerate}
- \item The password is reconstructed at {\em the server}, not on the
- patients device. An administrator of the server could thus
- access the recovered password at that time. It would be better
- to reconstruct the password only on the patients device.
- \item It is not clear which authentication methods the persons
- working for MIDATA use for their decisions and activities regarding
- the key recovery. The business process used here could be
- vulnerable, and it is not clear whether multi-factor authentication
- is used. As a result, we worry that it may be possible for an attacker
- to successfully use social engineering via email (or other means)
- to illegitimately trigger a recovery process.
- \item The MIDATA system also does not offer any trust
agility~\cite{marlinspike2011}.
- The user is forced to accept the 2-out-of-5 rule with trustees
- provided by MIDATA.
-\end{enumerate}
diff --git a/doc/thesis/rest_api_documentation.tex
b/doc/thesis/rest_api_documentation.tex
deleted file mode 100644
index 4d53fb6..0000000
--- a/doc/thesis/rest_api_documentation.tex
+++ /dev/null
@@ -1,333 +0,0 @@
-%\title{Anastasis REST API}
-%\date{\today} %% or \date{01 november 2018}
-%\author{Dominik Meister (\texttt{dominiksamuel.meister@students.bfh.ch}) \\
-% Dennis Neufeld (\texttt{dennis.neufeld@students.bfh.ch })}
-%\maketitle
-%\clearpage
-
-\section{REST API documentation} \label{appendix_server_api}
-The server api is a RESTful API which has the following endpoints.
-
-\subsection*{Obtain Salt}
-\textbf{GET /salt}
-\\
-Obtain the salt used by the escrow provider. Different providers will use
different high-entropy salt values. The resulting provider salt is then used in
various operations to ensure cryptographic operations differ by provider. A
provider must never change its salt value. \\
-\textbf{Response: } \\
-Returns a "SaltResponse".
-\begin{lstlisting}
-interface SaltResponse {
- // salt value, at least 128 bits of entropy
- server_salt: string;
-}
-\end{lstlisting}
-
-\subsection*{Obtain terms of service}
-\textbf{GET /terms}
-\\
-Obtain the terms of service provided by the escrow provider.
-\\
-\textbf{Response: } \\
-Returns an EscrowTermsOfServiceResponse. \\
-
-\begin{lstlisting}
-interface EscrowTermsOfServiceResponse {
-
- // minimum supported protocol version
- min_version: number;
-
- // maximum supported protocol version
- max_version: number;
-
- // supported authentication methods
- auth_methods: AuthenticationMethod[];
-
- // Payment required to maintain an account to store
- // policy documents for a month.
- // Users can pay more, in which case the storage time
- // will go up proportionally.
- monthly_account_fee: Amount;
-
- // Amount required per policy upload. Note that the amount is NOT
- // charged additionally to the monthly_storage_fee. Instead,
- // when a payment is made, the amount is divided by the policy_upload_fee
- // (and rounded down) to determine how many uploads can be made
- // under the associated payment identifier.
- policy_upload_ratio: Amount;
-
- // maximum policy upload size supported
- policy_size_limit_in_bytes: number;
-
- // maximum truth upload size supported
- truth_size_limit_in_bytes: number;
-
- // how long until the service expires deposited truth
- // (unless refreshed via another POST)?
- truth_expiration: RelativeTime;
-
- // Payment required to upload truth. To be paid per upload.
- truth_upload_fee: Amount;
-
- // Limit on the liability that the provider is offering with
- // respect to the services provided.
- liability_limit: Amount;
-
- // HTML text describing the terms of service in legalese.
- // May include placeholders like "${truth_upload_fee}" to
- // reference entries in this response.
- tos: string;
-}
-\end{lstlisting}
-
-\begin{lstlisting}
-interface AuthenticationMethod {
- // name of the authentication method
- name: string;
-
- // Fee for accessing truth using this method
- usage_fee: Amount;
-
-}
-\end{lstlisting}
-
-\subsection*{Manage Policy}
-This API is used by the Anastasis client to deposit or request encrypted
recovery documents with the escrow provider. Generally, a client will deposit
the same encrypted recovery document with each escrow provider, but provide
different truth to each escrow provider. \\
-\\
-Operations by the client are identified and authorized by \$ACCOUNT\_PUB,
which should be kept secret from third parties. \$ACCOUNT\_PUB should be an
account public key using the Crockford base32-encoding.\\
-\\
-\textbf{GET /policy/\$ACCOUNT\_PUB[?version=\$NUMBER]} \\
-\\
-Get the customer’s encrypted recovery document. If “version” is not specified,
the server returns the latest available version. If “version” is specified,
returns the policy with the respective “version”. The response must begin with
the nonce and an AES-GCM tag and continue with the ciphertext. Once decrypted,
the plaintext is expected to contain:
-\begin{itemize}
-\item the escrow policy
-\item the separately encrypted master key
-\end{itemize}
-
-\textbf{Status Codes: } \\
-\begin{itemize}
-\item 200 OK – The escrow provider responds with an EncryptedRecoveryDocument
object.
-\item 304 Not modified – The client requested the same resource it already
knows.
-\item 400 Bad request – The \$ACCOUNT\_PUB is not an EdDSA public key.
-\item 402 Payment Required – The account’s balance is too low for the
specified operation. See the Taler payment protocol specification for how to
pay.
-\item 403 Forbidden – The required account signature was invalid.
-\item 404 Not Found – The requested resource was not found.
-\end{itemize}
-Note that the key shares required to decrypt the master public key are not
included, as for this the client needs to obtain authorization. The policy does
provide sufficient information for the client to determine how to authorize
requests for truth. \\
- \\
-The client MAY provide an “If-None-Match” header with an Etag. In that case,
the server MUST additionally respond with an “304” status code in case the
resource matches the provided Etag.\\
- \\
-Anastasis-Version: \$NUMBER — The server must return actual version of the
encrypted recovery document via this header. If the client specified a version
number in the header of the request, the server must return that version. If
the client did not specify a version in the request, the server returns latest
version of the EncryptedRecoveryDocument.\\
- \\
-Etag: Set by the server to the Base32-encoded SHA512 hash of the body. Used
for caching and to prevent redundancies. The server MUST send the Etag if the
status code is 200 OK.\\
- \\
-If-None-Match: If this is not the very first request of the client, this
contains the Etag-value which the client has reveived before from the server.
The client SHOULD send this header with every request (except for the first
request) to avoid unnecessary downloads.\\
- \\
-Anastasis-Account-Signature: The client must provide Base-32 encoded EdDSA
signature over hash of body with \$ACCOUNT\_PRIV, affirming desire to download
the requested encrypted recovery document. The purpose used MUST be
TALER\_SIGNATURE\_ANASTASIS\_POLICY\_DOWNLOAD (1401).\\
-\newline
-\textbf{POST /policy/\$ACCOUNT\_PUB} \\
-Upload a new version of the customer’s encrypted recovery document. While the
document’s structure is described in JSON below, the upload should just be the
bytestream of the raw data (i.e. 32 bytes nonce followed by 16 bytes tag
followed by the encrypted document). If request has been seen before, the
server should do nothing, and otherwise store the new version. The body must
begin with a nonce, an AES-GCM tag and continue with the ciphertext. The format
is the same as specified for th [...]
- \\
-\textbf{Status Codes: } \\
-\begin{itemize}
-\item 204 No Content – The encrypted recovery document was accepted and
stored. “Anastasis-Version” indicate what version was assigned to this
encrypted recovery document upload by the server.
-\item 304 Not modified – The same encrypted recovery document was previously
accepted and stored. “Anastasis-Version” header incidates what version was
previously assigned to this encrypted recovery document.
-\item 400 Bad request – The \$ACCOUNT\_PUB is not an EdDSA public key or
mandatory headers are missing. The response body MUST elaborate on the error
using a Taler error code in the typical JSON encoding.
-\item 402 Payment Required – The account’s balance is too low for the
specified operation. See the Taler payment protocol specification for how to
pay. The response body MAY provide alternative means for payment.
-\item 403 Forbidden – The required account signature was invalid. The response
body may elaborate on the error.
-\item 409 Conflict – The If-Match Etag does not match the latest prior version
known to the server.
-\item 413 Request Entity Too Large – The upload is too large or too small. The
response body may elaborate on the error.
-\end{itemize}
-\textit{If-Match:} Unless the client expects to upload the first encrypted
recovery document to this account, the client should provide an Etag matching
the latest version already known to the server. If this header is present, the
server MUST refuse the upload if the latest known version prior to this upload
does not match the given Etag. \\
-\textit{If-None-Match:} This header must be present and set to the SHA512 hash
(Etag) of the body by the client. The client should also set the “Expect:
100-Continue” header and wait for “100 continue” before uploading the body. The
server MUST use the Etag to check whether it already knows the encrypted
recovery document that is about to be uploaded. The server MUST refuse the
upload with a “304” status code if the Etag matches the latest version already
known to the server.\\
-\textit{Anastasis-Policy-Signature:} The client must provide Base-32 encoded
EdDSA signature over hash of body with \$ACCOUNT\_PRIV, affirming desire to
upload an encrypted recovery document.\\
-\textit{Payment-Identifier:} Base-32 encoded 32-byte payment identifier that
was included in a previous payment (see 402 status code). Used to allow the
server to check that the client paid for the upload (to protect the server
against DoS attacks) and that the client knows a real secret of financial value
(as the kdf\_id might be known to an attacker). If this header is missing in
the client’s request (or the associated payment has exceeded the upload limit),
the server must return a 40 [...]
- \\
-\begin{lstlisting}
-interface EncryptedRecoveryDocument {
- // Nonce used to compute the (iv,key) pair for encryption
- // of the encrypted_compressed_recovery_document.
- nonce: [32]; //bytearray
-
- // Authentication tag
- aes_gcm_tag: [16]; //bytearray
-
- // Variable-size encrypted recovery document. After decryption,
- // this contains a gzip compressed JSON-encoded RecoveryDocument.
- // The nonce of the HKDF for this encryption must include the
- // string "ERD".
- // bytearray of undefined length
- encrypted_compressed_recovery_document: [];
-
-}
-\end{lstlisting}
-\begin{lstlisting}
-
-interface RecoveryDocument {
- // Account identifier at backup provider, AES-encrypted with
- // the (symmetric) master_key, i.e. an URL
- // https://sync.taler.net/$BACKUP_ID and
- // a private key to decrypt the backup. Anastasis is oblivious
- // to the details of how this is ultimately encoded.
- backup_account: []; //bytearray of undefined length
-
- // List of escrow providers and selected authentication method
- methods: EscrowMethod[];
-
- // List of possible decryption policies
- policy: DecryptionPolicy[];
-
-}
-\end{lstlisting}
-
-\begin{lstlisting}
-interface EscrowMethod {
- // URL of the escrow provider
- // (including possibly this Anastasis server)
- provider_url : string;
-
- // Name of the escrow method (e.g. security question, SMS etc.)
- escrow_method: string;
-
- // truth_seed of the escrow method (see /truth/ API below).
- truth_seed: [32]; //bytearray
-
- // Key used to encrypt the Truth this EscrowMethod is related to.
- // Client has to provide this key to the server when using /truth/
- truth_encryption_key: [32]; //bytearray
-
- // Salt used to encrypt the truth on the Anastasis server.
- truth_salt: [32]; //bytearray
-
- // The challenge to give to the user (i.e. the security question
- // if this is challenge-response).
- // (Q: as string in base32 encoding?)
- // (Q: what is the mime-type of this value?)
- //
- // For some methods, this value may be absent.
- //
- // The plaintext challenge is not revealed to the
- // Anastasis server.
- challenge: []; //bytearray of undefined length
-}
-
-\end{lstlisting}
-
-\begin{lstlisting}
-interface DecryptionPolicy {
- // Salt included to encrypt master key share when
- // using this decryption policy.
- policy_salt: [32]; //bytearray
-
- // Master key, AES-encrypted with key derived from
- // salt and keyshares revealed by the following list of
- // escrow methods identified by the truth_seeds.
- encrypted_master_key: [32]; //bytearray
-
- // List of escrow methods identified by their truth_seed.
- truth_seeds: []; //array of truth_seed
-
-}
-\end{lstlisting}
-
-\subsection*{Manage Truth}
-This API is used by the Anastasis client to deposit truth or request a
(encrypted) key share with the escrow provider.\\
-\newline
-An escrow method specifies an Anastasis provider and how the user should
authorize themself. The truth API allows the user to provide the (encrypted)
key share to the respective escrow provider, as well as auxiliary data required
for such an respective escrow method. \\
-\newline
-Operations by the client are identified and authorized by \$TRUTH\_PUB, which
should be kept secret from third parties. \$TRUTH\_PUB should be a public key
using the Crockford base32-encoding.\\
-\newline
-An Anastasis-server may store truth for free for a certain time period, or
charge per truth operation using GNU Taler. \\
-\newline
-\textbf{POST /truth/\$TRUTH\_PUB}
-\newline
-Upload a TruthUploadRequest-Object according to the policy the client created
before (see RecoveryDocument). If request has been seen before, the server
should do nothing, and otherwise store the new object. \\
-\newline
-\textbf{Status Codes: } \\
-\begin{itemize}
-\item 204 No content – Truth stored successfully.
-\item 304 Not modified – The same truth was previously accepted and stored
under this \$TRUTH\_PUB. The Anastasis server must still update the expiration
time for the truth when returning this response code.
-\item 402 Payment Required – This server requires payment to store truth per
item. See the Taler payment protocol specification for how to pay. The response
body MAY provide alternative means for payment.
-\item 409 Conflict – The server already has some truth stored under this
TRUTH\_PUB. The client should check that it is generating \$TRUTH\_PUB with
enough entropy.
-\item 412 Precondition Failed – The selected authentication method is not
supported on this provider.
-\end{itemize}
-\textbf{Details:}
-\begin{lstlisting}
-interface TruthUploadRequest {
- // Contains the information of an interface EncryptedKeyShare,
- // but simply as one binary block (in Crockford Base32
- // encoding for JSON).
- key_share_data: []; //bytearray
-
- // Key share method, i.e. "security question", "SMS", "e-mail", ...
- method: string;
-
- // Nonce used to compute the (iv,key) pair for encryption of the
- // encrypted_truth.
- nonce: [32]; //bytearray
-
- // Signature over the key_share signed with TRUTH_PRIV.
- key_share_signature: EddsaSignature;
-
- // Variable-size truth. After decryption,
- // this contains the ground truth, i.e. H(challenge answer),
- // phone number, e-mail address, picture, fingerprint, ...
- // **base32 encoded**.
- //
- // The nonce of the HKDF for this encryption must include the
- // string "ECT".
- encrypted_authentication_data: []; //bytearray
-
- // Signature over the key_share signed with TRUTH_PRIV.
- authentication_data_signature: EddsaSignature;
-
- // mime type of truth, i.e. text/ascii, image/jpeg, etc.
- truth_mime: string;
-}
-\end{lstlisting}
-\textbf{GET /truth/\$TRUTH\_PUB[?response=\$RESPONSE]} \\
- \\
-Get the stored encrypted key share. If \$RESPONSE is specified by the client,
the server checks if \$RESPONSE matches the expected response specified before
within the TruthUploadRequest (see encrypted\_truth). Also, the user has to
provide the correct truth\_encryption\_key with every get request (see below).
When \$RESPONSE is correct, the server responses with the encrypted key share.
The encrypted key share is returned simply as a byte array and not in JSON
format. \\
-
-\textbf{Status Codes: } \\
-\begin{itemize}
-\item 200 OK – EncryptedKeyShare is returned in body (in binary).
-\item 202 Accepted – The escrow provider will respond out-of-band (i.e. SMS).
The body may contain human-readable instructions on next steps.
-\item 303 See Other – The provider redirects for authentication (i.e. video
identification/WebRTC). If the client is not a browser, it should launch a
browser at the URL given in the “Location” header and allow the user to re-try
the operation after successful authorization.
-\item 402 Payment Required – The service requires payment for access to truth.
See the Taler payment protocol specification for how to pay. The response body
MAY provide alternative means for payment.
-\item 403 Forbidden – The server requires a valid “response” to the challenge
associated with the \$TRUTH\_PUB.
-\item 404 Not Found – The server does not know any truth under the given
TRUTH\_PUB.
-\item 503 Service Unavailable – Server is out of Service.
-\end{itemize}
-
-\textbf{Truth-Decryption-Key:} Key used to encrypt the truth (see
encrypted\_truth within TruthUploadRequest) and which has to provided by the
user. The key is stored with the according EscrowMethod. The server needs this
key to get the info out of TruthUploadRequest needed to verify the \$RESPONSE.\\
-\textbf{authentication\_data\_signature:} The client must provide Base-32
encoded EdDSA signature over the hash of the encrypted\_authentication\_data
with \$TRUTH\_PRIV.\\
-\textbf{key\_share\_signature:} The client must provide Base-32 encoded EdDSA
signature over hash of the encrypted\_key\_key\_share with \$TRUTH\_PRIV.
- \\
-\textbf{Details:}
-\begin{lstlisting}
-interface EncryptedKeyShare {
- // Nonce used to compute the decryption (iv,key) pair.
- nonce_i: [32]; //bytearray
-
- // Encrypted key-share in base32 encoding.
- // After decryption, this yields a KeyShare. Note that
- // the KeyShare MUST be encoded as a fixed-size binary
- // block (instead of in JSON encoding).
- //
- // HKDF for the key generation must include the
- // string "eks" as salt. Depending on the method,
- // the HKDF may additionally include
- // bits from the response (i.e. some hash over the
- // answer to the security question)
- encrypted_key_share_i: [32]; //bytearray
-}
-\end{lstlisting}
-\begin{lstlisting}
-interface KeyShare {
- // Key material to concatenate with policy_salt
- // and KDF to derive the key to decrypt the master key.
- key_share: [32]; //bytearray
-
- // Signature over the key_share signed with TRUTH\_PRIV.
- account_sig: EddsaSignature;
-}
-\end{lstlisting}
diff --git a/doc/thesis/server_architecture.tex
b/doc/thesis/server_architecture.tex
deleted file mode 100644
index 264f488..0000000
--- a/doc/thesis/server_architecture.tex
+++ /dev/null
@@ -1,134 +0,0 @@
-\subsection{Server architecture} \label{sec:serverarch}
-
-The Anastasis server architecture consists of two components. A web
-server with a REST API and a PostgreSQL database. The structure of
-these two components is shown in Figure~\ref{fig:anastasis:server}.
-
-\begin{figure}[H]
- \centering
- \includegraphics[scale=0.45]{images/server_api.png}
- \caption{Anastasis server architecture}
- \label{fig:anastasis:server}
-\end{figure}
-
-The webserver of Anastasis provides a RESTful API. For a detailed
-documentation of the REST API, see
-appendix ~\ref{appendix_server_api}.
-
-\newpage
-\subsubsection{Database}
-
-The database schema of Anastasis is shown in
-Figure~\ref{fig:anastasis_database}.
-\begin{figure}[H]
- \centering
- \includegraphics[scale=0.5]{images/anastasis-db.png}
- \caption{Anastasis database schema}
- \label{fig:anastasis_database}
-\end{figure}
-
-The database schema consists of four main tables:
-
-\begin{itemize}
-\item The {\em Truth} table is responsible for storing the key shares and
- its authentication method. The key share and the authentication data are
stored
- encrypted in the database. The authentication data is only decrypted during
- authentication. The key share is never decrypted for the
- server. This protects the privacy of the customer. Likewise, the
- user data is protected after a possible theft.
-\item The {\em User} table contains the identification of the user and an
- expiration timestamp. This timestamp is a subscription period. This
- timestamp is updated after each payment the user makes. Users for
- whom the subscription has expired are periodically deleted.
-\item The {\em Payments} table contains the details of a payment from a
- user. The payment is used either for the post-counter or the
- subscription. The post-counter is decremented after each upload of a
- recovery document. The user can only upload the recovery document if
- the provided payment contains a post-counter which is at least 1.
- Through this measure we can prevent people from maliciously filling
- our database.
-\item The {\em Recoverydocument} table contains the recovery
- information. The recovery document is stored encrypted in the
- database. This offers better protection, as explained earlier for
- the Truth table. Each recovery document record also contains a
- version, a hash of the recovery document and a signature. The
- version attribute allows the user to lookup a specific version of
- the document. The hash is used to check if the user uploads a
- duplicate of the document. The signature attests the
- integrity of the recovery data.
-\end{itemize}
-
-
-\subsubsection{Authentication methods}
-
-This section describes an overview over the different possible
-authentication methods for Anastasis. In our implementation only the
-secure question is implemented. The other methods are just explained
-how they would be implemented.
-
-In all cases, the authentication process begins by the user decrypting
-their (encrypted) recovery document, which contains a list of Anastasis
-providers, associated authentication methods, truth\_seeds and associated
-truth encryption keys. The recovery process than varies slightly
-depending on the authentication method.
-
-\paragraph{SMS (sms)}
-
-The user tells the server with a request that they wants to authorize
-key recovery (via GET /truth/\$TRUTH\_PUB), providing a way to decrypt the
-truth with the phone number. The server will then generate a \$PIN and
-send it via an SMS provider to the stored number in the truth
-object. The client then must send another request with the sent \$PIN
-(via GET /truth/\$TRUTH\_PUB?response=\$PIN). The server can now check
-if the two PINs match. Upon success, the server returns the encrypted
-key share.
-
-\paragraph{Video identification (vid)}
-
-This method allows the user to identify via video-call. Since the
-respective images must be passed on to the video identification
-service in the event of password recovery, it must be ensured that no
-further information about the user can be derived from them. Hence,
-the user's client software must try to delete metadata that could
-result in accidental information leakage about the user from the image
-before encrypting and uploading it to the Anastasis provider.
-
-For recovery, the user must first send a request to server that they
-wants to authorize recovery (GET /truth/\$TRUTH\_PUB). The Anastasis
-provider will then decrypt the user's image and send a request with a
-\$TOKEN to a video authentication provider that a user wants to
-authenticate, and respond to the user with a link to a video
-conference. The video authentication provider then checks via video
-conference that the user in the image is the same that they have on
-the video link. Upon success, the video provider releases the \$TOKEN
-to the user. The client then must send another request with the
-\$TOKEN (via GET /truth/\$TRUTH\_PUB?response=\$TOKEN). The Anastasis
-provider checks that the tokens match, and upon success returns the
-encrypted key share.
-
-\paragraph{Post identification (post)}
-
-The user tells the Anastasis provider with a request that they want
-to authenticate using Post identification (GET /truth/\$TRUTH\_PUB). The
-Anastasis provider uses the request to decrypt the user's truth to
-determine the user's postal address, and sends them letter containing
-a \$PIN. Upon receiving the letter, the client then has to send
-another request with the \$PIN (GET /truth/\$TRUTH\_PUB?response=\$PIN). The
-server can now check if the two PINs match. Upon success the server
-will release the encrypted key share.
-
-\paragraph{Security question (qa)}
-
-The user provided Anastasis with a secure question and a (normalized)
-answer. The secure question becomes part of the encrypted recovery
-document, and is never disclosed to weak adversaries, even during
-recovery. The encrypted truth on the server only contains a (salted)
-hash of the answer. The Anastasis provider cannot learn the plaintext
-answer. Because of the salt, and it cannot mount a confirmation attack
-either.
-
-If the user wants to recover the key share from the server, they must
-provide the (salted) hash of the answer to the security question (via
-GET /truth/\$TRUTH\_PUB?response=\$HASH). The server then checks if the
-stored and the provided hash match. Upon success the server responds
-with the encrypted key share.
diff --git a/doc/thesis/thesis.bbl b/doc/thesis/thesis.bbl
deleted file mode 100644
index efd9b6e..0000000
--- a/doc/thesis/thesis.bbl
+++ /dev/null
@@ -1,1412 +0,0 @@
-% $ biblatex auxiliary file $
-% $ biblatex bbl format version 3.1 $
-% Do not modify the above lines!
-%
-% This is an auxiliary file used by the 'biblatex' package.
-% This file may safely be deleted. It will be recreated by
-% biber as required.
-%
-\begingroup
-\makeatletter
-\@ifundefined{ver@biblatex.sty}
- {\@latex@error
- {Missing 'biblatex' package}
- {The bibliography requires the 'biblatex' package.}
- \aftergroup\endinput}
- {}
-\endgroup
-
-
-\refsection{0}
- \datalist[entry]{none/global//global/global}
- \entry{jerome2015}{article}{}
- \name{author}{4}{}{%
- {{hash=e042fd1cbe6bde0a3c8d7e8074ded97f}{%
- family={J{é}r{ô}me},
- familyi={J\bibinitperiod},
- given={Brugger},
- giveni={B\bibinitperiod}}}%
- {{hash=4b13ebea2e8187b9e7ee5a28ece70bf7}{%
- family={Angelina},
- familyi={A\bibinitperiod},
- given={BFH\bibnamedelima Dungga},
- giveni={B\bibinitperiod\bibinitdelim D\bibinitperiod}}}%
- {{hash=7dc3b7da04ebf4e193781c6ca4441dd1}{%
- family={Esther},
- familyi={E\bibinitperiod},
- given={BFH\bibnamedelima Hefti},
- giveni={B\bibinitperiod\bibinitdelim H\bibinitperiod}}}%
- {{hash=f4116824e8f06450be45803d598ab7d1}{%
- family={ZH},
- familyi={Z\bibinitperiod},
- given={Kt},
- giveni={K\bibinitperiod}}}%
- }
- \list{organization}{1}{%
- {BFH}%
- }
- \strng{namehash}{7c1cd3857fa434fc3f5603bf8f77898f}
- \strng{fullhash}{2a4edbd7fe20c9aeda5b1dfcb9ebb082}
- \strng{bibnamehash}{2a4edbd7fe20c9aeda5b1dfcb9ebb082}
- \strng{authorbibnamehash}{2a4edbd7fe20c9aeda5b1dfcb9ebb082}
- \strng{authornamehash}{7c1cd3857fa434fc3f5603bf8f77898f}
- \strng{authorfullhash}{2a4edbd7fe20c9aeda5b1dfcb9ebb082}
- \field{sortinit}{1}
- \field{sortinithash}{50c6687d7fc80f50136d75228e3c59ba}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{title}{AHV-Nummer als einheitlicher,
organisations{ü}bergreifender Personenidentifikator}
- \field{year}{2015}
- \endentry
- \entry{garfinkel1995}{book}{}
- \name{author}{1}{}{%
- {{hash=f7ae1c1e91c1c29835e2ff7e98908fa7}{%
- family={Garfinkel},
- familyi={G\bibinitperiod},
- given={Simson},
- giveni={S\bibinitperiod}}}%
- }
- \list{publisher}{1}{%
- {" O'Reilly Media, Inc."}%
- }
- \strng{namehash}{f7ae1c1e91c1c29835e2ff7e98908fa7}
- \strng{fullhash}{f7ae1c1e91c1c29835e2ff7e98908fa7}
- \strng{bibnamehash}{f7ae1c1e91c1c29835e2ff7e98908fa7}
- \strng{authorbibnamehash}{f7ae1c1e91c1c29835e2ff7e98908fa7}
- \strng{authornamehash}{f7ae1c1e91c1c29835e2ff7e98908fa7}
- \strng{authorfullhash}{f7ae1c1e91c1c29835e2ff7e98908fa7}
- \field{sortinit}{2}
- \field{sortinithash}{ed39bb39cf854d5250e95b1c1f94f4ed}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{title}{PGP: pretty good privacy}
- \field{year}{1995}
- \endentry
- \entry{pepdoc}{online}{}
- \list{organization}{1}{%
- {pEp Security SA}%
- }
- \field{sortinit}{3}
- \field{sortinithash}{a37a8ef248a93c322189792c34fc68c9}
- \field{labeltitlesource}{title}
- \field{title}{Welcome to p≡p Documentation!}
- \field{urlday}{6}
- \field{urlmonth}{6}
- \field{urlyear}{2020}
- \field{year}{2020}
- \field{urldateera}{ce}
- \verb{urlraw}
- \verb https://www.pep.security/docs/
- \endverb
- \verb{url}
- \verb https://www.pep.security/docs/
- \endverb
- \endentry
- \entry{caronni2000}{inproceedings}{}
- \name{author}{1}{}{%
- {{hash=881bf2fe8d7563c67a7bf0dca669ec1e}{%
- family={Caronni},
- familyi={C\bibinitperiod},
- given={Germano},
- giveni={G\bibinitperiod}}}%
- }
- \list{organization}{1}{%
- {IEEE}%
- }
- \strng{namehash}{881bf2fe8d7563c67a7bf0dca669ec1e}
- \strng{fullhash}{881bf2fe8d7563c67a7bf0dca669ec1e}
- \strng{bibnamehash}{881bf2fe8d7563c67a7bf0dca669ec1e}
- \strng{authorbibnamehash}{881bf2fe8d7563c67a7bf0dca669ec1e}
- \strng{authornamehash}{881bf2fe8d7563c67a7bf0dca669ec1e}
- \strng{authorfullhash}{881bf2fe8d7563c67a7bf0dca669ec1e}
- \field{sortinit}{4}
- \field{sortinithash}{e071e0bcb44634fab398d68ad04e69f4}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{booktitle}{Proceedings IEEE 9th International Workshops on
Enabling Technologies: Infrastructure for Collaborative Enterprises (WET ICE
2000)}
- \field{title}{Walking the web of trust}
- \field{year}{2000}
- \field{pages}{153\bibrangedash 158}
- \range{pages}{6}
- \endentry
- \entry{LLLW*2017}{inproceedings}{}
- \name{author}{7}{}{%
- {{hash=c4d8c39e3a63acab6d94c490b6d45028}{%
- family={Liu},
- familyi={L\bibinitperiod},
- given={Yi},
- giveni={Y\bibinitperiod}}}%
- {{hash=3e1f0e5c79944a684b0e981db2d979bf}{%
- family={Li},
- familyi={L\bibinitperiod},
- given={Ruilin},
- giveni={R\bibinitperiod}}}%
- {{hash=ded616c8fbaf16eea249759846a9c40f}{%
- family={Liu},
- familyi={L\bibinitperiod},
- given={Xingtong},
- giveni={X\bibinitperiod}}}%
- {{hash=c33641e67eeaefc87b7821dc9b51ff90}{%
- family={Wang},
- familyi={W\bibinitperiod},
- given={Jian},
- giveni={J\bibinitperiod}}}%
- {{hash=f4a4cbf770add19c206827116c68732e}{%
- family={Zhang},
- familyi={Z\bibinitperiod},
- given={Lei},
- giveni={L\bibinitperiod}}}%
- {{hash=6b995a03f55b8c0d7a4ed8e44daae0a5}{%
- family={Tang},
- familyi={T\bibinitperiod},
- given={Chaojing},
- giveni={C\bibinitperiod}}}%
- {{hash=ba23fbcd4b04b46c4588892f422fe72b}{%
- family={Kang},
- familyi={K\bibinitperiod},
- given={Hongyan},
- giveni={H\bibinitperiod}}}%
- }
- \list{organization}{1}{%
- {IEEE}%
- }
- \strng{namehash}{10c7b94477775db573510e04e477a77b}
- \strng{fullhash}{40a5ec0e4490a4063bf48a5924ef1c0f}
- \strng{bibnamehash}{40a5ec0e4490a4063bf48a5924ef1c0f}
- \strng{authorbibnamehash}{40a5ec0e4490a4063bf48a5924ef1c0f}
- \strng{authornamehash}{10c7b94477775db573510e04e477a77b}
- \strng{authorfullhash}{40a5ec0e4490a4063bf48a5924ef1c0f}
- \field{sortinit}{5}
- \field{sortinithash}{5dd416adbafacc8226114bc0202d5fdd}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{booktitle}{2017 11th IEEE International Conference on
Anti-counterfeiting, Security, and Identification (ASID)}
- \field{title}{An efficient method to enhance Bitcoin wallet security}
- \field{year}{2017}
- \field{pages}{26\bibrangedash 29}
- \range{pages}{4}
- \endentry
- \entry{millions_lost}{online}{}
- \name{author}{1}{}{%
- {{hash=3648296958ad2ea0461fac7a13e12981}{%
- family={Cuthbertson},
- familyi={C\bibinitperiod},
- given={Anthony},
- giveni={A\bibinitperiod}}}%
- }
- \list{organization}{1}{%
- {INDEPENDENT}%
- }
- \strng{namehash}{3648296958ad2ea0461fac7a13e12981}
- \strng{fullhash}{3648296958ad2ea0461fac7a13e12981}
- \strng{bibnamehash}{3648296958ad2ea0461fac7a13e12981}
- \strng{authorbibnamehash}{3648296958ad2ea0461fac7a13e12981}
- \strng{authornamehash}{3648296958ad2ea0461fac7a13e12981}
- \strng{authorfullhash}{3648296958ad2ea0461fac7a13e12981}
- \field{sortinit}{6}
- \field{sortinithash}{7851c86048328b027313775d8fbd2131}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{title}{Bitcoin: Millions of dollars of cryptocurrency 'lost'
after man dies with only password}
- \field{urlday}{7}
- \field{urlmonth}{3}
- \field{urlyear}{2020}
- \field{year}{2019}
- \field{urldateera}{ce}
- \verb{urlraw}
- \verb
https://www.independent.co.uk/life-style/gadgets-and-tech/news/bitcoin-exchange-quadrigacx-password-cryptocurrency-scam-a8763676.html
- \endverb
- \verb{url}
- \verb
https://www.independent.co.uk/life-style/gadgets-and-tech/news/bitcoin-exchange-quadrigacx-password-cryptocurrency-scam-a8763676.html
- \endverb
- \endentry
- \entry{bitcoin-keys}{online}{}
- \list{organization}{1}{%
- {Bitcoin}%
- }
- \field{sortinit}{7}
- \field{sortinithash}{f615fb9c6fba11c6f962fb3fd599810e}
- \field{labeltitlesource}{title}
- \field{title}{BIP 32 - Hierarchical Deterministic Wallets}
- \field{urlday}{6}
- \field{urlmonth}{6}
- \field{urlyear}{2020}
- \field{year}{2020}
- \field{urldateera}{ce}
- \verb{urlraw}
- \verb https://github.com/bitcoin/bips/blob/master/bip-0032/derivation.png
- \endverb
- \verb{url}
- \verb https://github.com/bitcoin/bips/blob/master/bip-0032/derivation.png
- \endverb
- \endentry
- \entry{bajikar2002}{article}{}
- \name{author}{1}{}{%
- {{hash=b5c45c4b8deb48651c65650f0409e671}{%
- family={Bajikar},
- familyi={B\bibinitperiod},
- given={Sundeep},
- giveni={S\bibinitperiod}}}%
- }
- \strng{namehash}{b5c45c4b8deb48651c65650f0409e671}
- \strng{fullhash}{b5c45c4b8deb48651c65650f0409e671}
- \strng{bibnamehash}{b5c45c4b8deb48651c65650f0409e671}
- \strng{authorbibnamehash}{b5c45c4b8deb48651c65650f0409e671}
- \strng{authornamehash}{b5c45c4b8deb48651c65650f0409e671}
- \strng{authorfullhash}{b5c45c4b8deb48651c65650f0409e671}
- \field{sortinit}{9}
- \field{sortinithash}{54047ffb55bdefa0694bbd554c1b11a0}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{journaltitle}{Mobile Platforms Group Intel Corporation}
- \field{title}{Trusted platform module (tpm) based security on notebook
pcs-white paper}
- \field{volume}{1}
- \field{year}{2002}
- \field{pages}{20}
- \range{pages}{1}
- \endentry
- \entry{vadhan2012}{article}{}
- \true{moreauthor}
- \true{morelabelname}
- \name{author}{1}{}{%
- {{hash=4a7848d2e829c08c64fd0693e3389940}{%
- family={Vadhan},
- familyi={V\bibinitperiod},
- given={Salil\bibnamedelima P},
- giveni={S\bibinitperiod\bibinitdelim P\bibinitperiod}}}%
- }
- \list{publisher}{1}{%
- {Now Publishers, Inc.}%
- }
- \strng{namehash}{abb7f98446293f740b141f01ff61554d}
- \strng{fullhash}{abb7f98446293f740b141f01ff61554d}
- \strng{bibnamehash}{abb7f98446293f740b141f01ff61554d}
- \strng{authorbibnamehash}{abb7f98446293f740b141f01ff61554d}
- \strng{authornamehash}{abb7f98446293f740b141f01ff61554d}
- \strng{authorfullhash}{abb7f98446293f740b141f01ff61554d}
- \field{sortinit}{1}
- \field{sortinithash}{50c6687d7fc80f50136d75228e3c59ba}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{journaltitle}{Foundations and Trends® in Theoretical Computer
Science}
- \field{number}{1--3}
- \field{title}{Pseudorandomness}
- \field{volume}{7}
- \field{year}{2012}
- \field{pages}{1\bibrangedash 336}
- \range{pages}{336}
- \endentry
- \entry{nielsen2002}{inproceedings}{}
- \name{author}{1}{}{%
- {{hash=6535189281ff6a1012638e384823f5cf}{%
- family={Nielsen},
- familyi={N\bibinitperiod},
- given={Jesper\bibnamedelima Buus},
- giveni={J\bibinitperiod\bibinitdelim B\bibinitperiod}}}%
- }
- \list{organization}{1}{%
- {Springer}%
- }
- \strng{namehash}{6535189281ff6a1012638e384823f5cf}
- \strng{fullhash}{6535189281ff6a1012638e384823f5cf}
- \strng{bibnamehash}{6535189281ff6a1012638e384823f5cf}
- \strng{authorbibnamehash}{6535189281ff6a1012638e384823f5cf}
- \strng{authornamehash}{6535189281ff6a1012638e384823f5cf}
- \strng{authorfullhash}{6535189281ff6a1012638e384823f5cf}
- \field{sortinit}{1}
- \field{sortinithash}{50c6687d7fc80f50136d75228e3c59ba}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{booktitle}{Annual International Cryptology Conference}
- \field{title}{A threshold pseudorandom function construction and its
applications}
- \field{year}{2002}
- \field{pages}{401\bibrangedash 416}
- \range{pages}{16}
- \endentry
- \entry{GGM1986}{article}{}
- \name{author}{3}{}{%
- {{hash=66aba379c7d3adb8af5b662a65c4c140}{%
- family={Goldreich},
- familyi={G\bibinitperiod},
- given={Oded},
- giveni={O\bibinitperiod}}}%
- {{hash=39e4a0690915f1d991133196a545b37b}{%
- family={Goldwasser},
- familyi={G\bibinitperiod},
- given={Shafi},
- giveni={S\bibinitperiod}}}%
- {{hash=fb54c363f1b0d126e883c84df49e4790}{%
- family={Micali},
- familyi={M\bibinitperiod},
- given={Silvio},
- giveni={S\bibinitperiod}}}%
- }
- \list{location}{1}{%
- {New York, NY, USA}%
- }
- \list{publisher}{1}{%
- {Association for Computing Machinery}%
- }
- \strng{namehash}{39e304099b960365cdb56b83f4c70df6}
- \strng{fullhash}{39e304099b960365cdb56b83f4c70df6}
- \strng{bibnamehash}{39e304099b960365cdb56b83f4c70df6}
- \strng{authorbibnamehash}{39e304099b960365cdb56b83f4c70df6}
- \strng{authornamehash}{39e304099b960365cdb56b83f4c70df6}
- \strng{authorfullhash}{39e304099b960365cdb56b83f4c70df6}
- \field{sortinit}{1}
- \field{sortinithash}{50c6687d7fc80f50136d75228e3c59ba}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{issn}{0004-5411}
- \field{journaltitle}{J. ACM}
- \field{month}{8}
- \field{number}{4}
- \field{title}{How to Construct Random Functions}
- \field{volume}{33}
- \field{year}{1986}
- \field{pages}{792\bibrangedash 807}
- \range{pages}{16}
- \verb{doi}
- \verb 10.1145/6490.6503
- \endverb
- \verb{urlraw}
- \verb https://doi.org/10.1145/6490.6503
- \endverb
- \verb{url}
- \verb https://doi.org/10.1145/6490.6503
- \endverb
- \endentry
- \entry{Preneel1999}{inbook}{}
- \name{author}{1}{}{%
- {{hash=0b9d4896fca22178c881b5236f351e05}{%
- family={Preneel},
- familyi={P\bibinitperiod},
- given={Bart},
- giveni={B\bibinitperiod}}}%
- }
- \name{editor}{1}{}{%
- {{hash=14f9bdb855aa40873ff3dce506ed6fff}{%
- family={Damg{å}rd},
- familyi={D\bibinitperiod},
- given={Ivan\bibnamedelima Bjerre},
- giveni={I\bibinitperiod\bibinitdelim B\bibinitperiod}}}%
- }
- \list{location}{1}{%
- {Berlin, Heidelberg}%
- }
- \list{publisher}{1}{%
- {Springer Berlin Heidelberg}%
- }
- \strng{namehash}{0b9d4896fca22178c881b5236f351e05}
- \strng{fullhash}{0b9d4896fca22178c881b5236f351e05}
- \strng{bibnamehash}{0b9d4896fca22178c881b5236f351e05}
- \strng{authorbibnamehash}{0b9d4896fca22178c881b5236f351e05}
- \strng{authornamehash}{0b9d4896fca22178c881b5236f351e05}
- \strng{authorfullhash}{0b9d4896fca22178c881b5236f351e05}
- \strng{editorbibnamehash}{14f9bdb855aa40873ff3dce506ed6fff}
- \strng{editornamehash}{14f9bdb855aa40873ff3dce506ed6fff}
- \strng{editorfullhash}{14f9bdb855aa40873ff3dce506ed6fff}
- \field{sortinit}{1}
- \field{sortinithash}{50c6687d7fc80f50136d75228e3c59ba}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{abstract}{This paper describes the state of the art for
cryptographic hash functions. Different definitions are compared, and the few
theoretical results on hash functions are discussed. A brief overview is
presented of the most important constructions, and some open problems are
presented.}
- \field{booktitle}{Lectures on Data Security: Modern Cryptology in Theory
and Practice}
- \field{isbn}{978-3-540-48969-6}
- \field{title}{The State of Cryptographic Hash Functions}
- \field{year}{1999}
- \field{pages}{158}
- \range{pages}{1}
- \verb{doi}
- \verb 10.1007/3-540-48969-X_8
- \endverb
- \verb{urlraw}
- \verb https://doi.org/10.1007/3-540-48969-X_8
- \endverb
- \verb{url}
- \verb https://doi.org/10.1007/3-540-48969-X_8
- \endverb
- \endentry
- \entry{SG2012}{article}{}
- \name{author}{2}{}{%
- {{hash=831a194fddb2f27c4e2c482b1f72f48a}{%
- family={Sobti},
- familyi={S\bibinitperiod},
- given={Rajeev},
- giveni={R\bibinitperiod}}}%
- {{hash=c244900d83a048c38628604327a28052}{%
- family={Geetha},
- familyi={G\bibinitperiod},
- given={G},
- giveni={G\bibinitperiod}}}%
- }
- \list{publisher}{1}{%
- {International Journal of Computer Science Issues (IJCSI)}%
- }
- \strng{namehash}{4d5e3f9d17e0c0b2294603b963e91c33}
- \strng{fullhash}{4d5e3f9d17e0c0b2294603b963e91c33}
- \strng{bibnamehash}{4d5e3f9d17e0c0b2294603b963e91c33}
- \strng{authorbibnamehash}{4d5e3f9d17e0c0b2294603b963e91c33}
- \strng{authornamehash}{4d5e3f9d17e0c0b2294603b963e91c33}
- \strng{authorfullhash}{4d5e3f9d17e0c0b2294603b963e91c33}
- \field{sortinit}{1}
- \field{sortinithash}{50c6687d7fc80f50136d75228e3c59ba}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{journaltitle}{International Journal of Computer Science Issues
(IJCSI)}
- \field{number}{2}
- \field{title}{Cryptographic hash functions: a review}
- \field{volume}{9}
- \field{year}{2012}
- \field{pages}{462}
- \range{pages}{1}
- \endentry
- \entry{RK2011}{article}{}
- \name{author}{2}{}{%
- {{hash=8f939579bcf2d180bae9f53387cab62b}{%
- family={Ramanujam},
- familyi={R\bibinitperiod},
- given={Sriram},
- giveni={S\bibinitperiod}}}%
- {{hash=81584ababc9dfe487baae50ab6f0ca8a}{%
- family={Karuppiah},
- familyi={K\bibinitperiod},
- given={Marimuthu},
- giveni={M\bibinitperiod}}}%
- }
- \strng{namehash}{79ea2c47cb704d13b6d9bcf7c199fc51}
- \strng{fullhash}{79ea2c47cb704d13b6d9bcf7c199fc51}
- \strng{bibnamehash}{79ea2c47cb704d13b6d9bcf7c199fc51}
- \strng{authorbibnamehash}{79ea2c47cb704d13b6d9bcf7c199fc51}
- \strng{authornamehash}{79ea2c47cb704d13b6d9bcf7c199fc51}
- \strng{authorfullhash}{79ea2c47cb704d13b6d9bcf7c199fc51}
- \field{sortinit}{1}
- \field{sortinithash}{50c6687d7fc80f50136d75228e3c59ba}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{journaltitle}{IJCSNS International Journal of Computer Science
and Network Security}
- \field{number}{1}
- \field{title}{Designing an algorithm with high Avalanche Effect}
- \field{volume}{11}
- \field{year}{2011}
- \field{pages}{106\bibrangedash 111}
- \range{pages}{6}
- \endentry
- \entry{GJW2011}{inproceedings}{}
- \name{author}{3}{}{%
- {{hash=74ca2f05d1125811a4211361255b1cf2}{%
- family={Gueron},
- familyi={G\bibinitperiod},
- given={Shay},
- giveni={S\bibinitperiod}}}%
- {{hash=38e00ab25a60509b785c20ef8caa89b9}{%
- family={Johnson},
- familyi={J\bibinitperiod},
- given={Simon},
- giveni={S\bibinitperiod}}}%
- {{hash=20a47eef2fa55e0486b02a0e2a0b8d0c}{%
- family={Walker},
- familyi={W\bibinitperiod},
- given={Jesse},
- giveni={J\bibinitperiod}}}%
- }
- \list{organization}{1}{%
- {IEEE}%
- }
- \strng{namehash}{4b253103893adba3aada17995ac73ec0}
- \strng{fullhash}{4b253103893adba3aada17995ac73ec0}
- \strng{bibnamehash}{4b253103893adba3aada17995ac73ec0}
- \strng{authorbibnamehash}{4b253103893adba3aada17995ac73ec0}
- \strng{authornamehash}{4b253103893adba3aada17995ac73ec0}
- \strng{authorfullhash}{4b253103893adba3aada17995ac73ec0}
- \field{sortinit}{1}
- \field{sortinithash}{50c6687d7fc80f50136d75228e3c59ba}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{booktitle}{2011 Eighth International Conference on Information
Technology: New Generations}
- \field{title}{SHA-512/256}
- \field{year}{2011}
- \field{pages}{354\bibrangedash 358}
- \range{pages}{5}
- \endentry
- \entry{BCK1996}{article}{}
- \name{author}{3}{}{%
- {{hash=06e2bb2f83d8b669b46db64431509301}{%
- family={Bellare},
- familyi={B\bibinitperiod},
- given={Mihir},
- giveni={M\bibinitperiod}}}%
- {{hash=7faf0f3900af6c70795ea089d283f02e}{%
- family={Canetti},
- familyi={C\bibinitperiod},
- given={Ran},
- giveni={R\bibinitperiod}}}%
- {{hash=088445b3855bedf4bcc9d25651eb98b2}{%
- family={Krawczyk},
- familyi={K\bibinitperiod},
- given={Hugo},
- giveni={H\bibinitperiod}}}%
- }
- \strng{namehash}{2527ef0685da3bdb01959cd066adc238}
- \strng{fullhash}{2527ef0685da3bdb01959cd066adc238}
- \strng{bibnamehash}{2527ef0685da3bdb01959cd066adc238}
- \strng{authorbibnamehash}{2527ef0685da3bdb01959cd066adc238}
- \strng{authornamehash}{2527ef0685da3bdb01959cd066adc238}
- \strng{authorfullhash}{2527ef0685da3bdb01959cd066adc238}
- \field{sortinit}{2}
- \field{sortinithash}{ed39bb39cf854d5250e95b1c1f94f4ed}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{journaltitle}{RSA Laboratories’ CryptoBytes}
- \field{number}{1}
- \field{title}{Message authentication using hash functions: The HMAC
construction}
- \field{volume}{2}
- \field{year}{1996}
- \field{pages}{12\bibrangedash 15}
- \range{pages}{4}
- \endentry
- \entry{krawczyk2010}{inproceedings}{}
- \name{author}{1}{}{%
- {{hash=088445b3855bedf4bcc9d25651eb98b2}{%
- family={Krawczyk},
- familyi={K\bibinitperiod},
- given={Hugo},
- giveni={H\bibinitperiod}}}%
- }
- \list{organization}{1}{%
- {Springer}%
- }
- \strng{namehash}{088445b3855bedf4bcc9d25651eb98b2}
- \strng{fullhash}{088445b3855bedf4bcc9d25651eb98b2}
- \strng{bibnamehash}{088445b3855bedf4bcc9d25651eb98b2}
- \strng{authorbibnamehash}{088445b3855bedf4bcc9d25651eb98b2}
- \strng{authornamehash}{088445b3855bedf4bcc9d25651eb98b2}
- \strng{authorfullhash}{088445b3855bedf4bcc9d25651eb98b2}
- \field{sortinit}{2}
- \field{sortinithash}{ed39bb39cf854d5250e95b1c1f94f4ed}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{booktitle}{Annual Cryptology Conference}
- \field{title}{Cryptographic extraction and key derivation: The HKDF
scheme}
- \field{year}{2010}
- \field{pages}{631\bibrangedash 648}
- \range{pages}{18}
- \endentry
- \entry{trimberger2012}{book}{}
- \name{author}{1}{}{%
- {{hash=0afd18d7b25d23c61db1fe942ec1c236}{%
- family={Trimberger},
- familyi={T\bibinitperiod},
- given={Stephen\bibnamedelima M},
- giveni={S\bibinitperiod\bibinitdelim M\bibinitperiod}}}%
- }
- \list{publisher}{1}{%
- {Springer Science \& Business Media}%
- }
- \strng{namehash}{0afd18d7b25d23c61db1fe942ec1c236}
- \strng{fullhash}{0afd18d7b25d23c61db1fe942ec1c236}
- \strng{bibnamehash}{0afd18d7b25d23c61db1fe942ec1c236}
- \strng{authorbibnamehash}{0afd18d7b25d23c61db1fe942ec1c236}
- \strng{authornamehash}{0afd18d7b25d23c61db1fe942ec1c236}
- \strng{authorfullhash}{0afd18d7b25d23c61db1fe942ec1c236}
- \field{sortinit}{2}
- \field{sortinithash}{ed39bb39cf854d5250e95b1c1f94f4ed}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{title}{Field-programmable gate array technology}
- \field{year}{2012}
- \endentry
- \entry{madurawe2006}{misc}{}
- \name{author}{1}{}{%
- {{hash=093f14ec763e8df6227fd18ac8958011}{%
- family={Madurawe},
- familyi={M\bibinitperiod},
- given={Raminda\bibnamedelima Udaya},
- giveni={R\bibinitperiod\bibinitdelim U\bibinitperiod}}}%
- }
- \list{publisher}{1}{%
- {Google Patents}%
- }
- \strng{namehash}{093f14ec763e8df6227fd18ac8958011}
- \strng{fullhash}{093f14ec763e8df6227fd18ac8958011}
- \strng{bibnamehash}{093f14ec763e8df6227fd18ac8958011}
- \strng{authorbibnamehash}{093f14ec763e8df6227fd18ac8958011}
- \strng{authornamehash}{093f14ec763e8df6227fd18ac8958011}
- \strng{authorfullhash}{093f14ec763e8df6227fd18ac8958011}
- \field{sortinit}{2}
- \field{sortinithash}{ed39bb39cf854d5250e95b1c1f94f4ed}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{month}{6}
- \field{note}{US Patent 7,064,579}
- \field{title}{Alterable application specific integrated circuit (ASIC)}
- \field{year}{2006}
- \endentry
- \entry{BDK2016}{inproceedings}{}
- \name{author}{3}{}{%
- {{hash=6b9702c0a225b2966f2e07631bcfe935}{%
- family={Biryukov},
- familyi={B\bibinitperiod},
- given={Alex},
- giveni={A\bibinitperiod}}}%
- {{hash=bf937d804c107f19fafa536592af6563}{%
- family={Dinu},
- familyi={D\bibinitperiod},
- given={Daniel},
- giveni={D\bibinitperiod}}}%
- {{hash=d38e18b5ec4018e5f12aab4287c4a08f}{%
- family={Khovratovich},
- familyi={K\bibinitperiod},
- given={Dmitry},
- giveni={D\bibinitperiod}}}%
- }
- \list{organization}{1}{%
- {IEEE}%
- }
- \strng{namehash}{037d5c3d4e3ef2dcef34dc59a05beed9}
- \strng{fullhash}{037d5c3d4e3ef2dcef34dc59a05beed9}
- \strng{bibnamehash}{037d5c3d4e3ef2dcef34dc59a05beed9}
- \strng{authorbibnamehash}{037d5c3d4e3ef2dcef34dc59a05beed9}
- \strng{authornamehash}{037d5c3d4e3ef2dcef34dc59a05beed9}
- \strng{authorfullhash}{037d5c3d4e3ef2dcef34dc59a05beed9}
- \field{sortinit}{2}
- \field{sortinithash}{ed39bb39cf854d5250e95b1c1f94f4ed}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{booktitle}{2016 IEEE European Symposium on Security and Privacy
(EuroS\&P)}
- \field{title}{Argon2: new generation of memory-hard functions for
password hashing and other applications}
- \field{year}{2016}
- \field{pages}{292\bibrangedash 302}
- \range{pages}{11}
- \endentry
- \entry{stamp2003}{article}{}
- \name{author}{1}{}{%
- {{hash=799c6648cb97b6ffb4e9da11a6e277ac}{%
- family={Stamp},
- familyi={S\bibinitperiod},
- given={Mark},
- giveni={M\bibinitperiod}}}%
- }
- \strng{namehash}{799c6648cb97b6ffb4e9da11a6e277ac}
- \strng{fullhash}{799c6648cb97b6ffb4e9da11a6e277ac}
- \strng{bibnamehash}{799c6648cb97b6ffb4e9da11a6e277ac}
- \strng{authorbibnamehash}{799c6648cb97b6ffb4e9da11a6e277ac}
- \strng{authornamehash}{799c6648cb97b6ffb4e9da11a6e277ac}
- \strng{authorfullhash}{799c6648cb97b6ffb4e9da11a6e277ac}
- \field{sortinit}{2}
- \field{sortinithash}{ed39bb39cf854d5250e95b1c1f94f4ed}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{journaltitle}{San Jose State University, Department of Computer
Science}
- \field{title}{Once upon a time-memory tradeoff}
- \field{year}{2003}
- \endentry
- \entry{shamir_sharing}{article}{}
- \name{author}{1}{}{%
- {{hash=71b77dd8ab33fe646ef25cded49e9881}{%
- family={Shamir},
- familyi={S\bibinitperiod},
- given={Adi},
- giveni={A\bibinitperiod}}}%
- }
- \list{publisher}{1}{%
- {ACm New York, NY, USA}%
- }
- \strng{namehash}{71b77dd8ab33fe646ef25cded49e9881}
- \strng{fullhash}{71b77dd8ab33fe646ef25cded49e9881}
- \strng{bibnamehash}{71b77dd8ab33fe646ef25cded49e9881}
- \strng{authorbibnamehash}{71b77dd8ab33fe646ef25cded49e9881}
- \strng{authornamehash}{71b77dd8ab33fe646ef25cded49e9881}
- \strng{authorfullhash}{71b77dd8ab33fe646ef25cded49e9881}
- \field{sortinit}{2}
- \field{sortinithash}{ed39bb39cf854d5250e95b1c1f94f4ed}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{journaltitle}{Communications of the ACM}
- \field{number}{11}
- \field{title}{How to share a secret}
- \field{volume}{22}
- \field{year}{1979}
- \field{pages}{612\bibrangedash 613}
- \range{pages}{2}
- \endentry
- \entry{pedersen_sharing_0}{inproceedings}{}
- \name{author}{1}{}{%
- {{hash=ee278eaf10727ef21f15ba59cdfcb51b}{%
- family={Pedersen},
- familyi={P\bibinitperiod},
- given={Torben\bibnamedelima Pryds},
- giveni={T\bibinitperiod\bibinitdelim P\bibinitperiod}}}%
- }
- \list{organization}{1}{%
- {Springer}%
- }
- \strng{namehash}{ee278eaf10727ef21f15ba59cdfcb51b}
- \strng{fullhash}{ee278eaf10727ef21f15ba59cdfcb51b}
- \strng{bibnamehash}{ee278eaf10727ef21f15ba59cdfcb51b}
- \strng{authorbibnamehash}{ee278eaf10727ef21f15ba59cdfcb51b}
- \strng{authornamehash}{ee278eaf10727ef21f15ba59cdfcb51b}
- \strng{authorfullhash}{ee278eaf10727ef21f15ba59cdfcb51b}
- \field{extraname}{1}
- \field{sortinit}{2}
- \field{sortinithash}{ed39bb39cf854d5250e95b1c1f94f4ed}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{booktitle}{Annual international cryptology conference}
- \field{chapter}{0}
- \field{title}{Non-interactive and information-theoretic secure
verifiable secret sharing}
- \field{year}{1991}
- \field{pages}{129\bibrangedash 140}
- \range{pages}{12}
- \endentry
- \entry{feldman_sharing}{inproceedings}{}
- \name{author}{1}{}{%
- {{hash=618e5892290641345f357d52e5ef3c12}{%
- family={Feldman},
- familyi={F\bibinitperiod},
- given={Paul},
- giveni={P\bibinitperiod}}}%
- }
- \list{organization}{1}{%
- {IEEE}%
- }
- \strng{namehash}{618e5892290641345f357d52e5ef3c12}
- \strng{fullhash}{618e5892290641345f357d52e5ef3c12}
- \strng{bibnamehash}{618e5892290641345f357d52e5ef3c12}
- \strng{authorbibnamehash}{618e5892290641345f357d52e5ef3c12}
- \strng{authornamehash}{618e5892290641345f357d52e5ef3c12}
- \strng{authorfullhash}{618e5892290641345f357d52e5ef3c12}
- \field{sortinit}{3}
- \field{sortinithash}{a37a8ef248a93c322189792c34fc68c9}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{booktitle}{28th Annual Symposium on Foundations of Computer
Science (sfcs 1987)}
- \field{title}{A practical scheme for non-interactive verifiable secret
sharing}
- \field{year}{1987}
- \field{pages}{427\bibrangedash 438}
- \range{pages}{12}
- \endentry
- \entry{pedersen_sharing_5.2}{inproceedings}{}
- \name{author}{1}{}{%
- {{hash=ee278eaf10727ef21f15ba59cdfcb51b}{%
- family={Pedersen},
- familyi={P\bibinitperiod},
- given={Torben\bibnamedelima Pryds},
- giveni={T\bibinitperiod\bibinitdelim P\bibinitperiod}}}%
- }
- \list{organization}{1}{%
- {Springer}%
- }
- \strng{namehash}{ee278eaf10727ef21f15ba59cdfcb51b}
- \strng{fullhash}{ee278eaf10727ef21f15ba59cdfcb51b}
- \strng{bibnamehash}{ee278eaf10727ef21f15ba59cdfcb51b}
- \strng{authorbibnamehash}{ee278eaf10727ef21f15ba59cdfcb51b}
- \strng{authornamehash}{ee278eaf10727ef21f15ba59cdfcb51b}
- \strng{authorfullhash}{ee278eaf10727ef21f15ba59cdfcb51b}
- \field{extraname}{2}
- \field{sortinit}{3}
- \field{sortinithash}{a37a8ef248a93c322189792c34fc68c9}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{booktitle}{Annual international cryptology conference}
- \field{chapter}{5.2}
- \field{title}{Non-interactive and information-theoretic secure
verifiable secret sharing}
- \field{year}{1991}
- \field{pages}{129\bibrangedash 140}
- \range{pages}{12}
- \endentry
- \entry{multifactor_authentication}{article}{}
- \name{author}{6}{}{%
- {{hash=349f11e1663912dcb58a979614214591}{%
- family={Ometov},
- familyi={O\bibinitperiod},
- given={Aleksandr},
- giveni={A\bibinitperiod}}}%
- {{hash=2210a791565f0e229e45ee4adddbe39a}{%
- family={Bezzateev},
- familyi={B\bibinitperiod},
- given={Sergey},
- giveni={S\bibinitperiod}}}%
- {{hash=515fcf6ab2738bfda2f35fc8a7aabbad}{%
- family={Makitalo},
- familyi={M\bibinitperiod},
- given={Niko},
- giveni={N\bibinitperiod}}}%
- {{hash=29e0c47c24b13223f7986b9dd3f37aeb}{%
- family={Andreev},
- familyi={A\bibinitperiod},
- given={Sergey},
- giveni={S\bibinitperiod}}}%
- {{hash=5d7740b6e2ec0fb41f72f451e980670b}{%
- family={Mikkonen},
- familyi={M\bibinitperiod},
- given={Tommi},
- giveni={T\bibinitperiod}}}%
- {{hash=1b1c95790f3403d472ac8a4befa0eb49}{%
- family={Koucheryavy},
- familyi={K\bibinitperiod},
- given={Yevgeni},
- giveni={Y\bibinitperiod}}}%
- }
- \list{publisher}{1}{%
- {Multidisciplinary Digital Publishing Institute}%
- }
- \strng{namehash}{45cd1a76e0cdd8946f91bead3b664768}
- \strng{fullhash}{c1db872bc8ef36ee51e0526f23769166}
- \strng{bibnamehash}{c1db872bc8ef36ee51e0526f23769166}
- \strng{authorbibnamehash}{c1db872bc8ef36ee51e0526f23769166}
- \strng{authornamehash}{45cd1a76e0cdd8946f91bead3b664768}
- \strng{authorfullhash}{c1db872bc8ef36ee51e0526f23769166}
- \field{sortinit}{3}
- \field{sortinithash}{a37a8ef248a93c322189792c34fc68c9}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{journaltitle}{Cryptography}
- \field{number}{1}
- \field{title}{Multi-factor authentication: A survey}
- \field{volume}{2}
- \field{year}{2018}
- \field{pages}{1}
- \range{pages}{1}
- \endentry
- \entry{authentication_methods_review}{article}{}
- \name{author}{4}{}{%
- {{hash=7320eb44b90aead6870ac2fab7d71076}{%
- family={Syed\bibnamedelima Idrus},
- familyi={S\bibinitperiod\bibinitdelim I\bibinitperiod},
- given={Syed\bibnamedelima Zulkarnain},
- giveni={S\bibinitperiod\bibinitdelim Z\bibinitperiod}}}%
- {{hash=a09a932af5f7cd55229eaae3115944ad}{%
- family={Cherrier},
- familyi={C\bibinitperiod},
- given={Estelle},
- giveni={E\bibinitperiod}}}%
- {{hash=b91ea03eff7b52d366d5afa7847a6284}{%
- family={Rosenberger},
- familyi={R\bibinitperiod},
- given={Christophe},
- giveni={C\bibinitperiod}}}%
- {{hash=315979ea9ce5ac9865a4cf0dae673cd0}{%
- family={Schwartzmann},
- familyi={S\bibinitperiod},
- given={Jean-Jacques},
- giveni={J\bibinithyphendelim J\bibinitperiod}}}%
- }
- \strng{namehash}{ce7e837cc1dbca8dddef9896de46176c}
- \strng{fullhash}{c7f2c123e1ed3b1e1ad986ca25e522b3}
- \strng{bibnamehash}{c7f2c123e1ed3b1e1ad986ca25e522b3}
- \strng{authorbibnamehash}{c7f2c123e1ed3b1e1ad986ca25e522b3}
- \strng{authornamehash}{ce7e837cc1dbca8dddef9896de46176c}
- \strng{authorfullhash}{c7f2c123e1ed3b1e1ad986ca25e522b3}
- \field{sortinit}{3}
- \field{sortinithash}{a37a8ef248a93c322189792c34fc68c9}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{journaltitle}{Australian Journal of Basic and Applied Sciences}
- \field{number}{5}
- \field{title}{A Review on Authentication Methods}
- \field{volume}{7}
- \field{year}{2013}
- \field{pages}{95\bibrangedash 107}
- \range{pages}{13}
- \verb{urlraw}
- \verb https://hal.archives-ouvertes.fr/hal-00912435
- \endverb
- \verb{url}
- \verb https://hal.archives-ouvertes.fr/hal-00912435
- \endverb
- \endentry
- \entry{just2004}{article}{}
- \name{author}{1}{}{%
- {{hash=daa648a2c605762c09bfaab94d0f2168}{%
- family={Just},
- familyi={J\bibinitperiod},
- given={Mike},
- giveni={M\bibinitperiod}}}%
- }
- \list{publisher}{1}{%
- {IEEE}%
- }
- \strng{namehash}{daa648a2c605762c09bfaab94d0f2168}
- \strng{fullhash}{daa648a2c605762c09bfaab94d0f2168}
- \strng{bibnamehash}{daa648a2c605762c09bfaab94d0f2168}
- \strng{authorbibnamehash}{daa648a2c605762c09bfaab94d0f2168}
- \strng{authornamehash}{daa648a2c605762c09bfaab94d0f2168}
- \strng{authorfullhash}{daa648a2c605762c09bfaab94d0f2168}
- \field{sortinit}{3}
- \field{sortinithash}{a37a8ef248a93c322189792c34fc68c9}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{journaltitle}{IEEE Security \& Privacy}
- \field{number}{5}
- \field{title}{Designing and evaluating challenge-question systems}
- \field{volume}{2}
- \field{year}{2004}
- \field{pages}{32\bibrangedash 39}
- \range{pages}{8}
- \endentry
- \entry{MBSS2013}{inproceedings}{}
- \name{author}{4}{}{%
- {{hash=0c05d559d041112c87e63b05c5a7262b}{%
- family={Mulliner},
- familyi={M\bibinitperiod},
- given={Collin},
- giveni={C\bibinitperiod}}}%
- {{hash=4e0292e00a4787b4db10b2dff39f4a1f}{%
- family={Borgaonkar},
- familyi={B\bibinitperiod},
- given={Ravishankar},
- giveni={R\bibinitperiod}}}%
- {{hash=1cda40a05e3c8aa2f5c29f19988ca758}{%
- family={Stewin},
- familyi={S\bibinitperiod},
- given={Patrick},
- giveni={P\bibinitperiod}}}%
- {{hash=ed83c5ceed1edd0dbc3cc610adf79477}{%
- family={Seifert},
- familyi={S\bibinitperiod},
- given={Jean-Pierre},
- giveni={J\bibinithyphendelim P\bibinitperiod}}}%
- }
- \list{organization}{1}{%
- {Springer}%
- }
- \strng{namehash}{adce78e3f1e04476f35b2b5fcb6c6262}
- \strng{fullhash}{85e8ef541ae3f71805b7382856006c85}
- \strng{bibnamehash}{85e8ef541ae3f71805b7382856006c85}
- \strng{authorbibnamehash}{85e8ef541ae3f71805b7382856006c85}
- \strng{authornamehash}{adce78e3f1e04476f35b2b5fcb6c6262}
- \strng{authorfullhash}{85e8ef541ae3f71805b7382856006c85}
- \field{sortinit}{3}
- \field{sortinithash}{a37a8ef248a93c322189792c34fc68c9}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{booktitle}{International Conference on Detection of Intrusions
and Malware, and Vulnerability Assessment}
- \field{title}{SMS-based one-time passwords: attacks and defense}
- \field{year}{2013}
- \field{pages}{150\bibrangedash 159}
- \range{pages}{10}
- \endentry
- \entry{rieck_detection}{book}{}
- \name{author}{3}{}{%
- {{hash=47449209bde605e33642aeb4dcc23bf2}{%
- family={Rieck},
- familyi={R\bibinitperiod},
- given={Konrad},
- giveni={K\bibinitperiod}}}%
- {{hash=1cda40a05e3c8aa2f5c29f19988ca758}{%
- family={Stewin},
- familyi={S\bibinitperiod},
- given={Patrick},
- giveni={P\bibinitperiod}}}%
- {{hash=ed83c5ceed1edd0dbc3cc610adf79477}{%
- family={Seifert},
- familyi={S\bibinitperiod},
- given={Jean-Pierre},
- giveni={J\bibinithyphendelim P\bibinitperiod}}}%
- }
- \list{publisher}{1}{%
- {Springer}%
- }
- \strng{namehash}{5646590031d49807385b96f9f6caae4a}
- \strng{fullhash}{5646590031d49807385b96f9f6caae4a}
- \strng{bibnamehash}{5646590031d49807385b96f9f6caae4a}
- \strng{authorbibnamehash}{5646590031d49807385b96f9f6caae4a}
- \strng{authornamehash}{5646590031d49807385b96f9f6caae4a}
- \strng{authorfullhash}{5646590031d49807385b96f9f6caae4a}
- \field{sortinit}{3}
- \field{sortinithash}{a37a8ef248a93c322189792c34fc68c9}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{title}{Detection of Intrusions and Malware, and Vulnerability
Assessment: 10th International Conference, DIMVA 2013, Berlin, Germany, July
18-19, 2013. Proceedings}
- \field{volume}{7967}
- \field{year}{2013}
- \endentry
- \entry{emailauthowasp}{online}{}
- \list{organization}{1}{%
- {OWASP Foundation}%
- }
- \field{sortinit}{3}
- \field{sortinithash}{a37a8ef248a93c322189792c34fc68c9}
- \field{labeltitlesource}{title}
- \field{title}{Forgot Password Cheat Sheet}
- \field{urlday}{5}
- \field{urlmonth}{6}
- \field{urlyear}{2020}
- \field{year}{2020}
- \field{urldateera}{ce}
- \verb{urlraw}
- \verb
https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html
- \endverb
- \verb{url}
- \verb
https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html
- \endverb
- \endentry
- \entry{pohlmann2017}{article}{}
- \name{author}{4}{}{%
- {{hash=613966f471ac9240f4bfce66e6e27b3e}{%
- family={Pohlmann},
- familyi={P\bibinitperiod},
- given={Norbert},
- giveni={N\bibinitperiod}}}%
- {{hash=6462a03ff4a69f0c01462ca9dfd9c2ac}{%
- family={Frintrop},
- familyi={F\bibinitperiod},
- given={Jan-Hendrik},
- giveni={J\bibinithyphendelim H\bibinitperiod}}}%
- {{hash=247317f34ce75f08f273ab47d30a4e91}{%
- family={Widdermann},
- familyi={W\bibinitperiod},
- given={Rick},
- giveni={R\bibinitperiod}}}%
- {{hash=197d288c2557c4675696cefb75461cf0}{%
- family={Ziegler},
- familyi={Z\bibinitperiod},
- given={Tim},
- giveni={T\bibinitperiod}}}%
- }
- \strng{namehash}{46fedf156ec86b72f1439a7e282b9fee}
- \strng{fullhash}{7c1027a04280b6542245beeb85db1408}
- \strng{bibnamehash}{7c1027a04280b6542245beeb85db1408}
- \strng{authorbibnamehash}{7c1027a04280b6542245beeb85db1408}
- \strng{authornamehash}{46fedf156ec86b72f1439a7e282b9fee}
- \strng{authorfullhash}{7c1027a04280b6542245beeb85db1408}
- \field{sortinit}{3}
- \field{sortinithash}{a37a8ef248a93c322189792c34fc68c9}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{title}{Wenn der Softbot menschliche Identit{ä}t best{ä}tigt.
Videoident-Verfahren II: Die Technik}
- \field{year}{2017}
- \endentry
- \entry{biometric_auth}{article}{}
- \name{author}{2}{}{%
- {{hash=019f89587e0c1e896a94bec0898d3964}{%
- family={Pagnin},
- familyi={P\bibinitperiod},
- given={Elena},
- giveni={E\bibinitperiod}}}%
- {{hash=3a3c8efa3b514b0608c70f90d96e7fec}{%
- family={Mitrokotsa},
- familyi={M\bibinitperiod},
- given={Aikaterini},
- giveni={A\bibinitperiod}}}%
- }
- \list{publisher}{1}{%
- {Hindawi}%
- }
- \strng{namehash}{db53816ca2458e8344846c9aa5b3bce3}
- \strng{fullhash}{db53816ca2458e8344846c9aa5b3bce3}
- \strng{bibnamehash}{db53816ca2458e8344846c9aa5b3bce3}
- \strng{authorbibnamehash}{db53816ca2458e8344846c9aa5b3bce3}
- \strng{authornamehash}{db53816ca2458e8344846c9aa5b3bce3}
- \strng{authorfullhash}{db53816ca2458e8344846c9aa5b3bce3}
- \field{sortinit}{4}
- \field{sortinithash}{e071e0bcb44634fab398d68ad04e69f4}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{journaltitle}{Security and Communication Networks}
- \field{title}{Privacy-preserving biometric authentication: challenges
and directions}
- \field{volume}{2017}
- \field{year}{2017}
- \endentry
- \entry{ccc_merkel}{online}{}
- \name{author}{1}{}{%
- {{hash=b7a2e18f77259e34d5b676fd04412bb3}{%
- family={Krempl},
- familyi={K\bibinitperiod},
- given={Stefan},
- giveni={S\bibinitperiod}}}%
- }
- \list{organization}{1}{%
- {heise online}%
- }
- \strng{namehash}{b7a2e18f77259e34d5b676fd04412bb3}
- \strng{fullhash}{b7a2e18f77259e34d5b676fd04412bb3}
- \strng{bibnamehash}{b7a2e18f77259e34d5b676fd04412bb3}
- \strng{authorbibnamehash}{b7a2e18f77259e34d5b676fd04412bb3}
- \strng{authornamehash}{b7a2e18f77259e34d5b676fd04412bb3}
- \strng{authorfullhash}{b7a2e18f77259e34d5b676fd04412bb3}
- \field{sortinit}{4}
- \field{sortinithash}{e071e0bcb44634fab398d68ad04e69f4}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{title}{CCC-Tüftler hackt Merkels Iris und von der Leyens
Fingerabdruck}
- \field{urlday}{7}
- \field{urlmonth}{3}
- \field{urlyear}{2020}
- \field{year}{2014}
- \field{urldateera}{ce}
- \verb{urlraw}
- \verb
https://www.heise.de/security/meldung/31C3-CCC-Tueftler-hackt-Merkels-Iris-und-von-der-Leyens-Fingerabdruck-2506929.html
- \endverb
- \verb{url}
- \verb
https://www.heise.de/security/meldung/31C3-CCC-Tueftler-hackt-Merkels-Iris-und-von-der-Leyens-Fingerabdruck-2506929.html
- \endverb
- \endentry
- \entry{coinbase}{online}{}
- \list{organization}{1}{%
- {Coinbase}%
- }
- \field{sortinit}{4}
- \field{sortinithash}{e071e0bcb44634fab398d68ad04e69f4}
- \field{labeltitlesource}{title}
- \field{title}{Backup your encrypted private keys on Google Drive and
iCloud with Coinbase Wallet}
- \field{urlday}{6}
- \field{urlmonth}{6}
- \field{urlyear}{2020}
- \field{year}{2020}
- \field{urldateera}{ce}
- \verb{urlraw}
- \verb
https://blog.coinbase.com/backup-your-private-keys-on-google-drive-and-icloud-with-coinbase-wallet-3c3f3fdc86dc
- \endverb
- \verb{url}
- \verb
https://blog.coinbase.com/backup-your-private-keys-on-google-drive-and-icloud-with-coinbase-wallet-3c3f3fdc86dc
- \endverb
- \endentry
- \entry{midata}{book}{}
- \name{author}{2}{}{%
- {{hash=b41b32ea32d73cd352e35f15b7f0b82e}{%
- family={Parag\bibnamedelima Chatterjee},
- familyi={P\bibinitperiod\bibinitdelim C\bibinitperiod},
- given={Emmanuel\bibnamedelima Benoist},
- giveni={E\bibinitperiod\bibinitdelim B\bibinitperiod}}}%
- {{hash=8d46139dbcfb8d6e298d3be4bb2ad78b}{%
- family={Nath},
- familyi={N\bibinitperiod},
- given={Asoke},
- giveni={A\bibinitperiod}}}%
- }
- \list{publisher}{1}{%
- {IGI Global}%
- }
- \strng{namehash}{e366017de179e8187fd5bb233ad210d8}
- \strng{fullhash}{e366017de179e8187fd5bb233ad210d8}
- \strng{bibnamehash}{e366017de179e8187fd5bb233ad210d8}
- \strng{authorbibnamehash}{e366017de179e8187fd5bb233ad210d8}
- \strng{authornamehash}{e366017de179e8187fd5bb233ad210d8}
- \strng{authorfullhash}{e366017de179e8187fd5bb233ad210d8}
- \field{sortinit}{4}
- \field{sortinithash}{e071e0bcb44634fab398d68ad04e69f4}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{title}{Applied Approach to Privacy and Security for the Internet
of Things}
- \field{year}{in print}
- \endentry
- \entry{marlinspike2011}{article}{}
- \name{author}{1}{}{%
- {{hash=9dfd0bf532dd1b08969afefcdd7188b5}{%
- family={Marlinspike},
- familyi={M\bibinitperiod},
- given={Moxie},
- giveni={M\bibinitperiod}}}%
- }
- \strng{namehash}{9dfd0bf532dd1b08969afefcdd7188b5}
- \strng{fullhash}{9dfd0bf532dd1b08969afefcdd7188b5}
- \strng{bibnamehash}{9dfd0bf532dd1b08969afefcdd7188b5}
- \strng{authorbibnamehash}{9dfd0bf532dd1b08969afefcdd7188b5}
- \strng{authornamehash}{9dfd0bf532dd1b08969afefcdd7188b5}
- \strng{authorfullhash}{9dfd0bf532dd1b08969afefcdd7188b5}
- \field{sortinit}{4}
- \field{sortinithash}{e071e0bcb44634fab398d68ad04e69f4}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{journaltitle}{Black Hat USA}
- \field{title}{SSL and the future of authenticity}
- \field{volume}{6}
- \field{year}{2011}
- \endentry
- \entry{josefsson2017}{inproceedings}{}
- \name{author}{2}{}{%
- {{hash=97ec76c57a8640354d28158df00f4d85}{%
- family={Josefsson},
- familyi={J\bibinitperiod},
- given={Simon},
- giveni={S\bibinitperiod}}}%
- {{hash=80783b1a7860da0eda4a2ca3f8434f66}{%
- family={Liusvaara},
- familyi={L\bibinitperiod},
- given={Ilari},
- giveni={I\bibinitperiod}}}%
- }
- \strng{namehash}{b3b08047d44ad47ea9a90d61cc647064}
- \strng{fullhash}{b3b08047d44ad47ea9a90d61cc647064}
- \strng{bibnamehash}{b3b08047d44ad47ea9a90d61cc647064}
- \strng{authorbibnamehash}{b3b08047d44ad47ea9a90d61cc647064}
- \strng{authornamehash}{b3b08047d44ad47ea9a90d61cc647064}
- \strng{authorfullhash}{b3b08047d44ad47ea9a90d61cc647064}
- \field{sortinit}{4}
- \field{sortinithash}{e071e0bcb44634fab398d68ad04e69f4}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{booktitle}{Internet Research Task Force, Crypto Forum Research
Group, RFC}
- \field{title}{Edwards-curve digital signature algorithm (EdDSA)}
- \field{volume}{8032}
- \field{year}{2017}
- \endentry
- \entry{heron2009}{article}{}
- \name{author}{1}{}{%
- {{hash=f2ca7c0188bc149bef92a85d32759b7b}{%
- family={Heron},
- familyi={H\bibinitperiod},
- given={Simon},
- giveni={S\bibinitperiod}}}%
- }
- \list{publisher}{1}{%
- {Elsevier}%
- }
- \strng{namehash}{f2ca7c0188bc149bef92a85d32759b7b}
- \strng{fullhash}{f2ca7c0188bc149bef92a85d32759b7b}
- \strng{bibnamehash}{f2ca7c0188bc149bef92a85d32759b7b}
- \strng{authorbibnamehash}{f2ca7c0188bc149bef92a85d32759b7b}
- \strng{authornamehash}{f2ca7c0188bc149bef92a85d32759b7b}
- \strng{authorfullhash}{f2ca7c0188bc149bef92a85d32759b7b}
- \field{sortinit}{4}
- \field{sortinithash}{e071e0bcb44634fab398d68ad04e69f4}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{journaltitle}{Network Security}
- \field{number}{12}
- \field{title}{Advanced encryption standard (AES)}
- \field{volume}{2009}
- \field{year}{2009}
- \field{pages}{8\bibrangedash 12}
- \range{pages}{5}
- \endentry
- \entry{gnu_taler}{online}{}
- \list{organization}{1}{%
- {Taler Systems SA}%
- }
- \field{sortinit}{5}
- \field{sortinithash}{5dd416adbafacc8226114bc0202d5fdd}
- \field{labeltitlesource}{title}
- \field{title}{GNU Taler: Features}
- \field{urlday}{2}
- \field{urlmonth}{6}
- \field{urlyear}{2020}
- \field{year}{2020}
- \field{urldateera}{ce}
- \verb{urlraw}
- \verb https://taler.net/en/features.html
- \endverb
- \verb{url}
- \verb https://taler.net/en/features.html
- \endverb
- \endentry
- \entry{postgresql}{online}{}
- \list{organization}{1}{%
- {The PostgreSQL Global Development Group}%
- }
- \field{sortinit}{5}
- \field{sortinithash}{5dd416adbafacc8226114bc0202d5fdd}
- \field{labeltitlesource}{title}
- \field{title}{PostgreSQL: The World's Most Advanced Open Source
Relational Database}
- \field{urlday}{2}
- \field{urlmonth}{6}
- \field{urlyear}{2020}
- \field{year}{2020}
- \field{urldateera}{ce}
- \verb{urlraw}
- \verb https://www.postgresql.org/
- \endverb
- \verb{url}
- \verb https://www.postgresql.org/
- \endverb
- \endentry
- \entry{libcurl}{online}{}
- \list{organization}{1}{%
- {Curl}%
- }
- \field{sortinit}{5}
- \field{sortinithash}{5dd416adbafacc8226114bc0202d5fdd}
- \field{labeltitlesource}{title}
- \field{title}{libcurl - the multiprotocol file transfer library}
- \field{urlday}{2}
- \field{urlmonth}{6}
- \field{urlyear}{2020}
- \field{year}{2020}
- \field{urldateera}{ce}
- \verb{urlraw}
- \verb https://curl.haxx.se/libcurl/
- \endverb
- \verb{url}
- \verb https://curl.haxx.se/libcurl/
- \endverb
- \endentry
- \entry{libmicrohttpd}{online}{}
- \list{organization}{1}{%
- {GNU project}%
- }
- \field{sortinit}{5}
- \field{sortinithash}{5dd416adbafacc8226114bc0202d5fdd}
- \field{labeltitlesource}{title}
- \field{title}{GNU Libmicrohttpd}
- \field{urlday}{2}
- \field{urlmonth}{6}
- \field{urlyear}{2020}
- \field{year}{2020}
- \field{urldateera}{ce}
- \verb{urlraw}
- \verb https://www.gnu.org/software/libmicrohttpd/?
- \endverb
- \verb{url}
- \verb https://www.gnu.org/software/libmicrohttpd/?
- \endverb
- \endentry
- \entry{global_data_index}{online}{}
- \list{organization}{1}{%
- {Dell EMC.}%
- }
- \field{sortinit}{5}
- \field{sortinithash}{5dd416adbafacc8226114bc0202d5fdd}
- \field{labeltitlesource}{title}
- \field{title}{Global Data Protection Index 2018 – Key Findings}
- \field{urlday}{7}
- \field{urlmonth}{3}
- \field{urlyear}{2020}
- \field{year}{2018}
- \field{urldateera}{ce}
- \verb{urlraw}
- \verb
https://www.delltechnologies.com/content/dam/uwaem/production-design-assets/en/gdpi/assets/infographics/dell-gdpi-vb-key-findings-deck.pdf)
- \endverb
- \verb{url}
- \verb
https://www.delltechnologies.com/content/dam/uwaem/production-design-assets/en/gdpi/assets/infographics/dell-gdpi-vb-key-findings-deck.pdf)
- \endverb
- \endentry
- \entry{forgot_my_pin}{online}{}
- \name{author}{1}{}{%
- {{hash=3690e6a925d190517dbba666878a6978}{%
- family={Frauenfelder},
- familyi={F\bibinitperiod},
- given={Mark},
- giveni={M\bibinitperiod}}}%
- }
- \list{organization}{1}{%
- {WIRED}%
- }
- \strng{namehash}{3690e6a925d190517dbba666878a6978}
- \strng{fullhash}{3690e6a925d190517dbba666878a6978}
- \strng{bibnamehash}{3690e6a925d190517dbba666878a6978}
- \strng{authorbibnamehash}{3690e6a925d190517dbba666878a6978}
- \strng{authornamehash}{3690e6a925d190517dbba666878a6978}
- \strng{authorfullhash}{3690e6a925d190517dbba666878a6978}
- \field{sortinit}{6}
- \field{sortinithash}{7851c86048328b027313775d8fbd2131}
- \field{labelnamesource}{author}
- \field{labeltitlesource}{title}
- \field{title}{I Forgot My PIN’: An Epic Tale of Losing \$30,000 in
Bitcoin}
- \field{urlday}{7}
- \field{urlmonth}{3}
- \field{urlyear}{2020}
- \field{year}{2017}
- \field{urldateera}{ce}
- \verb{urlraw}
- \verb
https://www.wired.com/story/i-forgot-my-pin-an-epic-tale-of-losing-dollar30000-in-bitcoin/
- \endverb
- \verb{url}
- \verb
https://www.wired.com/story/i-forgot-my-pin-an-epic-tale-of-losing-dollar30000-in-bitcoin/
- \endverb
- \endentry
- \enddatalist
-\endrefsection
-\endinput
-
diff --git a/doc/thesis/thesis.lot b/doc/thesis/thesis.lot
deleted file mode 100644
index 1a53ee5..0000000
--- a/doc/thesis/thesis.lot
+++ /dev/null
@@ -1,3 +0,0 @@
-\boolfalse {citerequest}\boolfalse {citetracker}\boolfalse
{pagetracker}\boolfalse {backtracker}\relax
-\defcounter {refsection}{0}\relax
-\selectlanguage *{english}
diff --git a/doc/thesis/thesis.out b/doc/thesis/thesis.out
deleted file mode 100644
index 1844bf4..0000000
--- a/doc/thesis/thesis.out
+++ /dev/null
@@ -1,80 +0,0 @@
-\BOOKMARK
[1][-]{section.1}{\376\377\000I\000n\000t\000r\000o\000d\000u\000c\000t\000i\000o\000n}{}%
1
-\BOOKMARK
[2][-]{subsection.1.1}{\376\377\000P\000r\000i\000n\000c\000i\000p\000l\000e\000s}{section.1}%
2
-\BOOKMARK
[2][-]{subsection.1.2}{\376\377\000A\000p\000p\000r\000o\000a\000c\000h}{section.1}%
3
-\BOOKMARK
[2][-]{subsection.1.3}{\376\377\000U\000s\000e\000\040\000c\000a\000s\000e\000s}{section.1}%
4
-\BOOKMARK
[3][-]{subsubsection.1.3.1}{\376\377\000E\000n\000c\000r\000y\000p\000t\000e\000d\000\040\000e\000m\000a\000i\000l\000\040\000c\000o\000m\000m\000u\000n\000i\000c\000a\000t\000i\000o\000n}{subsection.1.3}%
5
-\BOOKMARK
[3][-]{subsubsection.1.3.2}{\376\377\000D\000i\000g\000i\000t\000a\000l\000\040\000c\000u\000r\000r\000e\000n\000c\000i\000e\000s\000\040\000a\000n\000d\000\040\000p\000a\000y\000m\000e\000n\000t\000\040\000s\000o\000l\000u\000t\000i\000o\000n\000s}{subsection.1.3}%
6
-\BOOKMARK
[3][-]{subsubsection.1.3.3}{\376\377\000P\000a\000s\000s\000w\000o\000r\000d\000\040\000m\000a\000n\000a\000g\000e\000r\000s}{subsection.1.3}%
7
-\BOOKMARK
[3][-]{subsubsection.1.3.4}{\376\377\000H\000a\000r\000d\000\040\000d\000r\000i\000v\000e\000\040\000e\000n\000c\000r\000y\000p\000t\000i\000o\000n}{subsection.1.3}%
8
-\BOOKMARK
[1][-]{section.2}{\376\377\000P\000r\000o\000j\000e\000c\000t\000\040\000m\000a\000n\000a\000g\000e\000m\000e\000n\000t}{}%
9
-\BOOKMARK
[1][-]{section.3}{\376\377\000R\000e\000l\000a\000t\000e\000d\000\040\000w\000o\000r\000k}{}%
10
-\BOOKMARK
[2][-]{subsection.3.1}{\376\377\000C\000r\000y\000p\000t\000o\000g\000r\000a\000p\000h\000i\000c\000\040\000p\000r\000i\000m\000i\000t\000i\000v\000e\000s}{section.3}%
11
-\BOOKMARK
[3][-]{subsubsection.3.1.1}{\376\377\000P\000s\000e\000u\000d\000o\000-\000r\000a\000n\000d\000o\000m\000n\000e\000s\000s}{subsection.3.1}%
12
-\BOOKMARK
[3][-]{subsubsection.3.1.2}{\376\377\000H\000a\000s\000h\000\040\000f\000u\000n\000c\000t\000i\000o\000n}{subsection.3.1}%
13
-\BOOKMARK
[3][-]{subsubsection.3.1.3}{\376\377\000H\000M\000A\000C}{subsection.3.1}% 14
-\BOOKMARK
[3][-]{subsubsection.3.1.4}{\376\377\000H\000K\000D\000F}{subsection.3.1}% 15
-\BOOKMARK
[3][-]{subsubsection.3.1.5}{\376\377\000A\000r\000g\000o\000n\0002}{subsection.3.1}%
16
-\BOOKMARK
[2][-]{subsection.3.2}{\376\377\000S\000e\000c\000r\000e\000t\000\040\000s\000h\000a\000r\000i\000n\000g}{section.3}%
17
-\BOOKMARK
[3][-]{subsubsection.3.2.1}{\376\377\000S\000h\000a\000m\000i\000r\000'\000s\000\040\000s\000e\000c\000r\000e\000t\000\040\000s\000h\000a\000r\000i\000n\000g}{subsection.3.2}%
18
-\BOOKMARK
[3][-]{subsubsection.3.2.2}{\376\377\000V\000e\000r\000i\000f\000i\000a\000b\000l\000e\000\040\000s\000e\000c\000r\000e\000t\000\040\000s\000h\000a\000r\000i\000n\000g}{subsection.3.2}%
19
-\BOOKMARK
[3][-]{subsubsection.3.2.3}{\376\377\000D\000i\000s\000t\000r\000i\000b\000u\000t\000e\000d\000\040\000k\000e\000y\000\040\000g\000e\000n\000e\000r\000a\000t\000i\000o\000n}{subsection.3.2}%
20
-\BOOKMARK
[2][-]{subsection.3.3}{\376\377\000A\000u\000t\000h\000e\000n\000t\000i\000c\000a\000t\000i\000o\000n}{section.3}%
21
-\BOOKMARK
[3][-]{subsubsection.3.3.1}{\376\377\000P\000a\000s\000s\000w\000o\000r\000d\000\040\000a\000u\000t\000h\000e\000n\000t\000i\000c\000a\000t\000i\000o\000n}{subsection.3.3}%
22
-\BOOKMARK
[3][-]{subsubsection.3.3.2}{\376\377\000S\000e\000c\000u\000r\000e\000\040\000q\000u\000e\000s\000t\000i\000o\000n}{subsection.3.3}%
23
-\BOOKMARK
[3][-]{subsubsection.3.3.3}{\376\377\000S\000M\000S\000\040\000a\000u\000t\000h\000e\000n\000t\000i\000c\000a\000t\000i\000o\000n}{subsection.3.3}%
24
-\BOOKMARK
[3][-]{subsubsection.3.3.4}{\376\377\000E\000-\000m\000a\000i\000l\000\040\000a\000u\000t\000h\000e\000n\000t\000i\000c\000a\000t\000i\000o\000n}{subsection.3.3}%
25
-\BOOKMARK
[3][-]{subsubsection.3.3.5}{\376\377\000V\000i\000d\000e\000o\000I\000d\000e\000n\000t}{subsection.3.3}%
26
-\BOOKMARK
[3][-]{subsubsection.3.3.6}{\376\377\000P\000o\000s\000t\000I\000d\000e\000n\000t}{subsection.3.3}%
27
-\BOOKMARK
[3][-]{subsubsection.3.3.7}{\376\377\000B\000i\000o\000m\000e\000t\000r\000i\000c\000\040\000a\000u\000t\000h\000e\000n\000t\000i\000c\000a\000t\000i\000o\000n}{subsection.3.3}%
28
-\BOOKMARK
[2][-]{subsection.3.4}{\376\377\000E\000x\000i\000s\000t\000i\000n\000g\000\040\000s\000o\000l\000u\000t\000i\000o\000n\000s\000\040\000f\000o\000r\000\040\000k\000e\000y\000\040\000r\000e\000c\000o\000v\000e\000r\000y}{section.3}%
29
-\BOOKMARK
[3][-]{subsubsection.3.4.1}{\376\377\000C\000o\000i\000n\000b\000a\000s\000e}{subsection.3.4}%
30
-\BOOKMARK
[3][-]{subsubsection.3.4.2}{\376\377\000M\000I\000D\000A\000T\000A}{subsection.3.4}%
31
-\BOOKMARK [1][-]{section.4}{\376\377\000D\000e\000s\000i\000g\000n}{}% 32
-\BOOKMARK
[2][-]{subsection.4.1}{\376\377\000O\000v\000e\000r\000v\000i\000e\000w}{section.4}%
33
-\BOOKMARK
[2][-]{subsection.4.2}{\376\377\000A\000d\000v\000e\000r\000s\000a\000r\000y\000\040\000m\000o\000d\000e\000l}{section.4}%
34
-\BOOKMARK
[2][-]{subsection.4.3}{\376\377\000E\000n\000c\000r\000y\000p\000t\000i\000o\000n\000\040\000o\000f\000\040\000t\000h\000e\000\040\000c\000o\000r\000e\000\040\000s\000e\000c\000r\000e\000t}{section.4}%
35
-\BOOKMARK
[2][-]{subsection.4.4}{\376\377\000T\000h\000e\000\040\000r\000e\000c\000o\000v\000e\000r\000y\000\040\000d\000o\000c\000u\000m\000e\000n\000t}{section.4}%
36
-\BOOKMARK
[2][-]{subsection.4.5}{\376\377\000I\000d\000e\000n\000t\000i\000t\000y\000-\000d\000e\000r\000i\000v\000e\000d\000\040\000e\000n\000c\000r\000y\000p\000t\000i\000o\000n}{section.4}%
37
-\BOOKMARK
[2][-]{subsection.4.6}{\376\377\000A\000u\000t\000h\000e\000n\000t\000i\000c\000i\000t\000y\000\040\000o\000f\000\040\000r\000e\000c\000o\000v\000e\000r\000y\000\040\000d\000o\000c\000u\000m\000e\000n\000t\000s}{section.4}%
38
-\BOOKMARK
[2][-]{subsection.4.7}{\376\377\000A\000c\000c\000o\000u\000n\000t\000\040\000s\000i\000g\000n\000a\000t\000u\000r\000e\000s}{section.4}%
39
-\BOOKMARK
[2][-]{subsection.4.8}{\376\377\000A\000u\000t\000h\000e\000n\000t\000i\000c\000i\000t\000y\000\040\000o\000f\000\040\000t\000r\000u\000t\000h}{section.4}%
40
-\BOOKMARK
[2][-]{subsection.4.9}{\376\377\000A\000v\000a\000i\000l\000a\000b\000i\000l\000i\000t\000y\000\040\000c\000o\000n\000s\000i\000d\000e\000r\000a\000t\000i\000o\000n\000s}{section.4}%
41
-\BOOKMARK
[1][-]{section.5}{\376\377\000I\000m\000p\000l\000e\000m\000e\000n\000t\000a\000t\000i\000o\000n}{}%
42
-\BOOKMARK
[2][-]{subsection.5.1}{\376\377\000S\000y\000s\000t\000e\000m\000\040\000a\000r\000c\000h\000i\000t\000e\000c\000t\000u\000r\000e}{section.5}%
43
-\BOOKMARK
[2][-]{subsection.5.2}{\376\377\000S\000e\000r\000v\000e\000r\000\040\000a\000r\000c\000h\000i\000t\000e\000c\000t\000u\000r\000e}{section.5}%
44
-\BOOKMARK
[3][-]{subsubsection.5.2.1}{\376\377\000D\000a\000t\000a\000b\000a\000s\000e}{subsection.5.2}%
45
-\BOOKMARK
[3][-]{subsubsection.5.2.2}{\376\377\000A\000u\000t\000h\000e\000n\000t\000i\000c\000a\000t\000i\000o\000n\000\040\000m\000e\000t\000h\000o\000d\000s}{subsection.5.2}%
46
-\BOOKMARK
[2][-]{subsection.5.3}{\376\377\000C\000l\000i\000e\000n\000t\000\040\000a\000r\000c\000h\000i\000t\000e\000c\000t\000u\000r\000e}{section.5}%
47
-\BOOKMARK
[3][-]{subsubsection.5.3.1}{\376\377\000C\000r\000y\000p\000t\000o\000\040\000A\000P\000I}{subsection.5.3}%
48
-\BOOKMARK
[3][-]{subsubsection.5.3.2}{\376\377\000C\000l\000i\000e\000n\000t\000\040\000A\000P\000I}{subsection.5.3}%
49
-\BOOKMARK
[3][-]{subsubsection.5.3.3}{\376\377\000S\000e\000r\000v\000i\000c\000e\000\040\000A\000P\000I}{subsection.5.3}%
50
-\BOOKMARK
[2][-]{subsection.5.4}{\376\377\000A\000p\000p\000l\000i\000c\000a\000t\000i\000o\000n\000\040\000f\000l\000o\000w}{section.5}%
51
-\BOOKMARK
[3][-]{subsubsection.5.4.1}{\376\377\000S\000e\000c\000r\000e\000t\000\040\000s\000p\000l\000i\000t\000t\000i\000n\000g}{subsection.5.4}%
52
-\BOOKMARK
[3][-]{subsubsection.5.4.2}{\376\377\000S\000e\000c\000r\000e\000t\000\040\000r\000e\000c\000o\000v\000e\000r\000y}{subsection.5.4}%
53
-\BOOKMARK
[2][-]{subsection.5.5}{\376\377\000C\000l\000i\000e\000n\000t\000\040\000A\000p\000p\000l\000i\000c\000a\000t\000i\000o\000n\000\040\000C\000o\000m\000m\000a\000n\000d\000\040\000L\000i\000n\000e\000\040\000I\000n\000t\000e\000r\000f\000a\000c\000e\000\040\000\050\000C\000L\000I\000\051}{section.5}%
54
-\BOOKMARK
[3][-]{subsubsection.5.5.1}{\376\377\000A\000n\000a\000s\000t\000a\000s\000i\000s\000\040\000s\000p\000l\000i\000t\000t\000e\000r}{subsection.5.5}%
55
-\BOOKMARK
[3][-]{subsubsection.5.5.2}{\376\377\000A\000n\000a\000s\000t\000a\000s\000i\000s\000\040\000a\000s\000s\000e\000m\000b\000l\000e\000r}{subsection.5.5}%
56
-\BOOKMARK
[2][-]{subsection.5.6}{\376\377\000L\000i\000b\000r\000a\000r\000i\000e\000s}{section.5}%
57
-\BOOKMARK
[3][-]{subsubsection.5.6.1}{\376\377\000G\000N\000U\000\040\000T\000a\000l\000e\000r}{subsection.5.6}%
58
-\BOOKMARK
[3][-]{subsubsection.5.6.2}{\376\377\000P\000o\000s\000t\000g\000r\000e\000S\000Q\000L}{subsection.5.6}%
59
-\BOOKMARK
[3][-]{subsubsection.5.6.3}{\376\377\000L\000i\000b\000c\000u\000r\000l}{subsection.5.6}%
60
-\BOOKMARK
[3][-]{subsubsection.5.6.4}{\376\377\000G\000N\000U\000\040\000L\000i\000b\000m\000i\000c\000r\000o\000h\000t\000t\000p\000d}{subsection.5.6}%
61
-\BOOKMARK
[2][-]{subsection.5.7}{\376\377\000T\000e\000s\000t\000i\000n\000g}{section.5}%
62
-\BOOKMARK
[1][-]{section.6}{\376\377\000B\000u\000s\000i\000n\000e\000s\000s\000\040\000m\000o\000d\000e\000l}{}%
63
-\BOOKMARK
[2][-]{subsection.6.1}{\376\377\000E\000x\000e\000c\000u\000t\000i\000v\000e\000\040\000s\000u\000m\000m\000a\000r\000y}{section.6}%
64
-\BOOKMARK
[2][-]{subsection.6.2}{\376\377\000M\000a\000r\000k\000e\000t\000\040\000r\000e\000v\000i\000e\000w\000\040\000a\000n\000d\000\040\000i\000n\000n\000o\000v\000a\000t\000i\000o\000n\000\040\000p\000o\000t\000e\000n\000t\000i\000a\000l}{section.6}%
65
-\BOOKMARK
[2][-]{subsection.6.3}{\376\377\000B\000u\000s\000i\000n\000e\000s\000s\000\040\000m\000o\000d\000e\000l\000\040\000c\000a\000n\000v\000a\000s}{section.6}%
66
-\BOOKMARK
[3][-]{subsubsection.6.3.1}{\376\377\000K\000e\000y\000\040\000p\000a\000r\000t\000n\000e\000r\000s}{subsection.6.3}%
67
-\BOOKMARK
[3][-]{subsubsection.6.3.2}{\376\377\000K\000e\000y\000\040\000a\000c\000t\000i\000v\000i\000t\000i\000e\000s}{subsection.6.3}%
68
-\BOOKMARK
[3][-]{subsubsection.6.3.3}{\376\377\000K\000e\000y\000\040\000r\000e\000s\000o\000u\000r\000c\000e\000s}{subsection.6.3}%
69
-\BOOKMARK
[3][-]{subsubsection.6.3.4}{\376\377\000V\000a\000l\000u\000e\000\040\000p\000r\000o\000p\000o\000s\000i\000t\000i\000o\000n\000s}{subsection.6.3}%
70
-\BOOKMARK
[3][-]{subsubsection.6.3.5}{\376\377\000C\000u\000s\000t\000o\000m\000e\000r\000\040\000r\000e\000l\000a\000t\000i\000o\000n\000s\000h\000i\000p\000s}{subsection.6.3}%
71
-\BOOKMARK
[3][-]{subsubsection.6.3.6}{\376\377\000C\000u\000s\000t\000o\000m\000e\000r\000\040\000s\000e\000g\000m\000e\000n\000t\000s}{subsection.6.3}%
72
-\BOOKMARK
[3][-]{subsubsection.6.3.7}{\376\377\000C\000o\000s\000t\000\040\000s\000t\000r\000u\000c\000t\000u\000r\000e}{subsection.6.3}%
73
-\BOOKMARK
[3][-]{subsubsection.6.3.8}{\376\377\000R\000e\000v\000e\000n\000u\000e\000\040\000s\000t\000r\000e\000a\000m\000s}{subsection.6.3}%
74
-\BOOKMARK
[2][-]{subsection.6.4}{\376\377\000P\000r\000o\000j\000e\000c\000t\000\040\000p\000l\000a\000n}{section.6}%
75
-\BOOKMARK
[1][-]{section.7}{\376\377\000C\000o\000n\000c\000l\000u\000s\000i\000o\000n\000\040\000a\000n\000d\000\040\000o\000u\000t\000l\000o\000o\000k}{}%
76
-\BOOKMARK
[1][-]{appendix.A}{\376\377\000R\000E\000S\000T\000\040\000A\000P\000I\000\040\000d\000o\000c\000u\000m\000e\000n\000t\000a\000t\000i\000o\000n}{}%
77
-\BOOKMARK
[1][-]{appendix.B}{\376\377\000W\000o\000r\000k\000\040\000j\000o\000u\000r\000n\000a\000l}{}%
78
-\BOOKMARK
[1][-]{section*.92}{\376\377\000G\000l\000o\000s\000s\000a\000r\000y}{}% 79
-\BOOKMARK
[1][-]{section*.93}{\376\377\000R\000e\000f\000e\000r\000e\000n\000c\000e\000s}{}%
80
diff --git a/doc/thesis/thesis.run.xml b/doc/thesis/thesis.run.xml
deleted file mode 100644
index 66c9ec2..0000000
--- a/doc/thesis/thesis.run.xml
+++ /dev/null
@@ -1,91 +0,0 @@
-<?xml version="1.0" standalone="yes"?>
-<!-- logreq request file -->
-<!-- logreq version 1.0 / dtd version 1.0 -->
-<!-- Do not edit this file! -->
-<!DOCTYPE requests [
- <!ELEMENT requests (internal | external)*>
- <!ELEMENT internal (generic, (provides | requires)*)>
- <!ELEMENT external (generic, cmdline?, input?, output?, (provides |
requires)*)>
- <!ELEMENT cmdline (binary, (option | infile | outfile)*)>
- <!ELEMENT input (file)+>
- <!ELEMENT output (file)+>
- <!ELEMENT provides (file)+>
- <!ELEMENT requires (file)+>
- <!ELEMENT generic (#PCDATA)>
- <!ELEMENT binary (#PCDATA)>
- <!ELEMENT option (#PCDATA)>
- <!ELEMENT infile (#PCDATA)>
- <!ELEMENT outfile (#PCDATA)>
- <!ELEMENT file (#PCDATA)>
- <!ATTLIST requests
- version CDATA #REQUIRED
- >
- <!ATTLIST internal
- package CDATA #REQUIRED
- priority (9) #REQUIRED
- active (0 | 1) #REQUIRED
- >
- <!ATTLIST external
- package CDATA #REQUIRED
- priority (1 | 2 | 3 | 4 | 5 | 6 | 7 | 8) #REQUIRED
- active (0 | 1) #REQUIRED
- >
- <!ATTLIST provides
- type (static | dynamic | editable) #REQUIRED
- >
- <!ATTLIST requires
- type (static | dynamic | editable) #REQUIRED
- >
- <!ATTLIST file
- type CDATA #IMPLIED
- >
-]>
-<requests version="1.0">
- <internal package="biblatex" priority="9" active="1">
- <generic>latex</generic>
- <provides type="dynamic">
- <file>thesis.bcf</file>
- </provides>
- <requires type="dynamic">
- <file>thesis.bbl</file>
- </requires>
- <requires type="static">
- <file>blx-dm.def</file>
- <file>blx-unicode.def</file>
- <file>blx-compat.def</file>
- <file>blx-case-expl3.def</file>
- <file>biblatex.def</file>
- <file>standard.bbx</file>
- <file>numeric.bbx</file>
- <file>numeric-comp.bbx</file>
- <file>ieee.bbx</file>
- <file>numeric-comp.cbx</file>
- <file>ieee.cbx</file>
- <file>biblatex.cfg</file>
- <file>english.lbx</file>
- <file>american.lbx</file>
- </requires>
- </internal>
- <external package="biblatex" priority="5" active="1">
- <generic>biber</generic>
- <cmdline>
- <binary>biber</binary>
- <infile>thesis</infile>
- </cmdline>
- <input>
- <file>thesis.bcf</file>
- </input>
- <output>
- <file>thesis.bbl</file>
- </output>
- <provides type="dynamic">
- <file>thesis.bbl</file>
- </provides>
- <requires type="dynamic">
- <file>thesis.bcf</file>
- </requires>
- <requires type="editable">
- <file>bibliothek.bib</file>
- </requires>
- </external>
-</requests>
diff --git a/doc/thesis/thesis.tex b/doc/thesis/thesis.tex
deleted file mode 100644
index 22b0f2a..0000000
--- a/doc/thesis/thesis.tex
+++ /dev/null
@@ -1,118 +0,0 @@
-\documentclass{scrartcl}
-\usepackage{lipsum}
-%%\usepackage[french]{babel}
-%%\usepackage[ngerman]{babel}
-
-%% Choose default font for the document
-%% Warning : only ONE of the following should be enabled
-\usepackage{kpfonts}
-%%\usepackage{libertine}
-\usepackage[table]{xcolor}
-%% The following chose the default language for the document and
-%% use the default typography rules for the chosen language.
-\usepackage{polyglossia}
-\setdefaultlanguage{english}
-%% \setdefaultlanguage{german}
-%%\setdefaultlanguage{french}
-\usepackage{float}
-\usepackage[toc,page]{appendix}
-\usepackage[backend=biber, style=ieee]{biblatex}
-\addbibresource{bibliothek.bib}
-\usepackage[export]{adjustbox}
-\usepackage{menukeys}
-\usepackage{abstract}
-\usepackage{pdfpages}
-\usepackage{hyperref}
-\usepackage{graphicx}
-\usepackage{listings}
-\lstset{language=C,
- basicstyle=\ttfamily,
- keywordstyle=\bfseries,
- showstringspaces=false,
- morekeywords={include, printf, interface}
-}
-
-\begin{document}
-\pagenumbering{gobble}
-\clearpage
-\thispagestyle{empty}
-
-%% include BFH logo and HuCE-ml logo
-\begin{figure}
- \includegraphics[scale=1,valign=t]{images/BFH_Logo_A_en_100_4CU.pdf}
-\end{figure}
-
-%% Document title and subtitle
-
-\begin{minipage}[c][3cm][c]{\linewidth} {
- \centering
- \vspace*{2cm}
- {\fontsize{24pt}{0pt}\selectfont \textbf{Anastasis}} \\
- \vspace*{0.6cm}
- {\fontsize{20pt}{0pt}\selectfont Password-less key recovery via
multi-factor
-multi-party authentication} \\
- \vspace*{1cm}
- {\fontsize{14pt}{0pt}\selectfont Bachelor thesis} \\
-
-}
-\end{minipage}
-
-\vspace{1.5cm}
-
-\vfill
-
-%% Author and document information
-\begin{minipage}[c][3cm][c]{\linewidth}
-{
- \centering
- \begin{tabbing}
-
xxxxxxxxxxxxxxxxxxx\=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \kill
- Field of Studies: \> Computer science bachelor,
IT-Security \\
- Authors: \> Dominik Samuel Meister, Dennis
Neufeld \\
- Supervisor: \> Prof. Dr. Christian Grothoff \\
- Expert: \> Pierre-Yves Voirol \\
- Date: \> \today \\
- \end{tabbing}
-}
-\end{minipage}
-
-\pagebreak
-
-\clearpage
-\pagenumbering{roman}
-%\includepdf{images/selbst_meister.pdf}
-%\includepdf{images/selbst_dennis.pdf}
-\include{abstract}
-\include{acknowledgments}
-
-\tableofcontents
-\listoffigures
-
-\clearpage
-\pagenumbering{arabic}
-\include{introduction}
-
-\include{project_management}
-
-\include{related_work}
-
-\include{design}
-
-\include{implementation}
-
-\include{business_model}
-
-\include{conclusion}
-
-\appendix
-\include{rest_api_documentation}
-\include{Journal}
-
-\clearpage
-\include{glossary}
-\clearpage
-
-%% Print the bibibliography and add the section to th table of content
-\printbibliography[heading=bibintoc]
-
-\end{document}
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [taler-anastasis] branch master updated: cleanup,
gnunet <=