encfs-users — EncFS filesystem users

Re: [Encfs-users] System hangs while mounting enfs

[Blumenthal, U. - 0. - M. <ur...@ll...>]

Well, the code seems to be working fine for most cases. But it's rather concerning that the main repo seems abandoned.

Perhaps we can maintain fork(s)?
--
V/R,
Uri
 
There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
                                                                                                                                     -  C. A. R. Hoare
 

On 9/22/22, 17:20, "Joe Pfeiffer" <jo...@pf...> wrote:

    I'm sorry to say after looking at https://github.com/vgough/encfs and
    especially the Status description on that page, I've reluctantly
    started transitioning to ecryptfs.
    -- 
    Joe Pfeiffer
    1440 Tierra del Sol Dr
    Las Cruces, NM 88007-5548
    575.496.3501 (C)


    _______________________________________________
    Encfs-users mailing list
    Enc...@li...
    https://lists.sourceforge.net/lists/listinfo/encfs-users

Re: [Encfs-users] System hangs while mounting enfs

[Joe P. <jo...@pf...>]

I'm sorry to say after looking at https://github.com/vgough/encfs and
especially the Status description on that page, I've reluctantly
started transitioning to ecryptfs.
-- 
Joe Pfeiffer
1440 Tierra del Sol Dr
Las Cruces, NM 88007-5548
575.496.3501 (C)

[Encfs-users] System hangs while mounting enfs

[Ratheendran R <rat...@gm...>]

Hi,

We are chosen encfs(v1.9.5) to encrypt the data in the file, on system
boots up the I mount the folder containing the encrypted files, decrypt and
consumed subsequently.
The mount command is run using init scripts and is as below.

   (echo 1234 )| encfs -S /firmware/encrypt/  /tmp/decrypt/


This has been working up until now, but on one of the new boards, it just
hangs and system is not usable.I used the strace with the enfs command with
logs redirect to debug console In this case, the system starts up, but if
this is diverted to a null device, the system hangs. I already send a
good amount of time debugging this issue and reached nowhere, I need your
help to resolve this issue.

Thanks,
Ratheendran

Re: [Encfs-users] Secrecy Proposal

[Blumenthal, U. - 0. - M. <ur...@ll...>]

Sure. Will do.

See you on the Github! :)

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Sebastian Messmer
Sent: Tuesday, February 9, 2016 12:01
To: Blumenthal, Uri - 0553 - MITLL; enc...@li...
Subject: Re: [Encfs-users] Secrecy Proposal

Hi,

most of CryFS was developed after the thesis was finished.
It was developed as an open source project with users in mind, it is not 
meant as a proof-of-concept for the thesis.

I agree there are still issues, CryFS is not stable yet. For example, 
the build system has to be switched.
I propose we move the conversation from this mailing list to GitHub. 
Please feel free to open issues for things you don't like and we can 
discuss possible solutions there.

Best,
Sebastian

On 09.02.2016 16:43, Blumenthal, Uri - 0553 - MITLL wrote:
>> thanks for your feedback. Building CryFS on Mac OS X is currently not
>> supported unfortunately.
>> Maybe I should've said that clearer from the beginning, I'm sorry this
>> got you so frustrated.
> Thank you for the explanation. It confirms my assessment:
>
> - The idea and the filesystem architecture are interesting, well-suited
> for MS or better.
>
> - The implementation is fine to mark a checkbox in thesis defense (“yes it
> can work - here’s the proof”), but unsuitable for field deployment without
> significant efforts and possibly re-design.
>
>> Btw most users won't ever build CryFS themselves
> We differ here. But I guess, “the market” will decide.
>
>
>> - there are Debian
>> packages already, and in future there will also be RPM and (once
>> supported) Mac OS X installers.
> Sure, fine.
>
>
>> On 09.02.2016 05:43, Blumenthal, Uri - 0553 - MITLL wrote:
>>>>> OK, I got the code and took a brief look. First impression: it looks
>>>>> like an exercise in “how many different and complex packages I can tie
>>>>> together without crashing the whole thing”. Fragility of such approach
>>>>> are too numerous to list. …………
>>>> When I started the project, I was trying out a new buildsystem called
>>>> biicode with a new approach to dependency management.
>>> Exactly what I meant. An experiment - “let’s try this... oh wow, look -
>>> it
>>> works!” Fine for a college lab, not so cool for the field.
>>>
>>> A codebase with a decent chance to become stable usually doesn't chase
>>> the
>>> newest shiny toys/tools.
>>>
>>> It is especially nice that your build system blindly overrides local
>>> edits. I.e., it is pointless to edit any of the CMakeLists.txt files in
>>> there, as it pulls the original ones from your Github regardless. What
>>> can
>>> I say?
>>>
>>> (You felt trying a new cryptographic filesystem was not exciting enough,
>>> had to throw new development tools in the mix?)
>>>
>>>> The stuff it
>>>> downloads is mostly other code modules from myself.
>>> As if those modules were too large to be a part of the same codebase…
>>>
>>>> Boost is downloaded in a certain version to ensure compatibility.
>>> Boost usually is good enough to ensure backwards compatibility on its
>>> own
>>> (as EncFS demonstrates nicely).
>>>
>>> In any case, I for one do not need to carry an old version of boost. I’m
>>> pretty sure many would feel the same way. I strongly suggest to drop
>>> boost-1.57.
>>>
>>>> Unfortunately, biicode is
>>>> not maintained anymore, so I'll switch to more established build
>>>> systems.
>>> Glad to hear this. Cmake alone is quite enough to annoy a person. :-)
>>>
>>>> Mac OS X is not yet supported, this is actually what I'm currently
>>>> working on.
>>> OK.
>>>
>>>> It should compile fine if you're using the latest clang (or
>>>> at least did for me),
>>> I’m using clang-3.7 (the latest *stable*), and clang that came with the
>>> latest (*released*) Xcode. Clang-3.9 is still beta, so I don’t use it.
>>> But
>>> the compilation seemed to work - up until it found it’s unable to find
>>> osxfuse.
>>>
>>>> but I couldn't get it to run with osxfuse yet.
>>> Parametrizing osxfuse location might help.
>>>
>>>> Sorry for that.
>>> ;-)
>>>
>>>> Do you have a Linux VM? There it should work fine by
>>>> just following the build instructions on github.
>>> I do, but use it for other development. So trying cryfs there is out of
>>> question. “CryFS = Cry For Sure” ;)
>>>

Re: [Encfs-users] Secrecy Proposal

[Sebastian M. <hei...@we...>]

Hi,

most of CryFS was developed after the thesis was finished.
It was developed as an open source project with users in mind, it is not 
meant as a proof-of-concept for the thesis.

I agree there are still issues, CryFS is not stable yet. For example, 
the build system has to be switched.
I propose we move the conversation from this mailing list to GitHub. 
Please feel free to open issues for things you don't like and we can 
discuss possible solutions there.

Best,
Sebastian

On 09.02.2016 16:43, Blumenthal, Uri - 0553 - MITLL wrote:
>> thanks for your feedback. Building CryFS on Mac OS X is currently not
>> supported unfortunately.
>> Maybe I should've said that clearer from the beginning, I'm sorry this
>> got you so frustrated.
> Thank you for the explanation. It confirms my assessment:
>
> - The idea and the filesystem architecture are interesting, well-suited
> for MS or better.
>
> - The implementation is fine to mark a checkbox in thesis defense (“yes it
> can work - here’s the proof”), but unsuitable for field deployment without
> significant efforts and possibly re-design.
>
>> Btw most users won't ever build CryFS themselves
> We differ here. But I guess, “the market” will decide.
>
>
>> - there are Debian
>> packages already, and in future there will also be RPM and (once
>> supported) Mac OS X installers.
> Sure, fine.
>
>
>> On 09.02.2016 05:43, Blumenthal, Uri - 0553 - MITLL wrote:
>>>>> OK, I got the code and took a brief look. First impression: it looks
>>>>> like an exercise in “how many different and complex packages I can tie
>>>>> together without crashing the whole thing”. Fragility of such approach
>>>>> are too numerous to list. …………
>>>> When I started the project, I was trying out a new buildsystem called
>>>> biicode with a new approach to dependency management.
>>> Exactly what I meant. An experiment - “let’s try this... oh wow, look -
>>> it
>>> works!” Fine for a college lab, not so cool for the field.
>>>
>>> A codebase with a decent chance to become stable usually doesn't chase
>>> the
>>> newest shiny toys/tools.
>>>
>>> It is especially nice that your build system blindly overrides local
>>> edits. I.e., it is pointless to edit any of the CMakeLists.txt files in
>>> there, as it pulls the original ones from your Github regardless. What
>>> can
>>> I say?
>>>
>>> (You felt trying a new cryptographic filesystem was not exciting enough,
>>> had to throw new development tools in the mix?)
>>>
>>>> The stuff it
>>>> downloads is mostly other code modules from myself.
>>> As if those modules were too large to be a part of the same codebase…
>>>
>>>> Boost is downloaded in a certain version to ensure compatibility.
>>> Boost usually is good enough to ensure backwards compatibility on its
>>> own
>>> (as EncFS demonstrates nicely).
>>>
>>> In any case, I for one do not need to carry an old version of boost. I’m
>>> pretty sure many would feel the same way. I strongly suggest to drop
>>> boost-1.57.
>>>
>>>> Unfortunately, biicode is
>>>> not maintained anymore, so I'll switch to more established build
>>>> systems.
>>> Glad to hear this. Cmake alone is quite enough to annoy a person. :-)
>>>
>>>> Mac OS X is not yet supported, this is actually what I'm currently
>>>> working on.
>>> OK.
>>>
>>>> It should compile fine if you're using the latest clang (or
>>>> at least did for me),
>>> I’m using clang-3.7 (the latest *stable*), and clang that came with the
>>> latest (*released*) Xcode. Clang-3.9 is still beta, so I don’t use it.
>>> But
>>> the compilation seemed to work - up until it found it’s unable to find
>>> osxfuse.
>>>
>>>> but I couldn't get it to run with osxfuse yet.
>>> Parametrizing osxfuse location might help.
>>>
>>>> Sorry for that.
>>> ;-)
>>>
>>>> Do you have a Linux VM? There it should work fine by
>>>> just following the build instructions on github.
>>> I do, but use it for other development. So trying cryfs there is out of
>>> question. “CryFS = Cry For Sure” ;)
>>>

