On Wed, Sep 19, 2012 at 11:23 AM, Brian Warner <span dir="ltr"><<a href="mailto:warner@lothar.com" target="_blank">warner@lothar.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">Note that we currently only apply the tree-hash to ciphertext. We used</div>
to build a plaintext hash tree too, but removed it because it enabled<br>
partial-information-guessing attacks, just like revealing a flat hash of<br>
the plaintext, but worse. We hope to reintroduce it safely, by uploading<br>
encrypted(plaintext-hash-tree) in addition to<br>
not-encrypted(ciphertext-hash-tree). This would let us detect failures<br>
in the last decryption step.)</blockquote><div><br></div><div>This sounds great! I was actually trying to avoid any kind of hash of the plaintext in my system, but that said, an encrypted hash used to detect bugs in the encryption protocol would definitely make sense.</div>

<div><br></div><div>I'd also like to say I'm extremely impressed with the Rainhill immutable file protocol design described here:</div><div><br></div><div><a href="https://tahoe-lafs.org/trac/tahoe-lafs/wiki/NewCaps/Rainhill">https://tahoe-lafs.org/trac/tahoe-lafs/wiki/NewCaps/Rainhill</a></div>

<div><br></div><div>One of the things I encountered using Tahoe was that to set up e.g. a cron job to do a deep check/repair of content, I would have to use the readcap. Separating "deep verify" from the readcap makes a whole lot of sense to me and I'm really glad to see work in this regard. I'd really like to have a dedicated "repair node" that can do a deep verify / repair without exposing the readcap.</div>

<div> </div></div>-- <br>Tony Arcieri<br><br>