From a2f34b4e1a36a70333019825c7f6f73e69c91da0 Mon Sep 17 00:00:00 2001 From: Zooko O'Whielacronx Date: Mon, 13 Apr 2009 09:08:37 -0700 Subject: [PATCH] docs: a few edits/updates about dirnodes --- docs/specifications/dirnodes.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/specifications/dirnodes.txt b/docs/specifications/dirnodes.txt index 7023f86c..dff41ecd 100644 --- a/docs/specifications/dirnodes.txt +++ b/docs/specifications/dirnodes.txt @@ -238,7 +238,7 @@ How well does this design meet the goals? -=== Confidentiality leaks in the vdrive server === +=== Confidentiality leaks in the storage servers === Dirnode (and the mutable files upon which they are based) are very private against other clients: traffic between the client and the storage servers is @@ -259,7 +259,7 @@ attacker may be able to build up a graph with the same shape as the plaintext filesystem, but with unlabeled edges and unknown file contents. -=== Integrity failures in the vdrive server === +=== Integrity failures in the storage servers === The mutable file's integrity mechanism (RSA signature on the hash of the file contents) prevents the storage server from modifying the dirnode's contents @@ -268,8 +268,8 @@ unavailable, but not corrupt it. A sufficient number of colluding storage servers can perform a rollback attack: replace all shares of the whole mutable file with an earlier version. -TODO: To prevent this, when retrieving the contents of a mutable file, the -client should query more servers than necessary and use the highest available +To prevent this, when retrieving the contents of a mutable file, the +client queries more servers than necessary and uses the highest available version number. This insures that one or two misbehaving storage servers cannot cause this rollback on their own. -- 2.45.2