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 <heinzis...@web.de
<mailto:heinzis...@web.de>> 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 <heinzis...@web.de <mailto:heinzis...@web.de>>
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.
>
------------------------------------------------------------------------------
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
