64-bit Initialization Vectors

[lipnitsk]

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

Initialization vectors are only 64 bits, even when using AES instead of Blowfish. This may lead to vulnerabilities when encrypting large (or lots of) files.

[paragonie-scott]

See: https://sweet32.info/

[rfjakob]

Interesting article, but I am not sure it applies here, as encfs uses a 128-block cipher (aes) with a 64 bit initialization vector.

[paragonie-scott]

Birthday collisions on a 64-bit input will happen after 2^32 outputs (50% probability).

Try encrypting a terabyte with EncFS and see if you get an IV collision.

[benrubson]

Configuration file already contains :
<uniqueIV>0</uniqueIV>
I think we could make this an int rather than a boolean, without breaking compatibility.
As for blockMACBytes (see #13), it would then contain 16 for new filesystems 👍

[benrubson]

Do you think we can safely use an unsigned __int128 value to store 128 bits IVs ?
Or we should better use 2 64 bits values and concat them ?

I'm afraid 128 bits values could not be supported on 32 bits systems, this is at least the case on Cygwin 32 bits (g++/gcc 6.4.0) where the following test fails :

int main()
{
    unsigned __int128 test;
    return 0;
}

expected unqualified-id before « __int128 »

[rfjakob]

Some googling seems to confirm that. uint128 is not available everywhere. We should rather use 2 x uint64 or 16 x uint8 I believe.

[benrubson]

So I think we would have to declare a new struct containing the 2 uint64, or pass them as 2 args to the functions needing them.
The 2 mainly impacted files are CipherFileIO and SSL_Cipher.