[tahoe-dev] how to encrypt and integrity-check with only one value [correction]

[David-Sarah Hopwood]

David-Sarah Hopwood wrote:
> David-Sarah Hopwood wrote:
>>  - If the encryption used to produce k_enc is not an authenticated
>>    encryption scheme, then an attacker can potentially modify k_enc,
>>    and now an incorrect key k will be used for the decryption
>>    (possibly one that is related to the correct key). This means
>>    that an incorrect plaintext will be produced and accepted,
>>    assuming that the main encryption algorithm is also not
>>    authenticated. The check that r = H(k, v) will not catch this
>>    since it only verifies the ciphertext.
> 
> Sorry, I'm talking nonsense. The incorrect k *will* be caught by the
> check on H(k, v).
> 
> OTOH, that depends on there being no interaction between the k_enc
> encryption and the hash. So it does seem as though a security proof
> may be easier if the k_enc encryption is authenticated.

I'm still wrong. The only assumptions needed on the hash are fairly
standard ones, and there are no unusual requirements for the k_enc
encryption. In the case where the attacker does not know r, the check on
H(k, v) requires only 2nd preimage resistance from the hash. Also, it is
required that when k is generated randomly, H(k, v) produces a suitable
key for the k_enc encryption -- but plenty of protocols use hashes in
that way. I was being unnecessarily paranoid in my original reply to
Zooko.

The comment about the verify cap needing to be an encoding of
(v, k_enc) was correct, though.


Given that for mutable files, a read cap can be a hash of a public key
that is stored with the signature, it seems like we now have all the
protocols needed to design new Tahoe URL schemes that are much shorter
(and about time, lest Zooko break under the strain of insults about
his blog URL ;-)

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com