ExternalVendorCode/tahoe-lafs
1
0
Fork 0
mirror of https://github.com/tahoe-lafs/tahoe-lafs.git synced 2025-05-02 00:53:01 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

docs/mutable.txt: put fingerprint in read-write URI too, it makes everything easier

Browse Source
This commit is contained in:
Brian Warner 2007-10-31 16:30:15 -07:00
parent bcf84c1238
commit 715a3268cd
1 changed files with 24 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
docs/mutable.txt
View File

@ -99,13 +99,12 @@ encrypted child names to rw-URI/ro-URI pairs.
Each SDMF slot is created with a public/private key pair. The public key is Each SDMF slot is created with a public/private key pair. The public key is
known as the "verification key", while the private key is called the known as the "verification key", while the private key is called the
"signature key". The private key and public key are concatenated and the "signature key". The private key is hashed to form the "write key" (an AES
result is hashed to form the "write key" (an AES symmetric key). The write symmetric key). The write key is then hashed to form the "read key". The read
key is then hashed to form the "read key". The read key is hashed to form the key is hashed to form the "storage index" (a unique string used as an index
"storage index" (a unique string used as an index to locate stored data). to locate stored data).
The public key is hashed by itself to form the "verification key hash". The The public key is hashed by itself to form the "verification key hash".
private key is encrypted
The write key is hashed a different way to form the "write enabler master". The write key is hashed a different way to form the "write enabler master".
For each storage server on which a share is kept, the write enabler master is For each storage server on which a share is kept, the write enabler master is
@ -126,8 +125,19 @@ by concatenating the readkey with the IV, the hashing the results and
truncating to 16 bytes. The IV is randomly generated each time the slot is truncating to 16 bytes. The IV is randomly generated each time the slot is
updated, and stored next to the encrypted data. updated, and stored next to the encrypted data.
The read-write URI consists of just the write key. The read-only URI contains The read-write URI consists of the write key and the verification key hash.
the read key and the verification key hash. The read-only URI contains the read key and the verification key hash. The
verify-only URI contains the storage index and the verification key hash.
URI:SSK-RW:b2a(writekey):b2a(verification_key_hash)
URI:SSK-RO:b2a(readkey):b2a(verification_key_hash)
URI:SSK-Verify:b2a(storage_index):b2a(verification_key_hash)
Note that this allows the read-only and verify-only URIs to be derived from
the read-write URI without actually retrieving the public keys. Also note
that it means the read-write agent must validate both the private key and the
public key when they are first fetched. All users validate the public key in
exactly the same way.
The SDMF slot is allocated by sending a request to the storage server with a 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 desired size, the storage index, and the write enabler for that server's
@ -150,6 +160,7 @@ pieces are:
* the signature key, encrypted with the write key * the signature key, encrypted with the write key
The access pattern for read is: The access pattern for read is:
* hash read-key to get storage index
* use storage index to locate 'k' shares with identical 'R' values * use storage index to locate 'k' shares with identical 'R' values
* either get one share, read 'k' from it, then read k-1 shares * either get one share, read 'k' from it, then read k-1 shares
* or read, say, 5 shares, discover k, either get more or be finished * or read, say, 5 shares, discover k, either get more or be finished
@ -166,12 +177,15 @@ The access pattern for read is:
* submit plaintext to application * submit plaintext to application
The access pattern for write is: The access pattern for write is:
* hash write-key to get read-key, hash read-key to get storage index
* use the storage index to locate at least one share * use the storage index to locate at least one share
* read verification key and encrypted signature key * read verification key and encrypted signature key
* decrypt signature key using write-key * decrypt signature key using write-key
* concatenate signature and verification keys, compare against write-key * hash signature key, compare against write-key
* hash verification key to form read-key * hash verification key, compare against verification key hash
* encrypt plaintext from application with read-key * encrypt plaintext from application with read-key
* application can encrypt some data with the write-key to make it only
available to writers (use this for transitive read-onlyness of dirnodes)
* erasure-code crypttext to form shares * erasure-code crypttext to form shares
* split shares into blocks * split shares into blocks
* compute Merkle tree of blocks, giving root "r" for each share * compute Merkle tree of blocks, giving root "r" for each share