[tahoe-dev] [tahoe-lafs] #723: helper: client should verify ciphertext hashes and UEB

[tahoe-lafs]

#723: helper: client should verify ciphertext hashes and UEB
---------------------------+------------------------------------------------
 Reporter:  warner         |           Owner:           
     Type:  defect         |          Status:  new      
 Priority:  major          |       Milestone:  undecided
Component:  code-encoding  |         Version:  1.4.1    
 Keywords:  helper         |   Launchpad_bug:           
---------------------------+------------------------------------------------
 Prompted by a question from David-Sarah Hopwood, I spent some time today
 reviewing the helper code, and realized that the client should be doing
 more verification of the data that the helper returns to it. Specifically,
 the client should:

  * locally compute the ciphertext hashes (flat and Merkle tree), in
 {{{upload.EncryptAnUploadable}}}
  * compare these against the versions returned by the helper, in
 {{{AssistedUploader._build_verifycap}}}
 {{{upload_results.uri_extension_data}}}
  * compute and compare the resulting UEB hash

 This would prevent the helper from causing an integrity violation. With
 the present behavior, the helper can flip bits in the ciphertext (or
 upload a completely unrelated ciphertext of the same length) and return
 the resulting ciphertext hash to the trusting client. Because the client
 doesn't perform any validation of the response, it will simply build and
 return the resulting filecap. Later, when someone attempts a download with
 this filecap, they will receive the altered ciphertext (but it will match
 the hash provided by the helper) and try to decrypt it. Since we removed
 the plaintext hashes in [2331],[2337],[2338],[3286], the downloader hash
 no way to check the plaintext either, and will return corrupted plaintext
 to the end user.

 With the current codebase, this won't be too much work. But when
 [http://allmydata.org/trac/pycryptopp/ticket/18 pycryptopp#18] (allow
 random-access AES-CTR encryption) is fixed, I'd like to improve the
 assisted-uploader code to be more efficient in the resumed-upload case (by
 not encrypting-then-discarding all the previously-uploaded data), at which
 point this locally-generate-hashes fix would become more difficult. Or
 rather, I might have to forego the resumed-upload improvement to retain
 the don't-rely-on-helper-for-integrity property that this ticket would
 provide.

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