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 _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
