search

vgough / encfs

EncFS: an Encrypted Filesystem for FUSE.
https://vgough.github.io/encfs/
Other
2.09k stars 279 forks source link

64-bit Initialization Vectors #16

Open lipnitsk opened 10 years ago

lipnitsk commented 10 years ago

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 commented 7 years ago

See: https://sweet32.info/

rfjakob commented 7 years ago

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 commented 7 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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.