[tahoe-lafs-trac-stream] [tahoe-lafs] #393: mutable: implement MDMF

[tahoe-lafs]

#393: mutable: implement MDMF
-------------------------+-------------------------------------------------
     Reporter:  warner   |      Owner:  kevan
         Type:           |     Status:  assigned
  enhancement            |  Milestone:  1.9.0
     Priority:  major    |    Version:  1.0.0
    Component:  code-    |   Keywords:  newcaps performance random-access
  mutable                |  privacy gsoc mdmf mutable backward-
   Resolution:           |  compatibility forward-compatibility review-
Launchpad Bug:           |  needed
-------------------------+-------------------------------------------------

Comment (by kevan):

 attachment:393status46.dpatch sets tighter bounds on signature key,
 verification key, share hash chain and signature size, fixes a bug I found
 in situations where {{{n = k}}} (and adds a test for that bug), resolves
 the conflict with trunk identified by davidsarah, fixes a test from #1304
 that breaks when run against MDMF, and adds tests to ensure that the new
 downloader can handle old SDMF shares. I've also performed other
 interoperability testing between the old and new mutable file code,
 confirming that the old downloader can read SDMF files written by the new
 publisher, that the new downloader can read files published by the new
 publisher and modified by the old code, and that the old downloader can
 read files modified by the new publisher.

 warner: During one of the first phonecalls, you mentioned that you were
 worried that the update process could fetch more data than necessary to
 update a segment near the end of the file, I think. My notes on that issue
 are sketchy; could you elaborate on your concerns there, if you remember
 what they are?

 The signature, verification key, and signing key bounds are kind of iffy,
 in that they come from simulation (repeating the key generation and
 signature operations as the publisher would perform them thousands of
 times and observing the size of the output) rather than something more
 concrete (e.g., a property of the cryptosystem, or something in cryptopp
 that we don't think will change). Unfortunately, I haven't had time to dig
 deeply into the issue to find more reassuring explanations for those
 bounds yet. I'll probably have some time over the next week for that, but
 if someone else wants to give it a try in the meantime, feel free.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/393#comment:99>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage