[tahoe-dev] Choice of tree-hash

[David-Sarah Hopwood]

On 25/09/12 07:33, David-Sarah Hopwood wrote:
> 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.

... between the servers and gateway, I meant to say.

> 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/81ca1a04/attachment.pgp>