From: Brian Warner Date: Wed, 5 Mar 2008 23:54:26 +0000 (-0700) Subject: docs/mutable: describe deep-verify-cap scheme, update picture X-Git-Tag: allmydata-tahoe-0.9.0~63 X-Git-Url: https://git.rkrishnan.org/%3C?a=commitdiff_plain;h=456b43760830bc6e559d98ea7e8dfe9fe47151df;p=tahoe-lafs%2Ftahoe-lafs.git docs/mutable: describe deep-verify-cap scheme, update picture --- diff --git a/docs/mutable-DSA.svg b/docs/mutable-DSA.svg index c60b9d43..6870d834 100644 --- a/docs/mutable-DSA.svg +++ b/docs/mutable-DSA.svg @@ -73,13 +73,13 @@ inkscape:pageshadow="2" inkscape:zoom="1.0816863" inkscape:cx="380.71238" - inkscape:cy="831.05605" + inkscape:cy="202.40798" inkscape:document-units="px" inkscape:current-layer="layer1" inkscape:window-width="909" inkscape:window-height="818" - inkscape:window-x="30" - inkscape:window-y="80" /> + inkscape:window-x="733" + inkscape:window-y="78" /> @@ -95,35 +95,49 @@ inkscape:label="Layer 1" inkscape:groupmode="layer" id="layer1"> + + + x="39.546387" + y="40.257816" /> DSA private key + x="62.283081" + y="71.371185">DSA private key (256 bit string) + x="87.413116" + y="115.64791">(256 bit string) (2048+ bit string) + d="M 295.45488,119.06891 L 391.92545,138.37512" + style="fill:#00ffff;fill-opacity:1;stroke:#000000;stroke-width:2;stroke-linecap:butt;marker-end:url(#Arrow1Mend);stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" + sodipodi:nodetypes="cc" /> - - - storage index - - - 64 - - - 64 - (math) + x="312.47507" + y="116.78596">(math) @@ -384,33 +347,9 @@ id="path3463" d="M 253.43097,494.08087 L 212.15366,395.97781" style="fill:#00ffff;fill-opacity:1;stroke:#000000;stroke-width:2;stroke-linecap:butt;marker-end:url(#Dot_m);stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" /> - - - AES - H + x="28.658957" + y="697.3609" /> crypttext + x="36.979286" + y="733.41571">crypttext + + + AES + readkey + + transform="translate(-56.39343,-19.414131)"> + x="355.92569" + y="984.87494" /> signature + x="369.79294" + y="1025.5521">signature FEC + x="52.695496" + y="795.35602">FEC Hmerkletrees write-cap + x="45.299637" + y="148.21837">write-cap - - + + + storage index + + + + 64 - 64 + SI:A + y="699.2099" + id="text3613" + sodipodi:linespacing="100%">SI:A + + + + 64 + SI:B + - SI:B + x="446.52499" + y="893.35114" /> verify cap + x="452.99637" + y="973.78113">verify cap H - H + x="599.06464" + y="612.30853">H H + x="210.782" + y="208.30971">H H + transform="matrix(0.6558602,0,0,0.6558602,330.02604,743.02541)"> + transform="matrix(0.7835586,0,0,0.7835586,139.00437,363.12432)"> : stored in share + H + + + deep-verify cap + + 192 + 64 + + + H + H + + + + AES + writekey + + + + + AES + deepverifykey + + H diff --git a/docs/mutable-DSA.txt b/docs/mutable-DSA.txt index 568f3db4..4875d874 100644 --- a/docs/mutable-DSA.txt +++ b/docs/mutable-DSA.txt @@ -128,9 +128,14 @@ The pubkey hash is hashed by itself and truncated to 64 bits to form the last write-cap. The first 192 bits of the read-cap are hashed and truncated to form the first -64 bits of the storage index. The last 64 bits of the read-cap are hashed to -form the last 64 bits of the storage index. This gives us a 128-bit storage -index. +192 bits of the "traversal cap". The last 64 bits of the read-cap are hashed +to form the last 64 bits of the traversal cap. This gives us a 256-bit +traversal cap. + +The first 192 bits of the traversal-cap are hashed and truncated to form the +first 64 bits of the storage index. The last 64 bits of the traversal-cap are +hashed to form the last 64 bits of the storage index. This gives us a 128-bit +storage index. The verification-cap is the first 64 bits of the storage index plus the pubkey hash, 320 bits total. The verification-cap doesn't need to be @@ -150,6 +155,10 @@ encrypt the actual file data. This is to avoid key-reuse. An outstanding issue is how to avoid key reuse when files are modified in place instead of being replaced completely; this is not done in SDMF but might occur in MDMF. +The master data encryption key is used to encrypt data that should be visible +to holders of a write-cap or a read-cap, but not to holders of a +traversal-cap. + The private key is hashed one way to form the salt, and a different way to form the "write enabler master". For each storage server on which a share is kept, the write enabler master is concatenated with the server's nodeid and @@ -163,6 +172,18 @@ be used by applications which wish to store some data in a form that is only available to those with a write-cap, and not to those with merely a read-cap. This is used to implement transitive read-onlyness of dirnodes. +The traversal cap is hashed to work the "traversal key", which can be used by +applications that wish to store data in a form that is available to holders +of a write-cap, read-cap, or traversal-cap. + +The idea is that dirnodes will store child write-caps under the writekey, +child names and read-caps under the read-key, and verify-caps (for files) or +deep-verify-caps (for directories) under the traversal key. This would give +the holder of a root deep-verify-cap the ability to create a verify manifest +for everything reachable from the root, but not the ability to see any +plaintext or filenames. This would make it easier to delegate filechecking +and repair to a not-fully-trusted agent. + The public key is stored on the servers, as is the encrypted salt, the (non-encrypted) data salt, the encrypted data, and a signature. The container records the write-enabler, but of course this is not visible to readers. To @@ -173,19 +194,20 @@ tree, the encoding parameters, and the encrypted salt. "R" itself covers the hash trees and the share data. The read-write URI is just the private key. The read-only URI is the read-cap -key. The verify-only URI contains the the pubkey hash and the first 64 bits -of the storage index. +key. The deep-verify URI is the traversal-cap. The verify-only URI contains +the the pubkey hash and the first 64 bits of the storage index. FMW:b2a(privatekey) FMR:b2a(readcap) + FMT:b2a(traversalcap) FMV:b2a(storageindex[:64])b2a(pubkey-hash) -Note that this allows the read-only and verify-only URIs to be derived from -the read-write URI without actually retrieving any data from the share, but -instead by regenerating the public key from the private one. Uses of the -read-only or verify-only caps must validate the public key against their -pubkey hash (or its derivative) the first time they retrieve the pubkey, -before trusting any signatures they see. +Note that this allows the read-only, deep-verify, and verify-only URIs to be +derived from the read-write URI without actually retrieving any data from the +share, but instead by regenerating the public key from the private one. Users +of the read-only, deep-verify, or verify-only caps must validate the public +key against their pubkey hash (or its derivative) the first time they +retrieve the pubkey, before trusting any signatures they see. The SDMF slot is allocated by sending a request to the storage server with a desired size, the storage index, and the write enabler for that server's