Information Leakage Between Decryption and MAC Check

[lipnitsk]

From: https://defuse.ca/audits/encfs.htm

EncFS uses Mac-then-Encrypt. Therefore it is possible for any processing done on the decrypted plaintext before the MAC is checked to leak information about it, in a style similar to a padding oracle vulnerability. EncFS doesn't use padding, but the MAC code does iteratively check if the entire block is zero, so the number of leading zero bytes in the plaintext is leaked by the execution time.

[rianhunter]

Can you describe the specific attack in more detail? From what I can tell, If the attacker can cause EncFS to process data, then they already have access to the data they are trying to compromise.

[jetwhiz]

I think switching to an Encrypt-then-MAC setup would fix this issue, but could introduce new issues if not done correctly.

By switching to Galois/Counter Mode, though, we would fix not only this issue, but also audit issues 2.1 (Same Key Used for Encryption and Authentication #8) and 2.3 (Generating Block IV by XORing Block Number #10) as well. We would have to ensure IV's can never be repeated, however.

This could be done using openssl (https://www.openssl.org/docs/manmaster/crypto/EVP_EncryptInit.html#GCM-and-OCB-Modes) or we can wait until we switch to libgcrypt to implement this. Note that I believe Blowfish will not work with GCM (since it does not have a 128-bit block size).