Bugzilla Bug 168750

Here's the story.  My system crashed this morning.  After rebooting and
fsck'ing, one of my two encfs directories would not mount.  It kept giving me a
"incorrect password" error even though I've been using the same password for
nearly two years.  The other encfs directory (different fs and password)
mounted fine.  The one in question was created in 2005 and I've never changed
the password.  The .encfs5 file still has a 2005-04-15 timestamp.  The
directory that does work was created on 2006-11-25.

After tearing my hair out with different kernels, restoring from backups, and
even downgrading encfs, I suddenly remembered that yesterday I had upgraded
OpenSSL to 0.9.8e.  I performed the revdep-rebuilds as per the .ebuild info but
I still had this problem.  Re-emerging and even downgrading encfs after the
openssl upgrade does not resolve the issue.  The only way I am able to mount
the encfs volume is to downgrade openssl to 0.9.8e and re-emerge encfs.

I've already send an email upstream for Mr. Gough, however I think it might be
a good thing to inform the users that there may potentially be problems
mounting encfs directories with the new OpenSSL.

I made the severity "major" as the error generated gives the (false) impression
of permanent data loss.

you say you upgraded to 0.9.8e but then downgrading to 0.9.8e fixed things ...
which is the typo and which is correct ? ;)

Should have read "The only way I am able to mount
the encfs volume is to downgrade openssl to 0.9.8d and re-emerge encfs."

I received a response from Valient Gough and am pasting my response to his
response.

---
Valient,

First of all thanks for your response.  I was able to get some more clues. 
Hopefully this will make some sense to you:

What might 
> help me understand it is if you try mounting the one it doesn't work on but 
> add in the encfs flags "-v" and "-f" ( to turn on verbose logging and output 
> to stdout).  Send me a copy of that output.
> 
> 
Ok, here's what I got when using OpenSSL 0.9.8d on the non-functioning
directory:

19:40:40 (main.cpp:642) Root directory: /home/marduk/.Documents/
19:40:40 (main.cpp:643) Fuse arguments: (fg) (threaded) (keyCheck) encfs
/home/marduk/Documents -f -s -o use_ino -o default_permissions
19:40:40 (Interface.cpp:165) checking if ssl/aes(2:1:1) implements
ssl/blowfish(2:1:1)
19:40:40 (Interface.cpp:165) checking if ssl/blowfish(2:1:1) implements
ssl/blowfish(2:1:1)
19:40:40 (SSL_Cipher.cpp:322) allocated cipher ssl/blowfish, keySize 20,
ivlength 8
19:40:40 (FileUtils.cpp:1298) useStdin: 0
EncFS Password:
19:40:58 (FileUtils.cpp:1309) configuration key size = 32
19:40:58 (FileUtils.cpp:1310) cipher key size = 32
19:40:58 (SSL_Cipher.cpp:517) checksum mismatch: expected 3510222754, got
2059035396
19:40:58 (SSL_Cipher.cpp:518) on decode of 28 bytes
Error decoding volume key, password incorrect

The "checksum mismatch" line is interesting...


The other thing that might be helpful is to know the configuration of the two 
> filesystems (output from 'encfsctl info [path]').
> 
encfsctl info using OpenSSL 0.9.8d on the non-functioning directory:

Version 5 configuration; created by EncFS 1.2.0 (revision 20040813)
Filesystem cipher: "ssl/blowfish", version 2:1:1
Filename encoding: "nameio/block", version 3:0:1
Key Size: 160 bits
Block Size: 512 bytes
Each file contains 8 byte header with unique IV data.
Filenames encoded using IV chaining mode.

And here's the same on the functioning directory:

Version 5 configuration; created by EncFS 1.3.1 (revision 20040813)
Filesystem cipher: "ssl/aes", version 2:1:1
Filename encoding: "nameio/block", version 3:0:1
Key Size: 256 bits
Block Size: 512 bytes, including 8 byte MAC header
Each file contains 8 byte header with unique IV data.
Filenames encoded using IV chaining mode.
File data IV is chained to filename IV.

I do notice that the non-functioning one is using the blowfish cipher whereas
the functioning one uses AES.


> I'm not sure offhand what could have changed, but I've tried to maintain 
> backward compatibility in encfs by keeping old algorithms around as options 
> even if new ones are added.  Very old versions of encfs used OpenSSL's key 
> generation mechanism, which may no longer be backward compatibile (Encfs has 
> been using a new method for a long time, but only on new filesystems).
> 
> I'd create a new filesystem and copy the data over.  You probably don't even 
> need to run two versions of encfs - just creating a new filesystem is 
> probably enough.
> 
I've done exactly that.  What I did is use OpenSSL 0.9.8d to create a brand new
encfs volume.  I used the 'x'pert mode and chose the blowfish cipher because I
wanted to test using the same cipher as the original.  Then I copied all the
files (1.1G) from the original to the new encfs fs.  Then I upgraded to OpenSSL
0.9.8e, recompiled encfs and attempted to mount the new volume.  Again, I could
not mount the volume: "password incorrect."

