ExternalVendorCode/tahoe-lafs
1
0
Fork 0
mirror of https://github.com/tahoe-lafs/tahoe-lafs.git synced 2024-12-19 13:07:56 +00:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

docs/mutable.txt: add IV, define a place for it in the data structure

Browse Source
This commit is contained in:
Brian Warner 2007-10-29 19:51:12 -07:00
parent 5491339912
commit 9b92bff51c
1 changed files with 20 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
docs/mutable.txt
View File

@ -114,7 +114,14 @@ the "write enabler" for that particular server.
The private key is encrypted (using AES in counter mode) by the write key, The private key is encrypted (using AES in counter mode) by the write key,
and the resulting crypttext is stored on the servers. so it will be and the resulting crypttext is stored on the servers. so it will be
retrievable by anyone who knows the write key. retrievable by anyone who knows the write key. The write key is not used to
encrypt anything else, and the private key never changes, so we do not need
an IV for this purpose.
The actual data is encrypted (using AES in counter mode) with a key derived
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
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 just the write key. The read-only URI contains
the read key and the verification key hash. the read key and the verification key hash.
@ -344,17 +351,19 @@ is oblivious to this format.
43 8 segment size 43 8 segment size
51 8 data length 51 8 data length
5 59 32 offset table: 5 59 32 offset table:
91 4 (6) signature 91 4 (7) signature
95 4 (7) share hash chain 95 4 (8) share hash chain
99 4 (8) block hash tree 99 4 (9) block hash tree
103 4 (9) share data 103 4 (10) IV
107 8 (10) encrypted private key 107 4 (11) share data
6 115 256 verification key (2048 RSA key 'n' value, e=3) 111 8 (12) encrypted private key
7 371 256 signature= RSAenc(sig-key, H(version+seqnum+r+encparm)) 6 119 256 verification key (2048 RSA key 'n' value, e=3)
8 627 (a) share hash chain 7 375 256 signature= RSAenc(sig-key, H(version+seqnum+r+encparm))
8 631 (a) share hash chain
9 ?? (b) block hash tree 9 ?? (b) block hash tree
10 ?? LEN share data 10 ?? 16 IV (share data is AES(H(readkey+IV)) )
11 ?? 256 encrypted private key= AESenc(write-key, RSA 'd' value) 11 ?? LEN share data
12 ?? 256 encrypted private key= AESenc(write-key, RSA 'd' value)
(a) The share hash chain contains ceil(log(N)) hashes, each 32 bytes long. (a) The share hash chain contains ceil(log(N)) hashes, each 32 bytes long.
This is the set of hashes necessary to validate this share's leaf in the This is the set of hashes necessary to validate this share's leaf in the
@ -484,9 +493,6 @@ provides explicit support for revision identifiers and branching.
== TODO == == TODO ==
add IV, use it by hashing the long-term readkey with the IV to generate the
per-version readkey.
improve allocate-and-write or get-writer-buckets API to allow one-call (or improve allocate-and-write or get-writer-buckets API to allow one-call (or
maybe two-call) updates. The challenge is in figuring out which shares are on maybe two-call) updates. The challenge is in figuring out which shares are on
which machines. First cut will have lots of round trips. which machines. First cut will have lots of round trips.