gnunet-svn
[Top][All Lists]
Advanced

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

[taler-anastasis] branch master updated: dos2unix


From: gnunet
Subject: [taler-anastasis] branch master updated: dos2unix
Date: Sat, 06 Jun 2020 21:47: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 5da2d60  dos2unix
5da2d60 is described below

commit 5da2d60cc728fee81aeace4e10510193a1ea6bed
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Sat Jun 6 21:47:13 2020 +0200

    dos2unix
---
 doc/thesis/abstract.tex     |  33 +++++++++---
 doc/thesis/introduction.tex | 122 ++++++++++++++++++++++----------------------
 2 files changed, 88 insertions(+), 67 deletions(-)

diff --git a/doc/thesis/abstract.tex b/doc/thesis/abstract.tex
index 84192f9..55c2e76 100644
--- a/doc/thesis/abstract.tex
+++ b/doc/thesis/abstract.tex
@@ -2,12 +2,33 @@
 \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.\\
+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 s [...]
-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.\\
+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.
 
-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.
+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 34bdbc8..dbfb7e8 100644
--- a/doc/thesis/introduction.tex
+++ b/doc/thesis/introduction.tex
@@ -1,63 +1,63 @@
-\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.\\
-
-\subsection{Principles}
-For Anastasis we have following design principles, in order of importance:
-\begin{enumerate}
-       \item Anastasis must be Free Software.
-       \item Anastasis must not rely on the trustworthiness of individual 
providers. It must be possible to use Anastasis safely even if an individual 
provider is compromised. Anastasis must minimize the amount of information 
exposed to providers and the network.
-       \item The user is in control.
-       \item The system 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{Approaches}
-\subsubsection*{Secret sharing and recovery}
-Our approach to solve the problem of key management is to let the user split 
their secret across multiple escrow providers (see 
figure~\ref{fig:system_arch2}). To restore the secret again, the user has to 
follow standard authentication procedures. After successful authentication the 
user gets the secret shares to reassemble the secret.
-\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 unforgettably inherent 
attributes such as name and passport number, social security number or AHV 
number (in Switzerland). We use those attributes to derive an user identifier 
from (see figure~\ref{fig:user_id}).
-\begin{figure}[H]
-\centering
-\includegraphics[scale=0.3]{images/user_id.png}
-\caption{Derivation of user identifier}
-\label{fig:user_id}
-\end{figure}
-
-\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}
-\subsubsection*{PGP}
+\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.\\
+
+\subsection{Principles}
+For Anastasis we have following design principles, in order of importance:
+\begin{enumerate}
+       \item Anastasis must be Free Software.
+       \item Anastasis must not rely on the trustworthiness of individual 
providers. It must be possible to use Anastasis safely even if an individual 
provider is compromised. Anastasis must minimize the amount of information 
exposed to providers and the network.
+       \item The user is in control.
+       \item The system 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{Approaches}
+\subsubsection*{Secret sharing and recovery}
+Our approach to solve the problem of key management is to let the user split 
their secret across multiple escrow providers (see 
figure~\ref{fig:system_arch2}). To restore the secret again, the user has to 
follow standard authentication procedures. After successful authentication the 
user gets the secret shares to reassemble the secret.
+\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 unforgettably inherent 
attributes such as name and passport number, social security number or AHV 
number (in Switzerland). We use those attributes to derive an user identifier 
from (see figure~\ref{fig:user_id}).
+\begin{figure}[H]
+\centering
+\includegraphics[scale=0.3]{images/user_id.png}
+\caption{Derivation of user identifier}
+\label{fig:user_id}
+\end{figure}
+
+\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}
+\subsubsection*{PGP}
 For email encryption using Pretty Good Privacy (PGP)~\cite{garfinkel1995} you 
need a private key which is stored to the device running PGP. Losing the PGP 
private key means following: All received emails which are encrypted with a key 
derived from the private key are unreadable and you need to build your trust 
network again. Because emails could contain high sensitive information, it is 
necessary to be able to store the PGP private key securely.
-
-\subsubsection*{p\equiv p}
-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 an end-to-end cryptography. For this the software uses a 
private key. The impact of losing the private key is similar to those of PGP.\\
-
-\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 [...]
-\begin{figure}[H]
-       \centering
-       \includegraphics[scale=3.5]{images/bitcoin-keys.png}
-       \caption{Master key in Bitcoin Wallets~\cite{bitcoin-keys}}
-       \label{fig:bitcoin_keys}
-\end{figure}
-
-\subsubsection*{Taler}
-Taler is a new electronic instant payment system for privacy-friendly online 
transactions. Their digital wallets are storing electronic coins and are 
protected with a private key which loss means losing all the money stored in 
the wallet. Therefor the ECB (European Central Bank) informed Taler Systems SA 
about the requirement for electronic wallets denominated in Euros to support 
password-less data recovery. From this impulse the project Anastasis was 
finally born.
-
-\subsubsection{Password manager}
-To avoid using low-entropy passwords and password reuse some people use 
software password managers like KeePass\footnote{\url{https://keepass.info/}}. 
Those 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. And this exactly is the 
problem: On the one hand, many users will tend to use an insecure, easy to 
remember password even in t [...]
-Anastasis can store the passwords for password managers.
-
-\subsubsection{Hard drive encryption}
+
+\subsubsection*{p\equiv p}
+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 an end-to-end cryptography. For this the software uses a 
private key. The impact of losing the private key is similar to those of PGP.\\
+
+\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 [...]
+\begin{figure}[H]
+       \centering
+       \includegraphics[scale=3.5]{images/bitcoin-keys.png}
+       \caption{Master key in Bitcoin Wallets~\cite{bitcoin-keys}}
+       \label{fig:bitcoin_keys}
+\end{figure}
+
+\subsubsection*{Taler}
+Taler is a new electronic instant payment system for privacy-friendly online 
transactions. Their digital wallets are storing electronic coins and are 
protected with a private key which loss means losing all the money stored in 
the wallet. Therefor the ECB (European Central Bank) informed Taler Systems SA 
about the requirement for electronic wallets denominated in Euros to support 
password-less data recovery. From this impulse the project Anastasis was 
finally born.
+
+\subsubsection{Password manager}
+To avoid using low-entropy passwords and password reuse some people use 
software password managers like KeePass\footnote{\url{https://keepass.info/}}. 
Those 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. And this exactly is the 
problem: On the one hand, many users will tend to use an insecure, easy to 
remember password even in t [...]
+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

-- 
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]