gnunet-svn
[Top][All Lists]
Advanced

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

[GNUnet-SVN] [taler-docs] branch master updated: add section on availabi


From: gnunet
Subject: [GNUnet-SVN] [taler-docs] branch master updated: add section on availability
Date: Tue, 08 Oct 2019 14:43:24 +0200

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository docs.

The following commit(s) were added to refs/heads/master by this push:
     new 71bf76b  add section on availability
71bf76b is described below

commit 71bf76b66471be10faed6f7e98ab898ff39ee5a0
Author: Christian Grothoff <address@hidden>
AuthorDate: Tue Oct 8 14:43:22 2019 +0200

    add section on availability
---
 anastasis.rst | 34 +++++++++++++++++++++++++++++++++-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/anastasis.rst b/anastasis.rst
index eff15db..af4d575 100644
--- a/anastasis.rst
+++ b/anastasis.rst
@@ -273,6 +273,36 @@ FIXME: missing crypto! (See "EKS" below!)
 In particular, underspecified for the security answer ("may additionally 
include"...).
 
 
+---------------------------
+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 all
+operations. Furthermore, all data stored comes with an expiration logic, so an
+attacker cannot force servers to store data indefinitively.
+
+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 secret** 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.
+
+
 
 -------------
 Anastasis API
@@ -559,7 +589,9 @@ charge per truth operation using GNU Taler.
   :status 204 No content:
     Truth stored successfully.
   :status 304 Not modified:
-    The same truth was previously accepted and stored under this UUID.
+    The same truth was previously accepted and stored under this UUID.  The
+    Anastasis server must still update the expiration time for the truth when 
returning
+    this response code.
   :status 402 Payment Required:
     This server requires payment to store truth per item.
     See the Taler payment protocol specification for how to pay.

-- 
To stop receiving notification emails like this one, please contact
address@hidden.



reply via email to

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