Ben RUBSON

_(https://github.com/WayneD/rsync/commit/01b9bbb0f94e4ddd4b1e3ad678b220ca09bc0ad0 which solves a more or less "similar" issue does not help here)_

> could you please clarify which commit introduced the fix and which option is used to workaround this issue? When you configure encfs in expert mode : ``` Add random...

This is the most "important" EncFS security report. > By padding the plaintext with 16 zero bytes, that problem goes away, at the cost of wasting 16 bytes. I think...

I'll see if I can work on this later on :) I'm also wondering if such a modification would be reverse-write compatible. > By padding the plaintext with 16 zero...

I then tried to implement the `cipherBlockSize - 1` padding (15 bytes in examples below), according to what you described above @rfjakob, adding 15 bytes at the end of each...

I think I will go with [OneAndZeroes padding](https://www.di-mgt.com.au/cryptopad.html) of each block, with a `cipherBlockSize - 1` bytes padding for the last block. We would then still be able to get...

Thx for your feedbacks @rfjakob 👍 I agree if the cipher file is fully available locally. You may be in a situation where the cipher file would not be locally...

It would, because then here you encode data, so you don't expect it to be a multiple of `cipherBlockSize`. If the block you are writing is at the end of...

Unfortunately this would not help. Let's assume we receive a 4KB (`blockSize`) cipher block. According to the write call received, we have to write it as the end of the...

Not necessarily. Think about a cipher file being dowloaded directly into a reverse-write EncFS (so that it is written decrypted directly to the local disk). Every block received and written...