To handle smaller inserts or deletes, you need to ensure that the underlying blocks "get back into sync". The gzip technique I mentioned earlier works. Keep a running cryptographically secure checksum over the last blocksize bytes. When some condition on the checksum is met - equals 0 mod M - insert filler to the beginning of the next block before encrypting; discard to the beginning of the next block when decrypting. Logically, this is dividing the file up into segments whose ends occur at runs of blocksize bytes that give a checksum obeying the condition. A change within a segment can at most destroy that segment and the following one; any other segments eventually match up.
Oh, feh. I'm typing without thinking. In the worst case, an insertion (deletion) of K bytes could create (delete) K/M new (existing) segments. In practice, this is unlikely except in an adversarial situation, and all it can do is force extra data to be transferred.
                                                        -- Jerry

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to

Reply via email to