Re: [Encfs-users] Secrecy Proposal

[Blumenthal, U. - 0. - M. <ur...@ll...>]

>thanks for your feedback. Building CryFS on Mac OS X is currently not
>supported unfortunately.
>Maybe I should've said that clearer from the beginning, I'm sorry this
>got you so frustrated.

Thank you for the explanation. It confirms my assessment:

- The idea and the filesystem architecture are interesting, well-suited
for MS or better.

- The implementation is fine to mark a checkbox in thesis defense (“yes it
can work - here’s the proof”), but unsuitable for field deployment without
significant efforts and possibly re-design.

>Btw most users won't ever build CryFS themselves

We differ here. But I guess, “the market” will decide.


>- there are Debian
>packages already, and in future there will also be RPM and (once
>supported) Mac OS X installers.

Sure, fine.


>On 09.02.2016 05:43, Blumenthal, Uri - 0553 - MITLL wrote:
>>>> OK, I got the code and took a brief look. First impression: it looks
>>>> like an exercise in “how many different and complex packages I can tie
>>>> together without crashing the whole thing”. Fragility of such approach
>>>> are too numerous to list. …………
>>> When I started the project, I was trying out a new buildsystem called
>>> biicode with a new approach to dependency management.
>> Exactly what I meant. An experiment - “let’s try this... oh wow, look -
>>it
>> works!” Fine for a college lab, not so cool for the field.
>>
>> A codebase with a decent chance to become stable usually doesn't chase
>>the
>> newest shiny toys/tools.
>>
>> It is especially nice that your build system blindly overrides local
>> edits. I.e., it is pointless to edit any of the CMakeLists.txt files in
>> there, as it pulls the original ones from your Github regardless. What
>>can
>> I say?
>>
>> (You felt trying a new cryptographic filesystem was not exciting enough,
>> had to throw new development tools in the mix?)
>>
>>> The stuff it
>>> downloads is mostly other code modules from myself.
>> As if those modules were too large to be a part of the same codebase…
>>
>>> Boost is downloaded in a certain version to ensure compatibility.
>> Boost usually is good enough to ensure backwards compatibility on its
>>own
>> (as EncFS demonstrates nicely).
>>
>> In any case, I for one do not need to carry an old version of boost. I’m
>> pretty sure many would feel the same way. I strongly suggest to drop
>> boost-1.57.
>>
>>> Unfortunately, biicode is
>>> not maintained anymore, so I'll switch to more established build
>>>systems.
>> Glad to hear this. Cmake alone is quite enough to annoy a person. :-)
>>
>>> Mac OS X is not yet supported, this is actually what I'm currently
>>> working on.
>> OK.
>>
>>> It should compile fine if you're using the latest clang (or
>>> at least did for me),
>> I’m using clang-3.7 (the latest *stable*), and clang that came with the
>> latest (*released*) Xcode. Clang-3.9 is still beta, so I don’t use it.
>>But
>> the compilation seemed to work - up until it found it’s unable to find
>> osxfuse.
>>
>>> but I couldn't get it to run with osxfuse yet.
>> Parametrizing osxfuse location might help.
>>
>>> Sorry for that.
>> ;-)
>>
>>> Do you have a Linux VM? There it should work fine by
>>> just following the build instructions on github.
>> I do, but use it for other development. So trying cryfs there is out of
>> question. “CryFS = Cry For Sure” ;)
>>
>

Re: [Encfs-users] Secrecy Proposal

[Sebastian M. <hei...@we...>]

Hi Uri,

thanks for your feedback. Building CryFS on Mac OS X is currently not 
supported unfortunately.
Maybe I should've said that clearer from the beginning, I'm sorry this 
got you so frustrated.
Btw most users won't ever build CryFS themselves - there are Debian 
packages already, and in future there will also be RPM and (once 
supported) Mac OS X installers.

Best
Sebastian

On 09.02.2016 05:43, Blumenthal, Uri - 0553 - MITLL wrote:
>>> OK, I got the code and took a brief look. First impression: it looks
>>> like an exercise in “how many different and complex packages I can tie
>>> together without crashing the whole thing”. Fragility of such approach
>>> are too numerous to list. …………
>> When I started the project, I was trying out a new buildsystem called
>> biicode with a new approach to dependency management.
> Exactly what I meant. An experiment - “let’s try this... oh wow, look - it
> works!” Fine for a college lab, not so cool for the field.
>
> A codebase with a decent chance to become stable usually doesn't chase the
> newest shiny toys/tools.
>
> It is especially nice that your build system blindly overrides local
> edits. I.e., it is pointless to edit any of the CMakeLists.txt files in
> there, as it pulls the original ones from your Github regardless. What can
> I say?
>
> (You felt trying a new cryptographic filesystem was not exciting enough,
> had to throw new development tools in the mix?)
>
>> The stuff it
>> downloads is mostly other code modules from myself.
> As if those modules were too large to be a part of the same codebase…
>
>> Boost is downloaded in a certain version to ensure compatibility.
> Boost usually is good enough to ensure backwards compatibility on its own
> (as EncFS demonstrates nicely).
>
> In any case, I for one do not need to carry an old version of boost. I’m
> pretty sure many would feel the same way. I strongly suggest to drop
> boost-1.57.
>
>> Unfortunately, biicode is
>> not maintained anymore, so I'll switch to more established build systems.
> Glad to hear this. Cmake alone is quite enough to annoy a person. :-)
>
>> Mac OS X is not yet supported, this is actually what I'm currently
>> working on.
> OK.
>
>> It should compile fine if you're using the latest clang (or
>> at least did for me),
> I’m using clang-3.7 (the latest *stable*), and clang that came with the
> latest (*released*) Xcode. Clang-3.9 is still beta, so I don’t use it. But
> the compilation seemed to work - up until it found it’s unable to find
> osxfuse.
>
>> but I couldn't get it to run with osxfuse yet.
> Parametrizing osxfuse location might help.
>
>> Sorry for that.
> ;-)
>
>> Do you have a Linux VM? There it should work fine by
>> just following the build instructions on github.
> I do, but use it for other development. So trying cryfs there is out of
> question. “CryFS = Cry For Sure” ;)
>

Re: [Encfs-users] Secrecy Proposal

[Blumenthal, U. - 0. - M. <ur...@ll...>]

>>OK, I got the code and took a brief look. First impression: it looks
>> like an exercise in “how many different and complex packages I can tie
>> together without crashing the whole thing”. Fragility of such approach
>> are too numerous to list. …………
>When I started the project, I was trying out a new buildsystem called
>biicode with a new approach to dependency management.

Exactly what I meant. An experiment - “let’s try this... oh wow, look - it
works!” Fine for a college lab, not so cool for the field.

A codebase with a decent chance to become stable usually doesn't chase the
newest shiny toys/tools.

It is especially nice that your build system blindly overrides local
edits. I.e., it is pointless to edit any of the CMakeLists.txt files in
there, as it pulls the original ones from your Github regardless. What can
I say?

(You felt trying a new cryptographic filesystem was not exciting enough,
had to throw new development tools in the mix?)

> The stuff it 
>downloads is mostly other code modules from myself.

As if those modules were too large to be a part of the same codebase…

>Boost is downloaded in a certain version to ensure compatibility.

Boost usually is good enough to ensure backwards compatibility on its own
(as EncFS demonstrates nicely).

In any case, I for one do not need to carry an old version of boost. I’m
pretty sure many would feel the same way. I strongly suggest to drop
boost-1.57.

>Unfortunately, biicode is
>not maintained anymore, so I'll switch to more established build systems.

Glad to hear this. Cmake alone is quite enough to annoy a person. :-)

>Mac OS X is not yet supported, this is actually what I'm currently
>working on. 

OK.

>It should compile fine if you're using the latest clang (or
>at least did for me),

I’m using clang-3.7 (the latest *stable*), and clang that came with the
latest (*released*) Xcode. Clang-3.9 is still beta, so I don’t use it. But
the compilation seemed to work - up until it found it’s unable to find
osxfuse.

>but I couldn't get it to run with osxfuse yet.

Parametrizing osxfuse location might help.

> 
>Sorry for that.

;-)

