gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[taler-anastasis] branch master updated: start abstract with thesis stat


From: gnunet
Subject: [taler-anastasis] branch master updated: start abstract with thesis statement, rewrite to be a bit more pushy
Date: Sat, 06 Jun 2020 22:03:31 +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 3c18646  start abstract with thesis statement, rewrite to be a bit 
more pushy
3c18646 is described below

commit 3c18646ed74791839067afbd64bb3b808e4db806
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Sat Jun 6 22:03:29 2020 +0200

    start abstract with thesis statement, rewrite to be a bit more pushy
---
 doc/thesis/abstract.tex     | 47 +++++++++++++++++--------------------
 doc/thesis/introduction.tex | 56 +++++++++++++++++++++++++++++++++++++++++----
 2 files changed, 72 insertions(+), 31 deletions(-)

diff --git a/doc/thesis/abstract.tex b/doc/thesis/abstract.tex
index 55c2e76..d34c9c0 100644
--- a/doc/thesis/abstract.tex
+++ b/doc/thesis/abstract.tex
@@ -2,33 +2,28 @@
 \begin{abstract}
 %\addcontentsline{toc}{section}{Abstract} % Usually not in TOC
 
-Everyone has probably noticed at least once through the media that
-someone has lost their key to their electronic wallet and therefore
-huge sums of money have become useless. Therefore, backup systems are
-essential to avoid such cases.
 
-But how should one create and manage such a 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 password can also
-be forgotten. Apart from that, the question arises how or where to
-save such a backup. A simple storage on e.g. Google Drive bears
-several risks: On the one hand, we are talking about Google, a company
-that is known to cooperate with certain authorities, and on the other
-hand, the cloud storage may be synchronized on several devices, to
-which someone else could possibly gain access. Unfortunately, to the
-best of our knowledge, there is no backup solution for keys that works
-password-less while giving the user complete control over his data.
+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.
 
-With Anastasis this gap shall be filled and a solution for secure
-recovery of secret keys, which works without passwords or other key
-material, shall be offered. 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.
 
-This
-thesis describes the design and implementation of Anastasis.
 \end{abstract}
diff --git a/doc/thesis/introduction.tex b/doc/thesis/introduction.tex
index dbfb7e8..bd1c859 100644
--- a/doc/thesis/introduction.tex
+++ b/doc/thesis/introduction.tex
@@ -1,7 +1,36 @@
 \section{Introduction}
-Secure storage of private cryptographic keys or in general every kind of core 
secret is a big problem. Most current key management systems just reduce the 
problem of memorizing a high-entropy passphrase or key to memorizing a 
low-entropy passphrase. This of course cannot be the solution because you 
undermine the whole security of a cryptographic system using such solutions.\\
-Key management systems have to deal with the question, how to store a key. 
Keys are used to encrypt high sensitive personal data and therefore they must 
be kept safely. Only the legitimated owner of a key should have the possibility 
to recover a lost key. Most people have difficulties memorizing a high-entropy 
passphrase and therefore tend to use low-entropy passphrases. That is why you 
can't rely on memorizing a password which is needed to recover a key.\\
-We have a software solution for the described problem. We call our solution 
"Anastasis" which is a term for restoration to health in medicine.\\
+
+Secure storage of private cryptographic keys or in general every kind
+of core secret is a big problem.
+
+But how should one create and manage such a 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 password can also
+be forgotten. Apart from that, the question arises how or where to
+save such a backup. A simple storage on e.g. Google Drive bears
+several risks: On the one hand, we are talking about Google, a company
+that is known to cooperate with certain authorities, and on the other
+hand, the cloud storage may be synchronized on several devices, to
+which someone else could possibly gain access. Unfortunately, to the
+best of our knowledge, there is no backup solution for keys that works
+password-less while giving the user complete control over his data.
+
+
+
+Most current key management systems
+just reduce the problem of memorizing a high-entropy passphrase or key
+to memorizing a low-entropy passphrase. This of course cannot be the
+solution because you undermine the whole security of a cryptographic
+system using such solutions. Key management systems have to deal with
+the question, how to store a key. Keys are used to encrypt high
+sensitive personal data and therefore they must be kept safely. Only
+the legitimated owner of a key should have the possibility to recover
+a lost key. Most people have difficulties memorizing a high-entropy
+passphrase and therefore tend to use low-entropy passphrases. That is
+why you can't rely on memorizing a password which is needed to recover
+a key. We have a software solution for the described problem. We call
+our solution ``Anastasis'' which is a term for the prognosis of
+full recovery in medicine.
 
 \subsection{Principles}
 For Anastasis we have following design principles, in order of importance:
@@ -44,7 +73,24 @@ Pretty Easy privacy (short p\equiv p) is "a cyber security 
solution which protec
 
 \subsubsection{Digital currencies and payment solutions}
 \subsubsection*{Bitcoin}
-Another application relying on a core secret are cryptocurrencies like 
Bitcoin. Each user of Bitcoin needs a so called 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}. Therefore 
losing those keys means losing all the corresponding Bitcoins which in some 
cases could be a loss of millions of Euros~\cite{millions_lost}. The following 
graphic illustrates the keys used in B [...]
+
+Another application relying on a core secret are cryptocurrencies like
+Bitcoin. Each user of Bitcoin needs a so called 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}.
+
+
+Loosing Bitcoin wallet keys means losing all 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 Anastasis would store the master key $m$:
+
 \begin{figure}[H]
        \centering
        \includegraphics[scale=3.5]{images/bitcoin-keys.png}
@@ -60,4 +106,4 @@ To avoid using low-entropy passwords and password reuse some 
people use software
 Anastasis can store the passwords for password managers.
 
 \subsubsection{Hard drive encryption}
-Many companies need to backup high sensitive data to be able to recover them 
in an emergency case. Those backups are often stored at external hard drives 
which are encrypted using software like BitLocker~\cite{bitlocker}. For 
encryption and decryption of the hardware additionally to the Trusted Platform 
Module (TPM)~\cite{bajikar2002} of the computer or a key file often a password 
is needed. In case of loosing a key file or a password, Anastasis can save from 
data loss.
\ No newline at end of file
+Many companies need to backup high sensitive data to be able to recover them 
in an emergency case. Those backups are often stored at external hard drives 
which are encrypted using software like BitLocker~\cite{bitlocker}. For 
encryption and decryption of the hardware additionally to the Trusted Platform 
Module (TPM)~\cite{bajikar2002} of the computer or a key file often a password 
is needed. In case of loosing a key file or a password, Anastasis can save from 
data loss.

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]