[tahoe-dev] how to encrypt and integrity-check with only one value (was: Re: two reasons not to use semi-private keys in our new cap design)

[David-Sarah Hopwood]

Zooko Wilcox-O'Hearn wrote:
> So here is my idea to use a single value to accomplish both decryption
> and integrity checking even when you can't set the symmetric key to be
> the secure hash of the plaintext.  You use the encryption key k to
> encrypt the plaintext to produce the ciphertext, and in the same pass
> you compute the integrity-check value v.  Then you compute the secure
> hash of the combination of k and v, let's call the result r = H(k, v). 
> Then you encrypt k using r and store the encrypted k with the
> ciphertext.  Now r is the real key -- the read cap.  If someone gives
> you r, the ciphertext, and the encrypted k, then you first use r to
> decrypt k, check that r = H(k, v), then perform the decryption and
> integrity-checking of the ciphertext.

I like this a lot; I think it's basically a good idea.

Some security analysis:

 - The diagram shows v as being the verify cap, but v is not
   sufficient to check that all the information needed to read the
   file is present, since it does not cover the encrypted k. The
   simplest change that would fix this is to make the verify cap
   an encoding of (v, k_enc).

   (v cannot depend on k_enc in order to reduce the size of
   the verify cap, since that would create a circular dependency.
   But arguably it is more important to make read caps small than
   verify caps.)

 - 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.

   With authenticated encryption for k_enc, a proof of the integrity
   property (i.e. given a read-cap, only one plaintext will be
   accepted) against an attacker without the read cap seems
   straightfoward: the decrypted k is correct assuming security of
   the authenticated encryption, and only one possible ciphertext
   will be accepted assuming 2nd preimage resistance of the hash
   (twice), so there is only one acceptable plaintext. This does not
   depend on the main encryption being authenticated.

Nitpick: the diagram uses "K1" for the encryption key and
"k" for the security parameter, whereas your post used "k" for
the key.

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