What I did next was downgrade back to OpenSSL 0.9.8d.  This time I created a
the volume, but instead of using 'x'pert mode and choosing blowfish, I chose
the 'p'aranoid mode, which uses aes.  I then copied the files into the
aes-encrypted volume.  Then I upgraded to OpenSSL 0.9.8e, recompiled encfs and
then attempted to mount the third volume.  It mounted successfully.

So possibly could there be a compatibility issue with OpenSSL 0.9.8e and the
blowfish cipher?

-m

I also noticed strange thing after upgrading openssl to 0.9.8e and re-emerging
openssh. While trying to connect from up2date-FC6 to ssh:
: debug1: Installing crc compensation attack detector.
: Disconnecting: Corrupted check bytes on input.
No problem connecting with putty from win machine.

net-misc/openssh-4.5_p1-r1  USE="X hpn pam -X509 -chroot -kerberos -ldap
-libedit (-selinux) -skey -smartcard -static -tcpd"
dev-libs/openssl-0.9.8e  USE="emacs zlib -bindist -sse2 -test"

back to openssl-0.9.8d fixed the issue.

i have now issues with connecting to the gentoo box from the win machine
using putty - garbled input received.

it only happens if AES is chosen as a first encryption chosen,
works fine with blowfish.

(In reply to comment #4)
> I do notice that the non-functioning one is using the blowfish cipher whereas
> the functioning one uses AES.
[snip]
> So possibly could there be a compatibility issue with OpenSSL 0.9.8e and the
> blowfish cipher?

I have seen evidence of this, too.  I'm using openvpn, configured for BF-CBC
using 448-bit keys.  Hosts with openssl 0.9.8d cannot talk to openssl 0.9.8e,
it logs the message "Authenticate/Decrypt packet error: cipher final failed".

Either upgrading everyone on the network to 0.9.8e, or downgrading everyone to
0.9.8d, results in successful connections all around.  Strangely, on a
different network, both 0.9.8d and 0.9.8e can talk to a server running 0.9.7e-3
(on an old Debian box), but that network uses 128-bit keys.  I don't know if
the key size is related.

Mark

(In reply to comment #6)
> i have now issues with connecting to the gentoo box from the win machine
> using putty - garbled input received.
> 
> it only happens if AES is chosen as a first encryption chosen,
> works fine with blowfish.

i'm seeing the same problem, putty/windows is unable to connect to an openssh
4.5 after having upgraded openssl to 0.9.8e, both sides of the connection
complain about bad packet size and/or garbage bytes. however it only happens
with AES, forcing blowfish still works. openssh's own client connects fine with
AES. was there some change in the AES code maybe?

Known bug in openssl 0.9.8e

http://bugzilla.mindrot.org/show_bug.cgi?id=1291

The openssl is already fixed for a while, could You forge a new release for
gentoo as well.

you're assuming ive been following the openssl mailing list/cvs tree and know
the exact changes required ... both of which would be false assumptions

post a diff from upstream cvs and i'll merge it

according to the encfs mailing list, this URL should be the patch to fix it:

http://cvs.openssl.org/chngview?cn=15978




source:

http://www.mail-archive.com/openssl-users%40openssl.org/msg48678.html


http://arg0.net/wiki/encfs

"Warning: Do not use OpenSSL 0.9.8e - it has a bug in its blowfish encryption
handling which makes it incompatible with past and future versions of OpenSSL."

Is the patch going to be merged soon?  I have the same problem, but when I
downgrade openssl back to 0.9.8d, portage breaks down and I am unable to
re-merge everything (luckily I keep binpkg's).

So right now I'm stuck with 0.9.8e...

I can confirm that (In reply to comment #12)
> according to the encfs mailing list, this URL should be the patch to fix it:
> 
> http://cvs.openssl.org/chngview?cn=15978
> 
> 
> 
> 
> source:
> 
> http://www.mail-archive.com/openssl-users%40openssl.org/msg48678.html
> 
> 
> http://arg0.net/wiki/encfs
> 
> "Warning: Do not use OpenSSL 0.9.8e - it has a bug in its blowfish encryption
> handling which makes it incompatible with past and future versions of OpenSSL."
> 

I can confirm that this patch works on my i686 system.

Created an attachment (id=121938) [edit]
patch from the above site

Created an attachment (id=121940) [edit]
New ebuild

Just added that one line for the patch.

added to 0.9.8e-r1, cheers

*** Bug 168851 has been marked as a duplicate of this bug. ***