[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-anastasis] branch master updated: misc minor edits
From: |
gnunet |
Subject: |
[taler-anastasis] branch master updated: misc minor edits |
Date: |
Wed, 10 Jun 2020 23:57:16 +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 c029d9a misc minor edits
c029d9a is described below
commit c029d9a85736284f0520a5d45239c9c47fe4330f
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Wed Jun 10 23:57:13 2020 +0200
misc minor edits
---
doc/thesis/business_model.tex | 47 ++++++++++++++++++++++++--------------
doc/thesis/client_architecture.tex | 4 ++--
doc/thesis/design.tex | 4 ++--
doc/thesis/implementation.tex | 10 ++++----
4 files changed, 39 insertions(+), 26 deletions(-)
diff --git a/doc/thesis/business_model.tex b/doc/thesis/business_model.tex
index 2171379..ecfcf1f 100644
--- a/doc/thesis/business_model.tex
+++ b/doc/thesis/business_model.tex
@@ -95,9 +95,9 @@ wallet key.
\subsubsection{Key partners}
Our key partners for Anastasis are three entities. First the business
-partners, Taler Systems SA and PEP Foundation, with whom we could
+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
+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
@@ -147,20 +147,32 @@ 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 which wants to integrate
-our solution into their wallet. This means at the begin our customers
-are mainly the users of already existing solutions. In later stages of
-our start-up we also want to acquire business to customer clients, for
-example users who want to secure their private key for their disk
-encryption.
+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}
-As mentioned earlier our customers will be primarily other solutions
-which need a way to backup their keys. Many applications with
-decentralized structures need such a solution. Other possible
-customers are users of digital currencies or users of OpenPGP
-solutions.
+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}
@@ -177,10 +189,11 @@ 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 micro payments for each transaction. For
-example a user has to pay 0.1 CHF per month for the subscription and
-0.01 CHF for each upload. Additionally, the user would have to pay for
-expensive authentication methods like video identification.
+a subscription fee and possibly additinal 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}
diff --git a/doc/thesis/client_architecture.tex
b/doc/thesis/client_architecture.tex
index ebe34a5..9c6e1e1 100644
--- a/doc/thesis/client_architecture.tex
+++ b/doc/thesis/client_architecture.tex
@@ -26,8 +26,8 @@ The most important data structures in the crypto API are the
following:
\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 Implementation
-Cryptography
+to create various key's, for more details see Chapter~\ref{chap:design}.
+
\begin{lstlisting}
struct kdf_id
{
diff --git a/doc/thesis/design.tex b/doc/thesis/design.tex
index 513104d..34a554f 100644
--- a/doc/thesis/design.tex
+++ b/doc/thesis/design.tex
@@ -1,4 +1,4 @@
-\section{Design}
+\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
@@ -379,7 +379,7 @@ 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 all operations. Furthermore, all data stored
+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.
diff --git a/doc/thesis/implementation.tex b/doc/thesis/implementation.tex
index 40a5095..d347ace 100644
--- a/doc/thesis/implementation.tex
+++ b/doc/thesis/implementation.tex
@@ -156,7 +156,7 @@ Figure~\ref{fig:recovery_process} illustrates the recovery
process.
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/\$UUID?resonse=\$RESPONSE) \\
+ /truth/\$UUID?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
@@ -405,7 +405,7 @@ The following four tests are independently performed.
\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
+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
@@ -415,8 +415,8 @@ service is needed to proccess 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.
+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}
\ No newline at end of file
+recovered core secret.
+\end{itemize}
--
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: misc minor edits,
gnunet <=