[tahoe-dev] [tahoe-lafs] #684: let client specify the encryption key

[tahoe-lafs]

#684: let client specify the encryption key
---------------------------+------------------------------------------------
 Reporter:  zooko          |           Owner:            
     Type:  enhancement    |          Status:  new       
 Priority:  major          |       Milestone:  eventually
Component:  code-encoding  |         Version:  1.4.1     
 Keywords:                 |   Launchpad_bug:            
---------------------------+------------------------------------------------

Comment(by warner):

 Re-using a key (which is equivalent to re-using a storage-index) will
 probably cause the second file to get lost. The uploading code will ask
 the storage servers to accept a share for storage-index XYZ, the server
 will say "I already have a share for that", the uploader will say "oh, ok,
 I'll use the existing share instead", and the result will be that the
 uploader will construct a filecap that won't be downloadable, and the
 second file will be lost.

 Actually, in the current release, this depends upon whether any servers
 have been added since the first upload. If the first part of the permuted
 list is still the same, then the uploader will re-use the existing shares.
 If the uploader has a different peer list, then it might place new shares
 anyways, because our uploader code isn't very smart about avoiding
 duplicate shares yet (something that needs to improve to make the Repairer
 work better). In this case, you could wind up with some shares for the
 first version and some shares for the second version. In theory, both
 versions might wind up being downloadable: someone using the first filecap
 would see good shares and corrupt shares, someone using the second filecap
 would see corrupt shares and good shares. The wrinkle is that the
 downloader is not yet clever enough to switch to good shares once it sees
 corruption, so the most likely effect would be both versions getting bad-
 hash errors on download.

 Eventually, the uploader code needs to be improved: if a server claims to
 have a share, the uploader should check to see that the share looks
 usable. The simplest check is to compare file lengths at the start of
 upload and UEB hashes at the end of upload; a more complete check would be
 to download the whole share and compare it to the one being generated, or
 challenge the server to return a keyed hash of the share and do the same
 comparison.

 But yeah, in any case, it becomes important for the uploader to avoid re-
 using an encryption key. At best it will cause confusion.

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/684#comment:2>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid