[tahoe-dev] Choice of tree-hash

[David-Sarah Hopwood]

On 24/09/12 22:40, Tony Arcieri wrote:
> On Mon, Sep 24, 2012 at 1:35 PM, David-Sarah Hopwood <david-sarah at jacaranda.org
> <mailto:david-sarah at jacaranda.org>> wrote:
> 
>     Integrity checking using a hash of the ciphertext relies on the decryption being
>     correct.
> 
> I'm a bit confused by this: if the decryption is incorrect, hasn't integrity been violated?

No, if the error is detected.

Integrity means that the system will never retrieve an incorrect plaintext, not that it
will always retrieve a correct one.

> Is the goal to detect a bad decrypt (due to software bugs) versus transmission/storage
> error?

Yes. The current ciphertext hashes will detect transmission and storage errors.

The end-to-end hash supported by browsers would also detect transmission errors between
the gateway and browser. We could potentially have the CLI commands do that plaintext
check. (It would require sending an extra hash per block if we want to do the check
incrementally for a streaming download.)

>     The current Tahoe design allows random keys. It doesn't require any extra field in the
>     capability. There's just no UI to enable it at the moment.
> 
> Would you use an authenticated encryption mode in this case? I am relying on
> HKDF(plaintext, IV || empty string) as my "MAC" to determine the authenticity of content.

Whether to use authenticated encryption vs hashing is independent of whether keys are
random or convergent.

-- 
David-Sarah Hopwood ⚥

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20120925/73d44110/attachment.pgp>