On Thu, 8 Oct 2009 11:01:01 -0400 (EDT)
si...@mungewell.org wrote:
| There would be a number of problems using encfs for plausible deniability,
| mainly the fact that it does not protect the meta data (the number of
| files, ownership, dates and file size).
|
| You would be much better using something like elettra, which is
| specifically designed for the purpose.
| http://www.winstonsmith.info/julia/elettra/
|
| Cheers,
| Mungewell.
|
|
Thanks for the pointer I'll take a look.
ownership is not an an issue. everything has only one owner.
filesize not a problem as thing will be quite variable
even number of files per directory is variable.
all files are also only data mostly 600 so that is uniform.
As for dates and time well I was thinking about that.
The 'junk' or 'chaff' files will probably need their time stamps
modified at random. perhaps every time you mount the EncFS a random
number of older time stamps is updated.
Or on umount all the timestamps are set to 'now' or 'epoch'.
Ignore timestamps may actually be a nice option for the mount!
It will be a pain for incremental backups (tar or dump), but for unison
transfers and rsync hardlinked 'snapshot' backups that will not make any
difference (given the right options), as the file itself does not
change, only its time stamps. This is the part that makes EncFS a much
more useful encryption method in any case.
The point is if you have say 3 or 4 regularly updating file sets
(with different passwords) and a few chaff sets (unknown passwords)
with obvious chaffing being used, then it will not be posible for
someone to tell how many sets you really have interleaved.
FUTURE SUGGESTION for EncFS...
have it store directories as 'index files' and 'flatten' the whole
tree, into say a set of directories basied on some other crieteria.
For example create 64 directories (to limit the number of files per
actual directory) and use a hash or directory index reference to
determine which directory a specific file is in.
That is you can remove and hide the whole directory tree, while
retaining the file studenture for backup and incremental file
transfer.
Currently if you list the top level each file or directory will belong
to one 'interleaving' password/salt pair but the contents of a specific
sub-directory will all be part of that directories password.
Removing and hiding the directory structure will prevent this current
one top-level directory/file one password grouping.
I think this would be the next biggest improvement that could be made.
Anthony Thyssen ( System Programmer ) <a.thys...@griffith.edu.au>
-----------------------------------------------------------------------------
This is one big web site! --- Hercules, "Web of Desire"
-----------------------------------------------------------------------------
Anthony's Home is his Castle http://www.cit.gu.edu.au/~anthony/
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Encfs-users mailing list
Encfs-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/encfs-users
