Warning! New cryptographic modes!

[Victor Duchovni]

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 majordomo at metzdowd.com