Score:2

Crypto

Does reusing IV in AES-CBC weaken it?

Kryštof Vosyka

11/15/22, 9:30 AM

Rsynccrypto allegedly uses AES-CBC with a twist: If the last few bytes of plaintext meet a condition*, then stop, pad the current block and start encrypting new block from the current position in file while reusing the IV. Better example might be in pseudocode:

if (trigger(buffer, i)) {
  encrypt_next_block(buffer, i);
  init_encryption(iv);
} else if(is_block_boundary(i)) {
  encrypt_next_block(buffer, i)
}

You can check the code here

Does that weaken the encryption somehow? If so, how?

* The exact condition is sum of the last 8196 bytes mod 4096 equals 0.

194

2 + 0

encryption

aes

cbc

Score:3

Crypto

Mikero

11/21/22, 1:17 AM

We don't even have to carefully analyze its variant of CBC mode. The webpage for rsyncrypto says it all:

This modification ensures that two almost identical files, such as the same file before an after a change, when encrypted using rsyncrypto and the same key, will produce almost identical encrypted files

Whatever they are doing (reusing IVs, etc), and assuming they actually succeed at their stated goals, they clearly leak some similarity information about plaintexts. So: yes, they weaken CBC mode, which doesn't leak anything about the plaintexts (except length) when used correctly.

About their specific variant of CBC: CBC maintains a chaining value from block to block. Initially the chaining value is set to the IV, and for subsequent blocks the chaining value is the ciphertext block. Apparently when a certain condition is satisfies, they reset the chaining value to the original IV.

It is well-known that reusing an IV in CBC mode leaks the length of a common prefix of plaintexts. In other words, if the first $k$ blocks of $M$ and $M'$ are identical, then the first $k$ blocks of $\textsf{CBC}_k(IV,M)$ and $\textsf{CBC}_k(IV,M')$ will be identical. It is possible to show that this is the only information about the plaintexts that is leaked. (This is assuming random IVs; more can be leaked if the adversary can predict/choose IVs).

The same reasoning applies to this CBC variant. Assuming the IV is used only for one encryption (but the chaining value may be reset to that IV during that encryption), ciphertexts leak the common prefix after any of these "IV-reset" steps. So, an eavesdropper who views a ciphertext and sees that blocks 12,13,14 equal blocks 22,23,24 can conclude that plaintext blocks 11 and 21 must have caused an IV reset, and that additionally plaintext blocks 12,13,14 equal plaintext blocks 22,23,24.

0 + 2

Kryštof Vosyka

11/21/22, 7:17 AM

I edited the question to provide more clarity.

Mikero

11/21/22, 4:57 PM

I updated my response.

Score:0

Crypto

DannyNiu

11/15/22, 11:04 AM

Maybe it's actually not snake-oil, but at best it's redundant.

The first part of its detail that I'd call redundant is the fact that it uses RSA to encrypt a per-file key that they for some reason call "session" key.

There is I believe a mode of operation of block cipher that's rsync-friendly, and it's the XTS disk encryption mode. Yes, if you can encrypt a block device and have live read-write access to individual blocks, there's no reason the same technology can't be applied to file segments.

0 + 1

Kryštof Vosyka

11/15/22, 12:44 PM

There actually is, if the data isn't offset by whole block, it's no longer rsync friendly. It at least that's how I understand it.