>Do you have a Linux VM? There it should work fine by
>just following the build instructions on github.

I do, but use it for other development. So trying cryfs there is out of
question. “CryFS = Cry For Sure” ;)

Re: [Encfs-users] Secrecy Proposal

[Sebastian M. <hei...@we...>]

On 09.02.2016 00:53, Blumenthal, Uri - 0553 - MITLL wrote:
> OK, I got the code and took a brief look. First impression: it looks 
> like an exercise in “how many different and complex packages I can tie 
> together without crashing the whole thing”. Fragility of such approach 
> are too numerous to list. Not to mention that it downloads a ****load 
> of stuff, most of which (some) people have installed - and care about 
> the version they have running. For example, WTF do I need your code to 
> pull megabytes of boost-1.57, when I’m happily running boost-1.59??? 
> Build is still running, so no more comments *at this time*. But I’m 
> almost sorry I started. 
When I started the project, I was trying out a new buildsystem called 
biicode with a new approach to dependency management. The stuff it 
downloads is mostly other code modules from myself. Boost is downloaded 
in a certain version to ensure compatibility. Unfortunately, biicode is 
not maintained anymore, so I'll switch to more established build systems.

Mac OS X is not yet supported, this is actually what I'm currently 
working on. It should compile fine if you're using the latest clang (or 
at least did for me), but I couldn't get it to run with osxfuse yet. 
Sorry for that. Do you have a Linux VM? There it should work fine by 
just following the build instructions on github.

Re: [Encfs-users] Secrecy Proposal

[Blumenthal, U. - 0. - M. <ur...@ll...>]

>>I meant that since file size does change with encryption padding, MAC,
>> and IV - if (a) one picks large block size, and (b) filesize are
>> comparable to block size, it would be hard to tell one (small) file
>> from another. Think copies of text emails (not those JavaScript
>> monsters :). :-)
>Yes, for very small files, this would work.

Exactly what I said. :-)

>>>There is the issue in the current implementation that you can get
>>> conflicts when multiple users are modifying the same directory at the
>>> same time. This is, however, an implementation issue and not a design
>>> issue. If you're interested in some possible solutions, you can take a
>>> look at section 4.6 in https://www.cryfs.org/cryfs_mathesis.pdf .
>> Let me take a look and get back to you.
>Thanks. I'm happy about any feedback you can give me.

OK, I got the code and took a brief look.

First impression: it looks like an exercise in “how many different and
complex packages I can tie together without crashing the whole thing”.
Fragility of such approach are too numerous to list. Not to mention that
it downloads a ****load of stuff, most of which (some) people have
installed - and care about the version they have running. For example, WTF
do I need your code to pull megabytes of boost-1.57, when I’m happily
running boost-1.59???

Build is still running, so no more comments *at this time*. But I’m almost
sorry I started.



>>> I'm not sure whether
>>> VeraCrypt can handle multiple instances accessing the same container
>>> file at the same time though.
>> I don’t know (yet).
>As long as they didn't take special attention to this when implementing
>VeraCrypt (which I don't see why they would), I think it is improbable
>that VeraCrypt can handle this scenario. It is much easier to implement
>it assuming there is only one process accessing the container file at a
>time.

:-)  That is true. 


>>>As a side note, the way CryFS stores its blocks is a quite small module
>>> in the application that could easily be changed to directly storing it
>>> on EBS or S3 (or any other cloud provider). I'm thinking about offering
>>> a version that runs directly off the cloud without a local copy of the
>>> ciphertexts. This is only an idea and nothing concrete yet though.
>> I think it would be *very* nice to have this option/capability.
>>
>Yes, I think so as well. It has also disadvantages (e.g. longer access
>times, slower read/write speeds, ...), but it is something worth trying.

Considering that it would free many gigabytes of user disk space - I’m
certain many (most?) of the users would gladly pay with some speed for
this.

> 
>I have other things on my agenda currently, but will definitely try it
>out in future. It would only be a small code change however, so if
>you're interested in implementing it, I'm happy to give you an
>introduction to the code base.

