On Mon, May 11, 2009 at 02:16:45PM -0400, Roland Dowdeswell wrote: > >In any case, there are obvious, well-understood solutions here: Use > >counter mode, which propagates changes by a single block of the > >cryptosystem. Or use any other stream cipher mode. (An interesting > >question is whether there's a mode that will recover from insertions > >or deletions. Perhaps something like: Use counter mode. If two > >consecutive ciphertext bytes are 0, fill the rest of the ciphertext > >block with 0's, jump the counter by 65536, and insert a special block > >containing the new counter value.) > > I'm not convinced that a stream cipher is appropriate here because > if you change the data then you'll reveal the plaintext.
Indeed. If the remote copy is a "backup", and the local file-system supports snaphots, then it is far better to arrange for the remote backup to always be a copy of a local snapshot, and to compute the rsync "delta" between the local copy of the remote snapshot and a newer snapshot locally, and then rsync the delta. Sure, snapshot file-systems are not yet universal, but given disk size and file-system trends, I would base encrypted remote backups on a foundation that assumed the existence of local before/after images. A cipher that produces largely identical cipher-text for largely identical plaintext in the face of updates, inserts and deletes, is unlikely to be particularly strong. The CBC IV reset should not be too disasterous if the IV is an encrypted block counter under a derived key. Drive encryption basically does the same thing with 512 byte blocks. This fails to handle inserts/deletes that are not multiples of the "chunk" size. -- Viktor. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com