>>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) ------------------------------------------------------------------------------ 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 Encfs-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/encfs-users