I wonder if your build process can be modified/simplified, with more
things made explicit/manual. As it is - I almost can’t stand it. :-(

CMake Error at 
/Users/ur20980/src/cryfs/bii/deps/toeb/cmakepp/cmake/core/message.cmake:94
(_message):
  Osxfuse not found.  Please install osxfuse.
Call Stack (most recent call first):
  /Users/ur20980/src/cryfs/bii/deps/messmer/fspp/CMakeLists.txt:20
(MESSAGE)


-- Configuring incomplete, errors occurred!
See also "/Users/ur20980/src/cryfs/bii/build/CMakeFiles/CMakeOutput.log".
See also "/Users/ur20980/src/cryfs/bii/build/CMakeFiles/CMakeError.log".
ERROR: CMake failed

$ ll /opt/local/lib/*fuse*
lrwxr-xr-x  1 macports  admin      22 Oct 28 02:35
/opt/local/lib/libosxfuse.2.dylib@ -> libosxfuse_i64.2.dylib
lrwxr-xr-x  1 macports  admin      20 Oct 28 02:35
/opt/local/lib/libosxfuse.dylib@ -> libosxfuse_i64.dylib
lrwxr-xr-x  1 macports  admin      17 Oct 28 02:35
/opt/local/lib/libosxfuse.la@ -> libosxfuse_i64.la
-rwxr-xr-x  1 macports  admin  195672 Oct 28 02:35
/opt/local/lib/libosxfuse_i32.2.dylib*
lrwxr-xr-x  1 macports  admin      22 Oct 28 02:35
/opt/local/lib/libosxfuse_i32.dylib@ -> libosxfuse_i32.2.dylib
-rwxr-xr-x  1 macports  admin  195704 Oct 28 02:35
/opt/local/lib/libosxfuse_i64.2.dylib*
lrwxr-xr-x  1 macports  admin      22 Oct 28 02:35
/opt/local/lib/libosxfuse_i64.dylib@ -> libosxfuse_i64.2.dylib
$ 

And this configuration did not negatively affect EncFS:

$ otool -L /opt/local/bin/encfs
/opt/local/bin/encfs:
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundat
ion (compatibility version 150.0.0, current version 1153.18.0)
	/opt/local/lib/libencfs.6.dylib (compatibility version 7.0.0, current
version 7.2.0)
	/opt/local/lib/librlog.5.dylib (compatibility version 6.0.0, current
version 6.0.0)
	/opt/local/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current
version 1.0.0)
	/opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0,
current version 1.0.0)
	/opt/local/lib/libboost_serialization-mt.dylib (compatibility version
0.0.0, current version 0.0.0)
	/opt/local/lib/libintl.8.dylib (compatibility version 10.0.0, current
version 10.3.0)
	/opt/local/lib/libosxfuse_i64.2.dylib (compatibility version 10.0.0,
current version 10.3.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
120.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
1213.0.0)

Re: [Encfs-users] Secrecy Proposal

[Sebastian M. <hei...@we...>]

On 08.02.2016 23:44, Blumenthal, Uri - 0553 - MITLL wrote:
> I meant that since file size does change with encryption padding, MAC, 
> and IV - if (a) one picks large block size, and (b) filesize are 
> comparable to block size, it would be hard to tell one (small) file 
> from another. Think copies of text emails (not those JavaScript 
> monsters :). :-) 
Yes, for very small files, this would work.
>>> Yes. I’m not talking about immaturity (i.e., bugs present and waiting
>>> to be found and remedied). I’m talking about design decisions and
>>> their consequences. For example, one obvious drawback is limitation on
>>> multi-user access.
>> There is the issue in the current implementation that you can get
>> conflicts when multiple users are modifying the same directory at the
>> same time. This is, however, an implementation issue and not a design
>> issue. If you're interested in some possible solutions, you can take a
>> look at section 4.6 in https://www.cryfs.org/cryfs_mathesis.pdf .
> Let me take a look and get back to you.
Thanks. I'm happy about any feedback you can give me.
>> I'm not sure whether
>> VeraCrypt can handle multiple instances accessing the same container
>> file at the same time though.
> I don’t know (yet).
As long as they didn't take special attention to this when implementing 
VeraCrypt (which I don't see why they would), I think it is improbable 
that VeraCrypt can handle this scenario. It is much easier to implement 
it assuming there is only one process accessing the container file at a 
time.
>
>> As a side note, the way CryFS stores its blocks is a quite small module
>> in the application that could easily be changed to directly storing it
>> on EBS or S3 (or any other cloud provider). I'm thinking about offering
>> a version that runs directly off the cloud without a local copy of the
>> ciphertexts. This is only an idea and nothing concrete yet though.
> I think it would be *very* nice to have this option/capability.
>
Yes, I think so as well. It has also disadvantages (e.g. longer access 
times, slower read/write speeds, ...), but it is something worth trying. 
I have other things on my agenda currently, but will definitely try it 
out in future. It would only be a small code change however, so if 
you're interested in implementing it, I'm happy to give you an 
introduction to the code base.

Re: [Encfs-users] Secrecy Proposal

[Blumenthal, U. - 0. - M. <ur...@ll...>]

>>Well, it can confuse somewhat file size of multiple small files
>That sounds interesting. Can you explain what you mean by that?

I meant that since file size does change with encryption padding, MAC, and
IV - if (a) one picks large block size, and (b) filesize are comparable to
block size, it would be hard to tell one (small) file from another. Think
copies of text emails (not those JavaScript monsters :). :-)

>> On the other hand, unless the filesystem is actively in use, I think
>>this
>> attack is still possible: I observe the state, make you store a file,
>>and
>> notice if the state changed or not. I don’t need to know the hierarchy
>>to
>> tell that.
>Yes, I agree. If the attacker has constant access to your Dropbox and
>sees the access pattern, watermarking attacks can still be possible.
>Actually, it might even be possible without constant access, because
>Dropbox keeps a file history which allows an attacker to get the access
>patterns afterwards. CryFS obfuscates this a bit better than EncFS (the
>attacker only knows that the file system grew by x bytes, they don't
>know how many files were added or how large individual files are), but
>that might be enough to get statistically relevant knowledge.

Yes.

>> Yes. I’m not talking about immaturity (i.e., bugs present and waiting
>> to be found and remedied). I’m talking about design decisions and
>> their consequences. For example, one obvious drawback is limitation on
>> multi-user access.
>There is the issue in the current implementation that you can get
>conflicts when multiple users are modifying the same directory at the
>same time. This is, however, an implementation issue and not a design
>issue. If you're interested in some possible solutions, you can take a
>look at section 4.6 in https://www.cryfs.org/cryfs_mathesis.pdf .

Let me take a look and get back to you.

>>> However, VeraCrypt doesn't work well when the data is stored in the
>>> cloud. Even if you only change one small file in your file system, this
>>> might cause the whole container file to be re-uploaded.
>> I’m not sure this is correct. For example, one could mount it as a file
>>on
>> EBS or EFS.
>> Only if it has to be copied to the local filesystem and back, it becomes
>> as bad as you describe.
>Yes, if you keep the container file entirely remotely and mount it over
>the network, you might get around this issue.

This is the ideal use of the cloud storage. I realize that it isn’t always
possible. :-(

>I'm not sure whether
>VeraCrypt can handle multiple instances accessing the same container
>file at the same time though.

I don’t know (yet).

>As a side note, the way CryFS stores its blocks is a quite small module
>in the application that could easily be changed to directly storing it
>on EBS or S3 (or any other cloud provider). I'm thinking about offering
>a version that runs directly off the cloud without a local copy of the
>ciphertexts. This is only an idea and nothing concrete yet though.

I think it would be *very* nice to have this option/capability. 

Re: [Encfs-users] Secrecy Proposal

[Sebastian M. <hei...@we...>]

Hey Uri,

On 08.02.2016 22:17, Blumenthal, Uri - 0553 - MITLL wrote:
> Well, it can confuse somewhat file size of multiple small files
That sounds interesting. Can you explain what you mean by that?
>> A watermarking attack is where an attacker gives you a certain file (or
>> set of files) and wants to check later whether you stored it in your
>> filesystem or not. With EncFS, this is possible if they just remember
>> the file size distribution.
> I see. Thanks for explaining.
>
> On the other hand, unless the filesystem is actively in use, I think this
> attack is still possible: I observe the state, make you store a file, and
> notice if the state changed or not. I don’t need to know the hierarchy to
> tell that.
Yes, I agree. If the attacker has constant access to your Dropbox and 
sees the access pattern, watermarking attacks can still be possible. 
Actually, it might even be possible without constant access, because 
Dropbox keeps a file history which allows an attacker to get the access 
patterns afterwards. CryFS obfuscates this a bit better than EncFS (the 
attacker only knows that the file system grew by x bytes, they don't 
know how many files were added or how large individual files are), but 
that might be enough to get statistically relevant knowledge.
> Yes. I’m not talking about immaturity (i.e., bugs present and waiting 
> to be found and remedied). I’m talking about design decisions and 
> their consequences. For example, one obvious drawback is limitation on 
> multi-user access. 
There is the issue in the current implementation that you can get 
conflicts when multiple users are modifying the same directory at the 
same time. This is, however, an implementation issue and not a design 
issue. If you're interested in some possible solutions, you can take a 
look at section 4.6 in https://www.cryfs.org/cryfs_mathesis.pdf .
>> However, VeraCrypt doesn't work well when the data is stored in the
>> cloud. Even if you only change one small file in your file system, this
>> might cause the whole container file to be re-uploaded.
> I’m not sure this is correct. For example, one could mount it as a file on
> EBS or EFS.
> Only if it has to be copied to the local filesystem and back, it becomes
> as bad as you describe.
Yes, if you keep the container file entirely remotely and mount it over 
the network, you might get around this issue. I'm not sure whether 
VeraCrypt can handle multiple instances accessing the same container 
file at the same time though.

As a side note, the way CryFS stores its blocks is a quite small module 
in the application that could easily be changed to directly storing it 
on EBS or S3 (or any other cloud provider). I'm thinking about offering 
a version that runs directly off the cloud without a local copy of the 
ciphertexts. This is only an idea and nothing concrete yet though.

Best
Sebastian

Re: [Encfs-users] Secrecy Proposal

[Blumenthal, U. - 0. - M. <ur...@ll...>]

>>Doesn’t EncFS obscure at least some metadata (besides names)?
>As far as I know, EncFS keeps the metadata (i.e. permission bits)
>unencrypted.

I see. Yes, I think this is correct, at least regarding permission bits.

>It obscures file names, but not file sizes or directory structure.

Well, it can confuse somewhat file size of multiple small files, but in
general you’re correct. If you have a distribution pattern (a few files of
1+MB, one file < 1KB, and a few around 100KB) it would be distinguishable.
And you described how it could be used to tell whether it’s likely to be,
e.g., a copy of CD, or a copy of Win distro, etc.

I’m not certain it would carry much harm - “yeah it was a CD, so what”,
but your point is well-taken. It would be nice to be able to hide this
kind of metadata.

As I said, I’m concerned of the cost to reliability and other capabilities
(such as multi-user access) that this measure would exact. (See below)

>A watermarking attack is where an attacker gives you a certain file (or
>set of files) and wants to check later whether you stored it in your
>filesystem or not. With EncFS, this is possible if they just remember
>the file size distribution.

I see. Thanks for explaining.

On the other hand, unless the filesystem is actively in use, I think this
attack is still possible: I observe the state, make you store a file, and
notice if the state changed or not. I don’t need to know the hierarchy to
tell that.

>> My concern is that in the attempt to improve security we may hurt
>> reliability.
>As of today, I wouldn't recommend CryFS for production use. It is a very
>young project.

Yes. I’m not talking about immaturity (i.e., bugs present and waiting to
be found and remedied). I’m talking about design decisions and their
consequences. For example, one obvious drawback is limitation on
multi-user access. 

> I'm using it myself for my documents and files and didn't
>have any issues, but it still needs to be proven by a larger number of
>beta testers. That is another reason why I reached out to this mailing
>list.

Good point.

>The design of CryFS is not very complicated and there are an awful lot
>of test cases, so I think I can get CryFS to be at least as stable as
>EncFS is today.

I can’t see why not.

With the exception of those constraints that your directory structure
maintenance would impose, of course - of which multi-user access is the
most obvious one.

>>>> For those who’d rather have a completely opaque container, there is
>>>> VeraCrypt.
>Ah right I forgot the VeraCrypt point you mentioned.
>VeraCrypt is a great choice if you're encrypting your files only locally
>and you know a maximal file system size in advance. Because you have to
>allocate a full container file even if it is only half full, you get the
>additional advantage of hiding how much data you actually store in your
>container. With CryFS, you can also do that, but it is more complicated
>(you'd have to introduce dummy blocks or a second file system with dummy
>data working on the same base directory). So for local-only encryption,
>CryFS only has an advantage if it is important to you that the file
>system only allocates the space you actually use.

Yes, it is a significant advantage, and the main reason I’m using mostly
EncFS (so far :).

>However, VeraCrypt doesn't work well when the data is stored in the
>cloud. Even if you only change one small file in your file system, this
>might cause the whole container file to be re-uploaded.

I’m not sure this is correct. For example, one could mount it as a file on
EBS or EFS.
Only if it has to be copied to the local filesystem and back, it becomes
as bad as you describe.

>Furthermore, if 
>you make changes to your file system on two different computers without
>waiting for a full sync in between, you will end up having conflicts in
>the container file, i.e. you will have two container files with each of
>them containing only one of the changes.

Yes, that’s a definite drawback.

Re: [Encfs-users] Secrecy Proposal

[Sebastian M. <hei...@we...>]

Hi Uri,

On 08.02.2016 19:42, Blumenthal, Uri - 0553 - MITLL wrote:
> Doesn’t EncFS obscure at least some metadata (besides names)?
As far as I know, EncFS keeps the metadata (i.e. permission bits) 
unencrypted.
It obscures file names, but not file sizes or directory structure.
>> Another potential problem are watermarking attacks.
> Could you please explain?

A watermarking attack is where an attacker gives you a certain file (or 
set of files) and wants to check later whether you stored it in your 
filesystem or not. With EncFS, this is possible if they just remember 
the file size distribution.
> My concern is that in the attempt to improve security we may hurt
> reliability.
As of today, I wouldn't recommend CryFS for production use. It is a very 
young project. I'm using it myself for my documents and files and didn't 
have any issues, but it still needs to be proven by a larger number of 
beta testers. That is another reason why I reached out to this mailing list.
The design of CryFS is not very complicated and there are an awful lot 
of test cases, so I think I can get CryFS to be at least as stable as 
EncFS is today.
>
>>> For those who’d rather have a completely opaque container, there is
>>> VeraCrypt.
Ah right I forgot the VeraCrypt point you mentioned.
VeraCrypt is a great choice if you're encrypting your files only locally 
and you know a maximal file system size in advance. Because you have to 
allocate a full container file even if it is only half full, you get the 
additional advantage of hiding how much data you actually store in your 
container. With CryFS, you can also do that, but it is more complicated 
(you'd have to introduce dummy blocks or a second file system with dummy 
data working on the same base directory). So for local-only encryption, 
CryFS only has an advantage if it is important to you that the file 
system only allocates the space you actually use.

However, VeraCrypt doesn't work well when the data is stored in the 
cloud. Even if you only change one small file in your file system, this 
might cause the whole container file to be re-uploaded. Furthermore, if 
you make changes to your file system on two different computers without 
waiting for a full sync in between, you will end up having conflicts in 
the container file, i.e. you will have two container files with each of 
them containing only one of the changes.

Best
Sebastian

Re: [Encfs-users] Secrecy Proposal

[Sebastian M. <hei...@we...>]

Hi Uri,

there are use cases where it is enough to encrypt file contents and you 
don't care about the directory structure, file sizes or file metadata 
being public. For these cases, a (fixed version of) EncFS works just as 
well.

However, this metadata being public gives an attacker more information 
than you might think at first glance. Say you store some directories, 
each has ~20 files and each file has ~3MB. This is probably a music CD 
collection. Or say you store a copy of the Windows 8 CD (or any other 
set of files the attacker has access to). By looking at the distribution 
of file sizes over directories, an attacker can say with fair certainty 
whether you're storing this set of files or not. Another potential 
problem are watermarking attacks.

So in general, my opinion is to better be safe than sorry and keep 
things as confidential as possible. But there certainly are use cases 
where this level of confidentiality is not needed.

Best,
Sebastian

On 08.02.2016 18:36, Blumenthal, Uri - 0553 - MITLL wrote:
> It is unclear to me what kind of information you expect the adversary to
> learn from the current EncFS structure with encrypted filenames (and the
> other protections, like block-encoding file names, etc), what what in your
> opinion that adversary could do with that information.
>
> I wonder if the extra complexity and fragility this mechanism introduces
> are worth the extra protection it offers.
>
> For example, I couldn’t care less that my directory structure is revealed.
> Hiding file names is plenty good enough for my use case.
>
> For those who’d rather have a completely opaque container, there is
> VeraCrypt.
> --
> Regards,
> Uri Blumenthal
>
>
>
>
> On 2/8/16, 04:23, "Sebastian Messmer" <hei...@we...> wrote:
>
>> Hey Anthony,
>>
>> thank you. Tell me what you think after you tried it out.
>> If you have input on the way I intend to solve the directory conflict
>> problem, I'd also be happy to hear it.
>>
>> Just as you can with EncFS, you can interleave multiple encrypted file
>> systems in CryFS if you keep the configuration file out of the base
>> directory. You can also for example obfuscate the actual file system
>> size by adding random blocks (or alternatively a second CryFS file
>> system with random data).
>>
>> Best
>> Sebastian
>>
>> On 08.02.2016 01:47, Anthony Thyssen wrote:
>>> I look forward to testing out this out.  As I have said in the past,
>>> this is the 'next step' in the File System Level of Encryption (As
>>> opposed to Disk/Partition or individual File based encryption).
>>>
>>> The point about a changes to a directory on two different systems
>>> causing a synchronization conflict is something I never even thought
>>> of, and will require some very careful handling. Otherwise files added
>>> on one system may become 'lost'.
>>>
>>> I also look forward to attempting to 'interleave' multiple encrypted
>>> file systems into the same encrypted data store, Something I often do
>>> with EncFS without problems.
>>>
>>> Thank you for your efforts, Cloud Filesystems have become a major part
>>> of the world, and Encrypted Filesystems has become vital to making
>>> this secure, even form the providers of such systems.
>>>
>>
>> --------------------------------------------------------------------------
>> ----
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>> _______________________________________________
>> Encfs-users mailing list
>> Enc...@li...
>> https://lists.sourceforge.net/lists/listinfo/encfs-users
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Encfs-users mailing list
> Enc...@li...
> https://lists.sourceforge.net/lists/listinfo/encfs-users

Re: [Encfs-users] Secrecy Proposal

[Blumenthal, U. - 0. - M. <ur...@ll...>]

It is unclear to me what kind of information you expect the adversary to
learn from the current EncFS structure with encrypted filenames (and the
other protections, like block-encoding file names, etc), what what in your
opinion that adversary could do with that information.

I wonder if the extra complexity and fragility this mechanism introduces
are worth the extra protection it offers.

For example, I couldn’t care less that my directory structure is revealed.
Hiding file names is plenty good enough for my use case.

For those who’d rather have a completely opaque container, there is
VeraCrypt.
--
Regards,
Uri Blumenthal




On 2/8/16, 04:23, "Sebastian Messmer" <hei...@we...> wrote:

>Hey Anthony,
>
>thank you. Tell me what you think after you tried it out.
>If you have input on the way I intend to solve the directory conflict
>problem, I'd also be happy to hear it.
>
>Just as you can with EncFS, you can interleave multiple encrypted file
>systems in CryFS if you keep the configuration file out of the base
>directory. You can also for example obfuscate the actual file system
>size by adding random blocks (or alternatively a second CryFS file
>system with random data).
>
>Best
>Sebastian
>
>On 08.02.2016 01:47, Anthony Thyssen wrote:
>> I look forward to testing out this out.  As I have said in the past,
>> this is the 'next step' in the File System Level of Encryption (As
>> opposed to Disk/Partition or individual File based encryption).
>>
>> The point about a changes to a directory on two different systems
>> causing a synchronization conflict is something I never even thought
>> of, and will require some very careful handling. Otherwise files added
>> on one system may become 'lost'.
>>
>> I also look forward to attempting to 'interleave' multiple encrypted
>> file systems into the same encrypted data store, Something I often do
>> with EncFS without problems.
>>
>> Thank you for your efforts, Cloud Filesystems have become a major part
>> of the world, and Encrypted Filesystems has become vital to making
>> this secure, even form the providers of such systems.
>>
>
>
>--------------------------------------------------------------------------
>----
>Site24x7 APM Insight: Get Deep Visibility into Application Performance
>APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>Monitor end-to-end web transactions and take corrective actions now
>Troubleshoot faster and improve end-user experience. Signup Now!
>http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>_______________________________________________
>Encfs-users mailing list
>Enc...@li...
>https://lists.sourceforge.net/lists/listinfo/encfs-users

Re: [Encfs-users] Secrecy Proposal

[Sebastian M. <hei...@we...>]

Hey Anthony,

thank you. Tell me what you think after you tried it out.
If you have input on the way I intend to solve the directory conflict 
problem, I'd also be happy to hear it.

Just as you can with EncFS, you can interleave multiple encrypted file 
systems in CryFS if you keep the configuration file out of the base 
directory. You can also for example obfuscate the actual file system 
size by adding random blocks (or alternatively a second CryFS file 
system with random data).

Best
Sebastian

On 08.02.2016 01:47, Anthony Thyssen wrote:
> I look forward to testing out this out.  As I have said in the past, 
> this is the 'next step' in the File System Level of Encryption (As 
> opposed to Disk/Partition or individual File based encryption).
>
> The point about a changes to a directory on two different systems 
> causing a synchronization conflict is something I never even thought 
> of, and will require some very careful handling. Otherwise files added 
> on one system may become 'lost'.
>
> I also look forward to attempting to 'interleave' multiple encrypted 
> file systems into the same encrypted data store, Something I often do 
> with EncFS without problems.
>
> Thank you for your efforts, Cloud Filesystems have become a major part 
> of the world, and Encrypted Filesystems has become vital to making 
> this secure, even form the providers of such systems.
>

Re: [Encfs-users] Secrecy Proposal

[Anthony T. <a.t...@gr...>]

I look forward to testing out this out.  As I have said in the past, this
is the 'next step' in the File System Level of Encryption (As opposed to
Disk/Partition or individual File based encryption).

The point about a changes to a directory on two different systems causing a
synchronization conflict is something I never even thought of, and will
require some very careful handling.  Otherwise files added on one system
may become 'lost'.

I also look forward to attempting to 'interleave' multiple encrypted file
systems into the same encrypted data store, Something I often do with EncFS
without problems.

Thank you for your efforts, Cloud Filesystems have become a major part of
the world, and Encrypted Filesystems has become vital to making this
secure, even form the providers of such systems.

Re: [Encfs-users] Secrecy Proposal

[Sebastian M. <hei...@we...>]

Hey Jakob,

thank you. I already fixed one of the reported issues :)

If two users add a file at the same time to the same directory, this 
will cause a synchronization conflict in the current version. This only 
happens if it is really the same directory. Working with different 
directories (that can contain each other) is not a problem.
I'm already working on fixing this by using parent pointers in a file 
pointing to its directory instead of the other way round. The approach 
is explained in detail in my master's thesis section 4.6.5 (see 
https://www.cryfs.org/cryfs_mathesis.pdf ).

Best,
Sebastian

On 06.02.2016 11:51, Jakob Unterwurzacher wrote:
> Hi Sebastian, great work, congratulations!
> I tested it briefly and only found two minor issues that I have 
> reported through github.
>
> However, I don't yet understand how Dropbox synchronisation is 
> supposed to work.
>
> As far as I can see, the list of files in a directory is stored in a file.
> So if Alice creates "file1" while Bob creates "file2", this will cause 
> a synchronisation conflict on the directory file, right?
>
> Best regards,
> Jakob
>
> On Fri, Feb 5, 2016 at 9:06 PM, Sebastian Messmer <hei...@we... 
> <mailto:hei...@we...>> wrote:
>
>     Since EncFS doesn't hide directory structure (and also in the light of
>     the recent security issues), and since the discussion on the mailing
>     list here showed that it is probably out of scope for the original
>     EncFS
>     project, I've started an own project fixing this. You can find
>     CryFS at
>     https://www.cryfs.org
>     Please take a look and give me feedback.
>
>     It encrypts file contents, file metadata, file sizes and directory
>     structure by splitting everything into same-size blocks and encrypting
>     them individually. I've analyzed and proven its security from a
>     theoretical point of view (using game based security notions) in my
>     Master's thesis. More information on its inner workings can be
>     found at
>     https://www.cryfs.org/howitworks
>
>     I wouldn't declare it stable yet, but I'm using it with my own files
>     already for some time and didn't run into problems so far. I'd be
>     happy
>     if you could give it a try and tell me what it could do better or (in
>     case) what is broken.
>     If you're interested in helping coding, I'd also be happy to hear
>     from you.
>
>     Thank you
>     Sebastian Messmer
>
>     On 16.09.2014 02:30, Anthony Thyssen wrote:
>     > On Sun, 14 Sep 2014 22:26:34 -0700
>     > Sebastian Messmer <hei...@we... <mailto:hei...@we...>>
>     wrote:
>     > | Hello,
>     > |
>     > | I'm using encfs for encrypted cloud file synchronization and
>     it works
>     > | great. I have some thoughts about secrecy though I'd like to
>     discuss.
>     > |
>     > | Encfs is great in hiding file contents. If enabling file name
>     > | encryption, you can also hide a bit more information about
>     what the
>     > | files contain.
>     > | However, seeing the file size, an attacker can often guess the
>     kind of
>     > | files you're storing. A music collection has a certain file
>     size pattern
>     > | that is different from e.g. video files, a photo collection or
>     > | documents.
>     > |
>     > | Other encryption systems (like truecrypt) are better in hiding
>     what
>     > | you're storing inside, but having one big file storing all of
>     your data
>     > | is not feasible in many scenarios. For example when you want
>     to do cloud
>     > | file synchronization, you can't use a system where you have to
>     reupload
>     > | the whole directory when you only changed one small file.
>     > |
>     > | I was thinking about how we could get this kind of secrecy in
>     encfs
>     > | without having this disadvantage.
>     > |
>     > | My proposal is to add a special encryption mode (the user can
>     > | enable/disable it when initializing the encrypted folder), in
>     which we
>     > | don't encrypt single files, but bundle files together to
>     blocks and
>     > | store these blocks of data. The block size could be configured
>     by the
>     > | user. For the sake of this example, say we have a small folder
>     with some
>     > | vacation photos and choose a block size of 10MB.
>     > |
>     > | On the disk, we don't store an encrypted version of each
>     picture, but we
>     > | store each encrypted block as one file. So if we have 5
>     pictures with 3
>     > | MB each, they would get bundled together into two blocks and
>     stored as
>     > | two files of 10MB each.
>     > |
>     > | If we have one particularly large picture > 10MB, this file
>     would be
>     > | split up into multiple blocks.
>     > |
>     > | There is still a lot to think about on how to actually
>     implement it.
>     > | We'd probably have to store some metadata in the blocks to
>     retrieve the
>     > | actual files stored in them, which would complicate the
>     > | encryption/decryption process a bit. But I think getting this
>     kind of
>     > | secrecy is worth it. And I think we could do it in a way that the
>     > | mapping from the encrypted blocks to the decrypted virtual
>     files stays
>     > | relatively simple.
>     > |
>     > | What are your thoughts on this? Has this idea been discussed
>     before?
>     > |
>     > | Thanks,
>     > | Sebastian
>     > |
>     > |
>     > I have proposed similar ideas, but not just to hide the file sizes
>     > but also the directory structure.
>     >
>     > That is like 'UNIX' file systems, a directory is itself just a file
>     > that contains the pointers matches filenames to file locations
>     (inodes).
>     > If this is done, files (or multiple files holding a single encrypted
>     > file), would be stored in a directory tree that has no relation
>     with the
>     > original un-encrypted directory structure.  if all files have a
>     maximum
>     > size before being split up, it is imposible to 'guess' what is
>     in files,
>     > especially as related parts may not even be 'grouped' by the
>     directory
>     > structure.
>     >
>     >
>     > One problem at this time is that encfs tries to preserve
>     > file permissions and and other directory level meta-data (times,
>     > symbolic links, hard links, etc). This detail is not encrypted
>     > and depends on the underlying directory store rather than the
>     > encryption.
>     >
>     > When you split up files or hide directory structure, you have
>     > to start handling this in EncFS in some way.
>     >
>
>

Re: [Encfs-users] Secrecy Proposal

[Jakob U. <jak...@gm...>]

Hi Sebastian, great work, congratulations!
I tested it briefly and only found two minor issues that I have reported
through github.

However, I don't yet understand how Dropbox synchronisation is supposed to
work.

As far as I can see, the list of files in a directory is stored in a file.
So if Alice creates "file1" while Bob creates "file2", this will cause a
synchronisation conflict on the directory file, right?

Best regards,
Jakob

On Fri, Feb 5, 2016 at 9:06 PM, Sebastian Messmer <hei...@we...> wrote:

> Since EncFS doesn't hide directory structure (and also in the light of
> the recent security issues), and since the discussion on the mailing
> list here showed that it is probably out of scope for the original EncFS
> project, I've started an own project fixing this. You can find CryFS at
> https://www.cryfs.org
> Please take a look and give me feedback.
>
> It encrypts file contents, file metadata, file sizes and directory
> structure by splitting everything into same-size blocks and encrypting
> them individually. I've analyzed and proven its security from a
> theoretical point of view (using game based security notions) in my
> Master's thesis. More information on its inner workings can be found at
> https://www.cryfs.org/howitworks
>
> I wouldn't declare it stable yet, but I'm using it with my own files
> already for some time and didn't run into problems so far. I'd be happy
> if you could give it a try and tell me what it could do better or (in
> case) what is broken.
> If you're interested in helping coding, I'd also be happy to hear from you.
>
> Thank you
> Sebastian Messmer
>
> On 16.09.2014 02:30, Anthony Thyssen wrote:
> > On Sun, 14 Sep 2014 22:26:34 -0700
> > Sebastian Messmer <hei...@we...> wrote:
> > | Hello,
> > |
> > | I'm using encfs for encrypted cloud file synchronization and it works
> > | great. I have some thoughts about secrecy though I'd like to discuss.
> > |
> > | Encfs is great in hiding file contents. If enabling file name
> > | encryption, you can also hide a bit more information about what the
> > | files contain.
> > | However, seeing the file size, an attacker can often guess the kind of
> > | files you're storing. A music collection has a certain file size
> pattern
> > | that is different from e.g. video files, a photo collection or
> > | documents.
> > |
> > | Other encryption systems (like truecrypt) are better in hiding what
> > | you're storing inside, but having one big file storing all of your data
> > | is not feasible in many scenarios. For example when you want to do
> cloud
> > | file synchronization, you can't use a system where you have to reupload
> > | the whole directory when you only changed one small file.
> > |
> > | I was thinking about how we could get this kind of secrecy in encfs
> > | without having this disadvantage.
> > |
> > | My proposal is to add a special encryption mode (the user can
> > | enable/disable it when initializing the encrypted folder), in which we
> > | don't encrypt single files, but bundle files together to blocks and
> > | store these blocks of data. The block size could be configured by the
> > | user. For the sake of this example, say we have a small folder with
> some
> > | vacation photos and choose a block size of 10MB.
> > |
> > | On the disk, we don't store an encrypted version of each picture, but
> we
> > | store each encrypted block as one file. So if we have 5 pictures with 3
> > | MB each, they would get bundled together into two blocks and stored as
> > | two files of 10MB each.
> > |
> > | If we have one particularly large picture > 10MB, this file would be
> > | split up into multiple blocks.
> > |
> > | There is still a lot to think about on how to actually implement it.
> > | We'd probably have to store some metadata in the blocks to retrieve the
> > | actual files stored in them, which would complicate the
> > | encryption/decryption process a bit. But I think getting this kind of
> > | secrecy is worth it. And I think we could do it in a way that the
> > | mapping from the encrypted blocks to the decrypted virtual files stays
> > | relatively simple.
> > |
> > | What are your thoughts on this? Has this idea been discussed before?
> > |
> > | Thanks,
> > | Sebastian
> > |
> > |
> > I have proposed similar ideas, but not just to hide the file sizes
> > but also the directory structure.
> >
> > That is like 'UNIX' file systems, a directory is itself just a file
> > that contains the pointers matches filenames to file locations (inodes).
> > If this is done, files (or multiple files holding a single encrypted
> > file), would be stored in a directory tree that has no relation with the
> > original un-encrypted directory structure.  if all files have a maximum
> > size before being split up, it is imposible to 'guess' what is in files,
> > especially as related parts may not even be 'grouped' by the directory
> > structure.
> >
> >
> > One problem at this time is that encfs tries to preserve
> > file permissions and and other directory level meta-data (times,
> > symbolic links, hard links, etc). This detail is not encrypted
> > and depends on the underlying directory store rather than the
> > encryption.
> >
> > When you split up files or hide directory structure, you have
> > to start handling this in EncFS in some way.
> >
>

Re: [Encfs-users] Secrecy Proposal

[Sebastian M. <hei...@we...>]

Since EncFS doesn't hide directory structure (and also in the light of 
the recent security issues), and since the discussion on the mailing 
list here showed that it is probably out of scope for the original EncFS 
project, I've started an own project fixing this. You can find CryFS at 
https://www.cryfs.org
Please take a look and give me feedback.

It encrypts file contents, file metadata, file sizes and directory 
structure by splitting everything into same-size blocks and encrypting 
them individually. I've analyzed and proven its security from a 
theoretical point of view (using game based security notions) in my 
Master's thesis. More information on its inner workings can be found at 
https://www.cryfs.org/howitworks

I wouldn't declare it stable yet, but I'm using it with my own files 
already for some time and didn't run into problems so far. I'd be happy 
if you could give it a try and tell me what it could do better or (in 
case) what is broken.
If you're interested in helping coding, I'd also be happy to hear from you.

Thank you
Sebastian Messmer

On 16.09.2014 02:30, Anthony Thyssen wrote:
> On Sun, 14 Sep 2014 22:26:34 -0700
> Sebastian Messmer <hei...@we...> wrote:
> | Hello,
> |
> | I'm using encfs for encrypted cloud file synchronization and it works
> | great. I have some thoughts about secrecy though I'd like to discuss.
> |
> | Encfs is great in hiding file contents. If enabling file name
> | encryption, you can also hide a bit more information about what the
> | files contain.
> | However, seeing the file size, an attacker can often guess the kind of
> | files you're storing. A music collection has a certain file size pattern
> | that is different from e.g. video files, a photo collection or
> | documents.
> |
> | Other encryption systems (like truecrypt) are better in hiding what
> | you're storing inside, but having one big file storing all of your data
> | is not feasible in many scenarios. For example when you want to do cloud
> | file synchronization, you can't use a system where you have to reupload
> | the whole directory when you only changed one small file.
> |
> | I was thinking about how we could get this kind of secrecy in encfs
> | without having this disadvantage.
> |
> | My proposal is to add a special encryption mode (the user can
> | enable/disable it when initializing the encrypted folder), in which we
> | don't encrypt single files, but bundle files together to blocks and
> | store these blocks of data. The block size could be configured by the
> | user. For the sake of this example, say we have a small folder with some
> | vacation photos and choose a block size of 10MB.
> |
> | On the disk, we don't store an encrypted version of each picture, but we
> | store each encrypted block as one file. So if we have 5 pictures with 3
> | MB each, they would get bundled together into two blocks and stored as
> | two files of 10MB each.
> |
> | If we have one particularly large picture > 10MB, this file would be
> | split up into multiple blocks.
> |
> | There is still a lot to think about on how to actually implement it.
> | We'd probably have to store some metadata in the blocks to retrieve the
> | actual files stored in them, which would complicate the
> | encryption/decryption process a bit. But I think getting this kind of
> | secrecy is worth it. And I think we could do it in a way that the
> | mapping from the encrypted blocks to the decrypted virtual files stays
> | relatively simple.
> |
> | What are your thoughts on this? Has this idea been discussed before?
> |
> | Thanks,
> | Sebastian
> |
> |
> I have proposed similar ideas, but not just to hide the file sizes
> but also the directory structure.
>
> That is like 'UNIX' file systems, a directory is itself just a file
> that contains the pointers matches filenames to file locations (inodes).
> If this is done, files (or multiple files holding a single encrypted
> file), would be stored in a directory tree that has no relation with the
> original un-encrypted directory structure.  if all files have a maximum
> size before being split up, it is imposible to 'guess' what is in files,
> especially as related parts may not even be 'grouped' by the directory
> structure.
>
>
> One problem at this time is that encfs tries to preserve
> file permissions and and other directory level meta-data (times,
> symbolic links, hard links, etc). This detail is not encrypted
> and depends on the underlying directory store rather than the
> encryption.
>
> When you split up files or hide directory structure, you have
> to start handling this in EncFS in some way.
>
>
>
>
>
>    Anthony Thyssen ( System Programmer )    <A.T...@gr...>
>   --------------------------------------------------------------------------
>    Disclaimer:  Any lapses in spelling, tact, or fact are transmission errors.
>   --------------------------------------------------------------------------
>     Anthony's Castle     http://www.ict.griffith.edu.au/anthony/
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce.
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Encfs-users mailing list
> Enc...@li...
> https://lists.sourceforge.net/lists/listinfo/encfs-users

Re: [Encfs-users] Secrecy Proposal

[Anthony T. <an...@la...>]

I'm just sort of wondering if any more progress, thoughts or discussion
has happened along these lines.

It may be that such a major change would need to be created as a new
project.

Any info?

  Anthony Thyssen ( System Programmer )    <A.T...@gr...>
 --------------------------------------------------------------------------
  "Yeap, I died on level twenty when my pet dragon caught a cold!"
 --------------------------------------------------------------------------
   Anthony's Castle     http://www.ict.griffith.edu.au/anthony/


On Mon, 15 Sep 2014 17:29:53 -0700,
Sebastian Messmer <hei...@we...> wrote :

I like the idea of also hiding directory structure.

I see the problem with the metadata.
We could either try to implement an own representation of metadata, or
just ignore it in this mode (at least at first). Since the user can
decide whether to use this mode or not, they can then choose between
preserving metadata or improved secrecy.

In many use cases (like cloud file syncing), metadata preservation
doesn't work anyhow. Even if the cloud storage is capable of storing
them, it will fail when having the files on different operating systems
(or different file systems for that matter).

Best
Sebastian


Am Dienstag, den 16.09.2014, 10:30 +1000 schrieb Anthony Thyssen:
> On Sun, 14 Sep 2014 22:26:34 -0700
> Sebastian Messmer <hei...@we...> wrote:
> | Hello,
> | 
> | I'm using encfs for encrypted cloud file synchronization and it works
> | great. I have some thoughts about secrecy though I'd like to discuss.
> | 
> | Encfs is great in hiding file contents. If enabling file name
> | encryption, you can also hide a bit more information about what the
> | files contain.
> | However, seeing the file size, an attacker can often guess the kind of
> | files you're storing. A music collection has a certain file size pattern
> | that is different from e.g. video files, a photo collection or
> | documents.
> | 
> | Other encryption systems (like truecrypt) are better in hiding what
> | you're storing inside, but having one big file storing all of your data
> | is not feasible in many scenarios. For example when you want to do cloud
> | file synchronization, you can't use a system where you have to reupload
> | the whole directory when you only changed one small file.
> | 
> | I was thinking about how we could get this kind of secrecy in encfs
> | without having this disadvantage.
> | 
> | My proposal is to add a special encryption mode (the user can
> | enable/disable it when initializing the encrypted folder), in which we
> | don't encrypt single files, but bundle files together to blocks and
> | store these blocks of data. The block size could be configured by the
> | user. For the sake of this example, say we have a small folder with some
> | vacation photos and choose a block size of 10MB.
> | 
> | On the disk, we don't store an encrypted version of each picture, but we
> | store each encrypted block as one file. So if we have 5 pictures with 3
> | MB each, they would get bundled together into two blocks and stored as
> | two files of 10MB each.
> | 
> | If we have one particularly large picture > 10MB, this file would be
> | split up into multiple blocks.
> | 
> | There is still a lot to think about on how to actually implement it.
> | We'd probably have to store some metadata in the blocks to retrieve the
> | actual files stored in them, which would complicate the
> | encryption/decryption process a bit. But I think getting this kind of
> | secrecy is worth it. And I think we could do it in a way that the
> | mapping from the encrypted blocks to the decrypted virtual files stays
> | relatively simple.
> | 
> | What are your thoughts on this? Has this idea been discussed before?
> | 
> | Thanks,
> | Sebastian
> | 
> | 
> I have proposed similar ideas, but not just to hide the file sizes
> but also the directory structure.
> 
> That is like 'UNIX' file systems, a directory is itself just a file
> that contains the pointers matches filenames to file locations (inodes).
> If this is done, files (or multiple files holding a single encrypted
> file), would be stored in a directory tree that has no relation with the
> original un-encrypted directory structure.  if all files have a maximum
> size before being split up, it is imposible to 'guess' what is in files,
> especially as related parts may not even be 'grouped' by the directory
> structure.
> 
> 
> One problem at this time is that encfs tries to preserve
> file permissions and and other directory level meta-data (times,
> symbolic links, hard links, etc). This detail is not encrypted
> and depends on the underlying directory store rather than the
> encryption.
> 
> When you split up files or hide directory structure, you have
> to start handling this in EncFS in some way.
> 
> 
> 
> 
> 
>   Anthony Thyssen ( System Programmer )    <A.T...@gr...>
>  --------------------------------------------------------------------------
>   Disclaimer:  Any lapses in spelling, tact, or fact are transmission errors.
>  --------------------------------------------------------------------------
>    Anthony's Castle     http://www.ict.griffith.edu.au/anthony/
> 
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce.
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Encfs-users mailing list
> Enc...@li...
> https://lists.sourceforge.net/lists/listinfo/encfs-users



------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Encfs-users mailing list
Enc...@li...
https://lists.sourceforge.net/lists/listinfo/encfs-users

Re: [Encfs-users] syncing ciphertexts

[Anthony T. <A.T...@gr...>]

On Thu, 20 Nov 2014 20:28:41 -0500
Matei David <ma...@cs...> wrote:
| Hi,
| 
| I'm interested in keeping two encfs folders in sync. One option is to
| run rsync/unison between the plaintext folders. I would like to have
| the additional option of performing sync on the ciphertexts.
| 
| >From the tests that I ran, it seems to me that this is only possible if
| uniqueIV is set to 0 in the configuration file. Whenever this is set to
| 1, the ciphertexts of two identical plaintext folders seem to be
| different. To clarify, my tests consisted of running this script while
| tweaking various parameters inside encfs6.xml.
| 

Just copy the folder from one to the other.

Don't worry about the separate encryptions being different, that is just
a randomization of the keys (Salt or UniqueIV) to make cracking harder.

I use unison to synchronise the encrypted files of a encfs file-systems
between three systems, no problems.

Others I know do the same via a DropBox.

What I would recommend is using some system that keeps the .encfs6.xml
separated from encrypted files. Transfer it separately to machines that
are 'allowed' to access the encrypted data.

Now while this file only contains public parts of the encryption, why
give that file to 'crackers'?  Without it it becomes even harder to
'crack' an encryption.

I treat it a bit like a 'second key'.   I not only need my pass phrase,
But I also need that file, to access my encrypted filesystem.

Look at the encfs environment variable ENCFS6_CONFIG

Unfortunately may of the encfs apps doesn't let you separate the config
from the encrypted data.

For some raw hints and tips on using EncFS see
  http://www.ict.griffith.edu.au/anthony/info/crypto/encfs.hints

  Anthony Thyssen ( System Programmer )    <A.T...@gr...>
 --------------------------------------------------------------------------
  All of us have violent instincts. We have evolved from predators.
  Well not me of course, I've just been programmed by you predators.
                                            The Doctor -- StarTrek Voyager
 --------------------------------------------------------------------------
   Anthony's Castle     http://www.ict.griffith.edu.au/anthony/

Re: [Encfs-users] syncing ciphertexts

[Matei D. <ma...@cs...>]

Can you look at the "001" line, at columns 2&4? So:

uniqueIV=0
chainedNameIV=0
externalIVChaining=1

In the plaintext folder view we have 4 identical files:
file-a
file-b
dir/file-a
dir/file-b
The all contain "hello\n".

In the ciphertext view, running md5sum on all 4 files I see:
3fee6e6aa7ad918709fac8ebb2ddaa3f  /tmp/.docs-1/dRh67KocD9v2gE-vcY5FjQHU
3fee6e6aa7ad918709fac8ebb2ddaa3f  /tmp/.docs-1/9khiedHAIWM,QyXyrau2qsLP
3fee6e6aa7ad918709fac8ebb2ddaa3f  /tmp/.docs-1/dJB18,Uy0wDV69ZbYwf6TGgf/dRh67KocD9v2gE-vcY5FjQHU
3fee6e6aa7ad918709fac8ebb2ddaa3f  /tmp/.docs-1/dJB18,Uy0wDV69ZbYwf6TGgf/9khiedHAIWM,QyXyrau2qsLP

So:
- The plain paths of the 2 files in the root dir are different:
  "file-a" and "file-b"
- The encoded paths of the 2 files in the root dir are different:
  "dRh67KocD9v2gE-vcY5FjQHU" and "9khiedHAIWM,QyXyrau2qsLP"
- Yet, the file data encoding of "file-a" and "file-b" is the same(!)

How does this fit in with the description of externalIVChaining? With
"001", I would expect to see 2 different md5sums. What am I missing?


On Fri, 21 Nov 2014 19:59:23 +0100
Jakob Unterwurzacher <jak...@gm...>
wrote:

> Hi Matei,
> have you taken a look at this?
> https://github.com/vgough/encfs/blob/master/encfs/FileUtils.cpp#L847
> On Nov 21, 2014 6:22 PM, "Matei David"
> <ma...@cs...> wrote:
> 
> > On Thu, 20 Nov 2014 17:47:59 -0800
> > "Mark R. Pariente"
> > <mar...@gm...> wrote:
> >
> > > On Thu, Nov 20, 2014 at 5:28 PM, Matei David
> > > <ma...@cs...> wrote:
> > > > Hi,
> > > >
> > > > I'm interested in keeping two encfs folders in sync. One option
> > > > is to run rsync/unison between the plaintext folders. I would
> > > > like to have the additional option of performing sync on the
> > > > ciphertexts.
> > > >
> > > > >From the tests that I ran, it seems to me that this is only
> > > > >possible if
> > > > uniqueIV is set to 0 in the configuration file. Whenever this is
> > > > set to 1, the ciphertexts of two identical plaintext folders
> > > > seem to be different. To clarify, my tests consisted of running
> > > > this script while tweaking various parameters inside encfs6.xml.
> > > >
> > > > #!/bin/bash -x
> > > > cat encfs6.xml
> > > > rm -rf /tmp/.docs-{1,2} /tmp/docs-{1,2}
> > > > mkdir -p /tmp/.docs-{1,2} /tmp/docs-{1,2}
> > > > echo password |
> > > > ENCFS6_CONFIG=encfs6.xml encfs -S /tmp/.docs-1 /tmp/docs-1
> > > > echo password |
> > > > ENCFS6_CONFIG=encfs6.xml encfs -S /tmp/.docs-2 /tmp/docs-2
> > > > echo "hello" >/tmp/docs-1/a-file
> > > > rsync -a /tmp/docs-1/ /tmp/docs-2/
> > > > md5sum /tmp/.docs-[12]/*
> > > > fusermount -u /tmp/docs-1
> > > > fusermount -u /tmp/docs-2
> > > >
> > > > My question is, are there security considerations why I would
> > > > want to keep uniqueIV set to 1? I checked the manual and the
> > > > guide here
> > > > http://www.ict.griffith.edu.au/anthony/info/crypto/encfs.hints
> > > > Neither mention unique IVs or what they are good for.
> > >
> > > UniqueIV generates a random IV value for each file - that is why
> > > you are seeing the same plaintext/path resulting in different
> > > ciphertext when copied.
> > >
> > > The reasoning for uniqueIV is to prevent statistical attacks -
> > > without it the same plaintext results in the same ciphertext so an
> > > observer can tell how many copies of a file you have, and this is
> > > considered information leakage.
> >
> > Thanks for the prompt reply.
> >
> > From the description in the manual, I would have thought that
> > externalIVChaining would prevent such an attack: I thought 2
> > identical plaintext files would encrypt in different ways depending
> > on their names (or paths, with chainedNameIV). But my understanding
> > is wrong, right? I think I'm mixing up 2 things that are being
> > encrypted: file names, and file contents.
> >
> > Can you explain what externalIVChaining does exactly? I tried to
> > figure it out but I don't see any effect. Here's what I tried:
> >
> > - for every triple of IV-related options:
> >   (uniqueIV, chainedNameIV, externalIVChaining)
> > - create 2 identical plaintext files (file-a, file-b)
> > - copy them to a  directory (dir/file-a dir/file-b)
> > - so in total, there are 4 identical files, with 2 different base
> > names
> > - sync the plaintexts between 2 mounts
> > - count:
> >   - unique file names in ciphertext of 1 mount
> >   - unique file names in ciphertext of both mounts
> >   - unique checksums in ciphertext of 1 mount
> >   - unique checksums in ciphertext of both mounts
> >
> > I'm attaching the script. The results I see are:
> > 000 2 2 1 1
> > 001 2 2 1 1
> > 010 4 4 1 1
> > 011 4 4 1 1
> > 100 2 2 4 8
> > 101 2 2 4 8
> > 110 4 4 4 8
> > 111 4 4 4 8
> >
> > Based on this, I infer that:
> > - uniqueIV affects only file content encryption, not file names
> > - chainedNameIV affects only file name encryption, not file contents
> >
> > What I don't understand is the effect of externalIVChaining. I don't
> > see anything chaning when it is enabled.
> >
> > Thanks,
> > M
> >
> >
> > ------------------------------------------------------------------------------
> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> > from Actuate! Instantly Supercharge Your Business Reports and
> > Dashboards with Interactivity, Sharing, Native Excel Exports, App
> > Integration & more Get technology previously reserved for
> > billion-dollar corporations, FREE
> >
> > http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Encfs-users mailing list
> > Enc...@li...
> > https://lists.sourceforge.net/lists/listinfo/encfs-users
> >
> >
>